軟件架構雖然是個相對穩定的技術領域，但也在十年間經歷了從單體應用到 SOA 再到微服務的演化過程。但在本文做者看來，自 SOA 架構風格提倡以來，軟件架構並未有特別的突破，更可能是在其之上作不斷的演化迭代。爲何呢？後端
Everything will be alright in the end, but if it is not alright, it’s not the end YET. —— True Grit跨域
Don’t take shortcuts. Don’t ask about what does not concern you. And don’t jump too quickly to conclusions.——Three Words of Wisdom安全
The whole is greater than the sume of all parts.微信
The whole has the properties its part do not have.架構
— The concept of Emergence併發
前言
自從 SOA 架構風格提倡以來，我的以爲軟件架構並未有特別突破的變革：主要是在 SOA 面向服務架構風格基礎上不斷演化迭代。基於服務的 EA 明確分層架構也好，微服務也罷，都是在面向服務架構基礎上的適應不一樣的場景的迭代升級，同時 DDD 領域驅動也給面向服務架構設計提供了很是好的設計理念，因此我就想回歸到根本：面向服務的的架構來聊聊，可能有人說老生常談沒啥意思，不要緊，就當一個本身的思路整理，先聊 10 塊錢的。框架
面向服務的架構我的認爲咱們花了很是多的精力在 HOW 上面，可是對服務是什麼（What）和爲何咱們要服務化的架構（Why）重視度和花的精力是相對不足的。dom
我先拋出一個觀點，我以爲服務化架構的本質和西方教育界深受影響的古希臘哲學家蘇格拉底的「產婆術」的教育思想本質上是很是相通的：蘇格拉底的「產婆術」思想強調教育是一個「接生」的過程，教師就是「接生婆」，人們之因此接受教育是爲了尋找「原我」以不斷完善自身。也就是教育的目的在於喚醒而再也不於塑造。同理服務化架構的本質也不只僅在採用什麼樣的技術框架實現和塑造，更重要的是在於經過不停地在共創中反問、反思、檢討等方式進行對業務的本質的不斷追溯、抽象、綜合概括演繹，咱們的每個架構師都是服務化架構的接生婆，咱們的使命是創建真正反映業務本質並驅動業務不斷向前的架構。模塊化
咱們是否足夠深刻理解業務的本質，作了足夠的概括演繹以及綜合抽象，是否清晰的反應到了咱們的服務化的根基：業務模型、域模型以及平臺公共語義模型上？這是咱們每個參與服務化的每個產品、架構師、TL 和核心開發同窗須要回答的第一個根本問題。微服務
爲了避免產生概念的混淆和理解差別，我嘗試先對一些基礎的概念進行定義，各大組織定義各異，我選擇和本身的理解更接近的一些定義，在參考各大標準定義的基礎上加入了一點本身的理解。
術語
業務服務：提供增值價值的業務行爲或流程，其具備明確的業務功能定義，同時具備明確對應其價值的服務質量及水平衡量標準。
業務流程：經過獲取產出（如一系列產品後者服務）知足客戶需求來實現特定業務價值的一系列業務行爲的有機組合。業務流程一般跨越整個平臺業務域，一般是由各域服務能力來支撐流程中的業務活動。
應用組件：按照必定的相關性進行進行結構化封裝的應用功能的一個集合，其目的是爲了
提高應用總體的一致性，靈活性，穩定性並實現重用。關鍵字：結構化封裝、一致性、靈活性、重用。應用：一個應用組件的集合，其目的用來提供單個業務功能或者多個業務功能，從而爲整個系統或者平臺提供增量價值支撐。如供應鏈計劃域中的銷量計劃應用，計劃庫存應用，業務規則參數應用，補貨庫存平衡應用等。
系統：一系列應用以及服務的有機組合，具有端到端的完整業務功能，以體系化提供用戶增量價值爲核心目的。
平臺：一個或者多個系統的有機組合，具有整個業務線或者業務生態的端到端業務功能全集，以提高業務線或者業務生態總體業務價值爲目標。
架構：架構是一個系統的基礎組織構成，體如今其構成的組件集合，組件之間的關係以及與外部環境（人、系統、設備）的交互關係，以及指導系統設計和發展演進的原則
架構風格：架構風格是一系列符合共同原則和特徵的架構
定義
面向服務的架構 (SOA)：
SOA 是一種架構風格，致力於將業務功能保持一致的服務（系統服務，應用服務，技術服務）做爲設計、構建和編排組合業務流程以及解決方案的基本單元。
目的
咱們採用 SOA 的架構是爲了什麼呢？
爲了更好的複用？爲了更好的責任切分？爲了接口和實現的分離，提高靈活性和隔離性？仍是爲了更好的接口分類和管理？
以上說法其實都沒錯，可是面向服務化的架構 SOA 目的是遠遠超過接口技術細節的設計與定義，其核心的關注點在於服務的業務內容以及內涵，而不只僅是如何設計和實現。
同時，SOA 更多的也不是如何構建一個服務，任何人均可以很容的建立一個服務，這並非 SOA 的核心挑戰，而是如何賦能企業構建有業務價值意義的完整業務語義的服務集合
面向服務的架構致力於在企業內的不一樣的業務環境內，建設業務功能驅動的服務，從而將服務組裝成有價值、更高級別的業務流程和解決方案平臺。
面向服務的架構的真正的價值體如今當可重用的服務被靈活組合、編排在一塊兒來構建敏捷的，靈活的業務流程，其中敏捷體如今服務能夠快速調整，獨立演化；靈活性體如今服務因爲其業務功能定義明確，邊界清晰且功能內聚性強，同時服務具有各自獨立完整生命週期，可被靈活組裝。
若是面向服務架構能爲企業提供了重大的價值，那麼這些價值經過什麼來體現的呢？
價值體現
行爲一致性
面向服務的架構容許咱們爲業務流程、任務或者決策擁有惟一的共同的的入口，也就是，無論服務訪問的路徑如何，服務給業務提供的業務行爲都是一致的。
數據一致性
面向服務的架構容許咱們爲業務數據信息提供單一的訪問入口，也就是它提供給業務一致的、企業內部共識的公用數據訪問。
模塊化及敏捷性
面向服務的架構 SOA 爲業務功能、業務決策和業務信息的模塊化提供了很是好的機制。同時，在模塊化實現好的狀況下，這些模塊能夠在多個業務流程和場景中被靈活複用和從新組合，從而爲業務競爭力和創造性提供靈活性和敏捷度支持。
功能與數據的解耦
面向服務的架構 SOA 提供了業務功能和信息集成的同時，減小了他們之間的依賴和耦合性。也就是，獨立的業務功能單元，應用系統，能夠一塊兒協同工做，同時各自又具有各自的演進計劃，生命週期和業務目標。
高度可管理性
SOA 提供給咱們經過定義服務水平協定在服務模塊粒度支撐咱們的業務目標，咱們能夠不斷的設定、監控和優化調整組件，應用以及系統所承載服務的考覈。
其中行爲一致性和數據一致性做爲服務的核心價值根基。
服務
1、定義
首先咱們先定義一下服務是什麼？
服務是經過服務契約的方式來提供業務功能的獨立單元，同時受服務契約所明確管理。
服務是設計、構建和編排組合一個完整業務實體中業務解決方案的基礎單元。服務契約指定了服務消費方和提供方之間全部的交互約定，包括：
服務接口
接口文檔
服務策略
服務質量
服務可用性
性能
那咱們常常聽到模塊、組件等其餘的軟件構件，服務和他們有什麼區別呢？其中最核心的區別在於服務自己是被明確管理的，其服務質量和性能是經過服務水平協定（SLA）被明確管理的，而模塊以及組件並沒有此約束。此外，服務的全生命週期包含從設計、部署到加強升級和維護都是可管理的。
舉例（下列內容僅作示例展現用，非適用於嚴格場景）
| 補貨計算服 | 服務策略 | 服務質量 | 性能要求 |
|---|---|---|---|
| 補貨建議量計算服務 | 針對行業下商家 / 供應商維度的入倉貨品補貨建議計算 | 在銷量預測符合分佈要求且知足準確率水平要求的狀況下，根據缺貨率服務水平要求的產生的補貨建議量符合業務指望的週轉天數 | 10W+ 貨品 *30 倉，品 + 倉補貨及建議量 <=30min |
| 訂單建立服務 | 包含購物車下單 + 當即下單場景，知足全部優惠計算後的訂單生成 | 訂單建立成功率 99.999999999% | 峯值支撐：100w 單 /s |
2、服務構成
服務自身主要包含兩個主要方面，第一方面也是服務最核心的方面就是服務的接口，另一方面則是服務的實現。服務很是好的實現了接口和實現的分離。
服務接口
服務接口指定了服務的操做，也就是服務是作什麼的 (What), 操做的輸入輸出參數，以及用來約定如何使用和提供這些能力的協議。
服務一般包含圍繞着一個核心的業務功能操做以及相關聯的操做。例如補貨建議計算服務中核心的操做是生成貨品 + 倉維度的補貨建議單，其餘相關操做包含查詢補貨建議單相關銷量預測操做，查詢補貨建議單對應計劃庫存操做
服務 核心功能操做 關聯操做 補貨建議計算服務 品 + 倉維度補貨建議計算 補貨建議單對應銷量預測查詢 補貨建議單對應計劃庫存操做 服務實現
服務實現指的是服務如何經過其明肯定義的接口提供其能力。服務實現能夠經過如下方式實現：
核心點是服務如何被實現的對於服務消費方來講是透明的，服務消費方僅僅須要關心的是服務是作什麼的，而不是如何被實現的。
服務能夠提供在保持服務接口或者行爲約定不改變的狀況下，提供根據不一樣的行業不一樣場景提供各類不一樣的實現。
服務實如今保持服務接口或者行爲約定不改變的狀況下，能夠自由進行升級和切換。服務實現既能夠是靜態的更新升級，也可使動態路由實時切換實現，如對應到不一樣的行業以及不一樣的業務場景的自動實現切換。
無論服務實現如何升級或者按需自動路由切換，只用服務的行爲和契約不會發生改變，用戶也就是服務的消費者根本不會感知到任何不一樣。
咱們能夠把服務接口想象成室內普通電源國標插口，服務策略爲室內非防水狀況下適用，服務契約想象成 24X7 的 220v 電壓供電能力（其中 180V～250V 50Hz 是質量要求，24x7 穩定性要求，電流供給 <=10A 是性能要求），此國標插座（服務提供方）能夠給包含與此接口匹配且符合契約的任何電器（消費方）交互並提供供電能力，支持其運轉。
服務接口定義了交互的的風格和細節，而服務的實現定義了一個特定的服務提供方或者特定的業務實現如何提供其能力。
這種相似鏈接點 / 插口的設計極大的方便了更鬆耦合的業務功能解決方案。
徹底基於編碼實現
基於其餘服務的編排而成
基於已有應用適配封裝而成
以上狀況混合實現
3、服務接口與服務實現的邏輯構成
服務接口與實現的構成也有兩個重要的不一樣方面，分別是執行功能的方法和執行的信息數據。換句話說，一個服務是由一個業務服務操做集合以及對應操做的輸入輸出的抽象業務服務數據模型組成。這層業務服務數據模型是企業業務層次或者平臺業務層次的業務實體的抽象，獨立於底層數據存儲與實現。此業務數據模型是和各子域密切相關聯，可是超越各子域以上的，在完整的業務線或者平臺層次上達成一致的業務數據模型，也就是說在各子域之間達成共識且約定的嚴格明確的公共模型，主要用於平臺業務流程中不一樣域服務的交互，是平臺層次統一的業務語言，我把它暫時稱爲平臺業務數據模型。 此平臺業務數據模型一般須要包含平臺統一語義的業務術語表，平臺各域核心實體表，平臺各域核心實體交互圖等。
接口與實現的邏輯構成：
服務操做
服務操做聲明定義了這個操做的輸入以及輸出參數。
平臺業務實體模型
平臺業務實體模型描述了服務中輸入輸出數據的結構以及含義。服務接口中的信息和服務實現中邏輯數據之間的差別是相當重要的。
在服務接口層次上，最重要的是信息必須在業務服務之間進行交互來賦能業務流程並完成業務流程。這些信息必須在參與流程的全部業務服務間達成一致且在服務之間通用，也就是平臺層次全部服務公用且標準的業務實體模型，同時此業務實體模型必須在平臺業務語義上明確且完成，確保能夠支撐平臺全部端到端的業務。此平臺層級的業務實體模型並非一蹴而就的，可是能夠隨着平臺的重心變化不斷迭代完善成型的。
然而不一樣的是，從內部來看，不少服務在各自實現的子域內部都有這些信息的不一樣的超集，可能潛在的存在不一樣的數據格式。幸運的是，咱們不須要感知也不須要在全部關聯服務的相關子域實體模型上達成共識，即便不是不可能，可是也不太現實。與之相反，服務接口和服務實現的分離設計容許很是方便的進行平臺業務實體模型和服務所在子域領域模型進行映射轉換。
服務接口最後一個重要的方面就是服務水平協議 SLA。服務水平 SLA 協議指定了服務的的兩個重要方面的指標，分別是業務上的指標和技術上的指標：
技術指標：響應時間 RT，併發吞吐量 Throughput，可用性 Availability，可靠性 Reliablity。
業務指標：完成的業務功能的質量或者完成度，如產生的補貨建議是否知足業務預期的週轉缺貨 KPI 要求：週轉降低 10 天，缺貨率降低 5%。
服務化分層架構
理解服務化分層架構，首先要對 TOGAF Meta-Model 有個清晰的理解，從元模型能夠看出業務服務和業務流程的上承業務，下啓系統平臺的核心做用，必定要深入理解業務服務和業務流程在企業架構中的重要性，下面我把我翻譯後畫的版本給你們放在這裏，給你們作個參考，TOGAF 很少作解釋，若有須要，你們能夠交流，後面有時間嘗試寫下我對 TOGAF 的學習和理解。
一般狀況下，咱們會按照不一樣行業的不一樣的業務流程去搭建系統，如供應鏈最初在你們電 3W 行業孕育，咱們按照 3W 的行業和業務場景搭建了平臺商家相適應的計劃系統；後續自營行業又根據本身的行業也搭建了自營的計劃系統；後續小電數碼、國際以及其餘業務快速發展，跟隨業務快跑的同時，也各自創建的各自的業務流程。在這個過程當中，BPM 爲建造不一樣的業務系統提供很是好的抽象支撐，可是常常的結果是，BPM 被用做構建了更高層抽象的，也更高效的，可是倒是煙囪式的應用，而不沒有更好的貢獻更多的支撐到總體上能快速應對業務變化而更靈活，更敏捷的業務平臺或者系統。
而這正是面向服務的架構中業務規則以及決策做爲服務要發揮更大做用的地方。面向服務的架構容許咱們將特定業務流程中的業務規則和業務決策抽象分離出來變成業務規則或者決策服務，這些規則和決策服務就能夠被靈活應用到不一樣的業務流程中，從而這些服務能夠被統一管理和演化升級。
BPM+SOA 一塊兒提供了支撐企業架構的完美組合。BPM 提供更高層抽象定義業務流程的能力，以及與流程相關聯的重要監控和管理能力；業務服務提供了支撐業務流程的核心的功能、決策以及信息。面向服務的架構則提供能力將服務組合在一塊兒來支撐和建立靈活且敏捷的端到端的企業業務。若是隻有 BPM 而沒有 SOA 對於建立單獨的業務應用或許很是有用，可是一般是建立的煙囪式的應用，很難擴展到企業內或者平臺內不一樣的業務線。若是隻有 SOA 而沒有 BPM 雖然能夠建立可重用且一致性高的服務，可是缺乏將這些服務快速搭建業務流程並支撐端到端業務的能力，也沒法支撐創建具備競爭力且能夠隨着外部競爭環境進行敏捷反應的業務。
下圖顯示了一個建議的的封層服務化架構圖，各分層以下：
端到端業務流程：業務流程是按照必定業務規則決定的順序執行的業務操做組成。高層級的業務功能，一般跨越應用域或者業務線。一般由行業開發團隊開發，此行業開發團隊能夠具有明確的實現組織結構，也能夠由跨團隊的相關域共同組成虛線團隊。例如，電商業務中，用戶選購下單交互流程；供應鏈業務中的補貨調撥計劃流程等。
平臺業務服務：高度模塊化的業務功能單元，由不一樣類型的子域服務組合編排而來，可做爲業務流程的編排單元。跨行業通用的業務服務可由功能所在覈心域開發團隊編排開發，行業內通用的業務服務能夠由行業開發團隊負責編排開發。例如，補貨審批服務
子域服務：平臺各功能子域提供的服務，對平臺可見，用於平臺業務服務的組合編排，也能夠做爲更高層的業務流程編排的基礎單元。子域服務一般由平臺各子域開發團隊負責開發。例如，銷量計劃服務，補貨建議計算服務。
子域基礎服務：用於支撐各功能子域服務的基礎服務，對子域可見，對平臺不可見，用於子域服務的編排。
子域基礎服務一般由平臺各子域開發團隊負責開發。例如，入倉決策服務，計劃單據服務，計劃庫存服務等。
基礎子域服務：或稱爲基礎業務域服務，提供平臺基礎業務服務，爲各個功能子域或平臺業務服務提供基礎業務功能及數據服務。例如：商家服務，貨品服務，庫存服務等。
基礎架構服務層：提供不一樣層次所公用的基礎架構服務，如用用戶管理，權限管理，操做審計等等。
咱們一般按照上述分層結構來描述平臺架構或者企業內部架構，看上去好像層次結構清晰明瞭，可是倒是不完整的，由於此面向服務的架構描述缺失了平臺系統架構中一個核心部分，暨信息及信息模型分層，這一點很是之關鍵，每每會決定架構的成功與否。
爲了使架構更完整同時也更真實，咱們須要添加對應的完整信息抽象（實體模型 or 領域模型）：
核心單據模型：端到端業務流程中操做的核心單據，承載業務核心價值的信息單元模型，例如，銷售訂單，採購訂單，補貨計劃單等。此模型一般是平臺公共語義模型的核心子集。
平臺公共語義模型：定義了平臺層業務流程、業務服務交互數據。在平臺層面或企業層面，端到端業務流程中交互信息的公共語義模型，此模型不只對平臺業務流程中交互的各實體進行了明確的定義，並且包含了業務流程中所須要的完整的業務語義實體，同時各業務語義實體邊界明確，責任清晰。核心單據模型一般是平臺公共語義模型的子集。平臺公共語義模型包含下層子域的對外服務實體子集，按照端到端的完整平臺業務語義，可由平臺各功能子域模型所共享給平臺的核心實體子集有機整合而成，也可由平臺業務模型全新定義，或者從 TOP-DOWN 以及 BOTTOM-UP 兩個方向共同融合而成。須要注意的是此模型必然是沒法一蹴而就，須要通過無數迭代而不斷完善，但其必定是不可或缺的。平臺的諸多架構決策和不斷演化完善須要基於此模型來進行。
子域領域模型：平臺各功能子域的領域模型，用於驅動各功能子域的應用系統設計和開發。子域領域模型須要保持動態穩定，經過防腐層同所依賴的外域或者外部服務進行隔離，防止外部服務污染子域內的核心業務語義，同時保持域內業務功能靈活可控。子域領域模型僅經過其對外服務實體子集對外可見，其他對外不可見。
跨域映射模型：用於各子域領域模型實現對外部模型的防腐依賴。
基礎架構服務層：提供不一樣層次所公用的基礎架構信息模型，如用戶模型，權限模型等。
信息架構模型框架
如今來討論下服務化分層架構重視度並不過高的另外一個重要側面：信息架構，之因此說信息架構很是之重要，是由於信息架構與服務化架構是一個密不可分的完整的總體。我對信息架構模型進行了分層劃分，下面從 TOP_DOWN 方向來討論不一樣的分層模型。
Level0：戰略與決策模型（高層戰略視角）
這層次模型用於定義企業的戰略方向和商業目的，從而定義了企業內任何系統平臺開發的方向和終局。這必然做爲企業內任何系統平臺開發的基本背景和基調，影響任何系統平臺開發項目的中長期目標定義和終局設定。
Level1：商業模式（業務線 owner 視角）
這層模型從業務線 owner 的視角，用運營主體的業務術語描述其商業模式的本質，包括其總體結構，業務流程，以及組織結構等。
Level2: 業務抽象概念模型
這層模型從業務架構的視角用信息化的方式對單個業務線或者多個業務線的業務進行抽象。Level 1 描述是對於企業業務來講有意義的東西或者事情，而 Level2 則給予這些有意義的東西以更嚴格且清晰的定義，明確其內涵以及外延並體系化，同時根據不一樣行業線的業務內容進行提取抽象，抽象出共性的內容，用於更高效靈活的描述和定義業務 。
Level1 描述的是業務運營人員所感知的業務流程，Level2 不只描述了這些業務流程，更重要的是抽象並描述了了這些業務流程所應該包含的底層業務功能。
一樣的，Level1 描述對企業業務來說全部重要的東西，Level2 描述的是組織想要管理的信息後面最根本的內容。Level1 描述的事情是 Level2 定義的基本實體的實際業務中對應的樣本或事例。
簡而言之，Level2 是 Level1 的抽象（Abstraction）與綜合 (Synthesis). 爲了達成這一視圖，必需要仔細分析和概括，有時候須要演繹的方式來定義出隱藏在企業業務運營主體視圖下根本結構和內容。
Level3：平臺公共語義模型
Level3 層公共語義模型同 Level2 層業務概念模型保持緊密一致，在此基礎上增長了服務化視角的語義。Level3 公共語義模型描述的內容是在必須在平臺層業務服務間共享的具備一致語義的業務實體和信息，是平臺層一致的共享信息模型。這層模型用於描述平臺層服務接口交互的共享信息，基於平臺完整業務語義下全部服務所公共數據的標準化視圖模型。簡而言之，平臺公共語義模型，定義了業務平臺層次基本業務服務語義，是平臺各業務服務之間，平臺業務流程和平臺業務服務交互的統一語言。
Level4：域模型
Level4 層域模型定位於平臺各子域的領域模型 / 實體模型，用於對各子域的核心業務功能進行抽象。域模型是平臺各子域的標準模型，不只明肯定義的各子域功能服務暨服務接口的語義，同時也包含各子域內服務實現中的關鍵實體的定義。域模型從總體上來講是平臺各子域的私有模型，除了服務語義外總體不對外可視。公共信息中的服務視圖是域模型的子集。
域模型核心用於除了用於暴露到平臺子域的業務服務設計與實現外，同時也用於驅動域內服務功能的設計和實現。
域模型是須要保持動態穩定的，除非域內業務發生本質變化，域模型應該是相對穩定的。域模型穩定性最大的敵人是外部的依賴，如何不受外部依賴的侵蝕而逐漸腐敗，域防腐層存在的最主要緣由。子域防腐層維護外部依賴服務和子域模型之間的動態映射，維護域模型的獨立性，保護域模型不受有害侵蝕。
域模型我理解基本和咱們一般談的領域模型基本接近，對於各域內業務的抽象，驅動各域技術設計方案設計和實現，至於具體的模型表現形式，採用基於亞里士多德的物質本源的思想（「Material Cause,Formal Cause,Efficient Cause,Final Cause" —> 實體 + 屬性 + 關係）的 ER 圖，仍是基於咱們老祖宗老子道家思想 (「人法地、地法天、天法道、道法天然」 —> 實體 + 行爲) 的思想的領域驅動 DDD 的方式，我的認爲各有伯仲，組中能清楚表達出業務本質便可，後面單獨寫一篇抽象建模的文章聊一下這兩種不一樣的思想。
Level5：實現模型
此層模型爲開發者視角的實現模型，也就是咱們系統實現核心的對象模型，是咱們系統落地的基石。
設計服務
咱們初步瞭解的什麼是服務，以及什麼是服務化的分層？那如何設計服務以及服務化架構呢？下面給出基本步驟和方案。
1、理解總體背景
首先，咱們要理解服務化架構的總體背景。咱們必須理解咱們所支撐的業務和業務根本驅動力以及全部的業務流程，業務場景以及業務用例；同時對於平臺系統，咱們還必須理解公司的戰略所賦予平臺的使命是什麼？咱們平臺中長期的目標是什麼？平臺的終局是什麼？這些組合和在一塊兒纔是服務化架構的完整的上下文背景。這些必需要反映到咱們的業務模型、平臺公共語義模型和各域模型中去。
而後，咱們須要提出並回答以下問題：
咱們當前支撐的是什麼樣的業務？（業務模型）
這個業務或者這些業務的中長期目標和短時間目標分別是什麼？
平臺的短中長期目標是什麼？平臺的終局是什麼？
上述目標是否存在衝突，如何平衡和取捨？
實現這些目標，須要完成什麼樣的成果？
這些成果如何衡量？
取得這些成果，須要什麼樣的能力和信息？
實現這些能力須要什麼樣的流程、服務、實體以及規則
現有的服務、應用或者系統提供了那些基本能力和信息？
前面六個問題描述了總體的架構需求（包括業務和平臺），而剩下的問題則描述了整個服務化架構的上下文以及引入了服務目錄庫的需求。咱們服務不能只從單個服務的角度來看，而必須從整個服務集合的角度來反應完整的業務語義和平臺語義。咱們的服務集合也就是服務目錄庫必須具有完整的上下文語義，必須能識別出：
總體的上下文背景，包括完整的業務語義和平臺語義。
服務職責範圍
關聯的服務的分組
服務的類型和角色
服務目錄庫的設計必須支持兩個主要的設計時目標：
第一個目標是要提供一種機制來幫助理解服務總體的上下文背景，用於更好的服務選擇及更高效的服務重用。特別是，這個服務實現了什麼樣的責任，以及如何和其餘的服務相關聯。
第二個目標是要提供一種機制來識別一個特定服務的責任邊界，用來指引服務的實現。這是一個很是關鍵的點，特別是在避免服務的功能和數據重複上很是重要，不只僅是避免重複建設，更核心的是要以此保證業務功能和數據的一致性。
服務目錄庫中的服務能夠按照服務類型以及服務角色來進行組織。服務類型請參照服務化分層架構內容裏的描述；服務角色包含任務服務角色、實體服務角色和決策服務角色，請參照後面小節描述。
2、服務設計原則
面向服務化的架構的其中一個成功的關鍵是建立一個具有完整業務語義的服務集合以便於能夠方便一塊兒進行組合編排來支撐不一樣的業務流程以及豐富的業務場景。
咱們常常談論各功能域要提供鬆耦合的服務，是由於服務間的鬆耦合是很是重要的，特別是經過減小服務間的依賴以便於服務能夠在不一樣的場景中被複用，以及能夠起到隔離變動影響的做用。可是如何才能儘量的實現這個目標呢？
首先咱們來看下對於服務最重要點是什麼？首先就是這個服務提供了什麼樣的業務功能，其次這個服務對業務有價值的數據產生了那些影響。從這兩個點上咱們就能夠比較容易得出兩種類型的耦合在服務接口設計中是特別重要的：
數據依賴
功能依賴
舉例來講明下：
交易服務協調全部的活動，而後依賴其餘服務來幫助完成流程。交易服務依賴於或者說耦合於用戶服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務等。
爲啥交易服務沒有實現全部的功能？
首先是由於咱們想在其餘高級別流程或者服務中重用底層的能力。
第二是交易服務服務並不負責用戶服務，商品服務，庫存服務，營銷服務、訂單服務以及支付服務。交易服務只是使用它們，而不是負責實現它們。
用戶服務被用做管理客戶信息訪問，它具備惟一的責任來提供、維護和更新客戶信息，這樣作的目的是爲了能夠在任何須要訪問客戶數據服務的地方重用客戶服務。比代碼重用更重要的是隔離或者是集中式訪問客戶信息，由於只有惟一的路徑訪問數據，數據就老是一致的，真正實現 Source Of Truth。所以，儘管有不少服務包含交易服務，購物車，訂單歷史等服務須要訪問客戶服務, 經過鬆耦合的這種模式去管理這些依賴是比較容易被理解的。
經過建立服務來執行用戶管理，商品管理，庫存管理，以及營銷管理等，就能夠在任何能夠用到的地方，執行保持一致性的這些業務功能。
敲黑板：好的服務設計並不只僅是關注重用性，更重要的是要提供一致性, 既包含功能一致性，也包含數據一致性。
那麼下一個問題是你如何決定有哪些服務以及這些服務分別是什麼呢？一樣，你用功能分解和信息隔離組合在一塊兒來決定服務有哪些而且各自是什麼？
對線上交易功能的分解引導去識別用戶、商品、庫存、營銷、訂單以及支付等相關功能服務。
對信息的隔離引導咱們去識別用戶和商品等做爲交易訂單中的共享信息。
面向服務的架構中服務設計的問題須要跨越多個以至於全部的流程中來一塊兒考慮。
所以，服務設計原則基本原則以下：
避免服務間的功能重複
避免服務間的功能缺失
避免數據重複
實現數據的協同訪問
具有統1、一致的方式來執行給定的功能
在服務化設計中，如何實現上述的這些原則呢？答案是提出並回答以下問題：
誰負責這個功能？
這個功能在哪裏被用到的？
誰負責管理這些指定的數據？
誰負責定義和實現那些特別的業務規則
流程中的哪一個步驟具有執行這個任務所須要的特定的知識
這些問題的答案會幫你來識別以下信息：
服務應該作什麼？
服務對什麼負責？
一樣重要的是，識別服務不該該作什麼，而應該依賴其餘的服務來支撐
3、服務顆粒度與類型
咱們一般設計服務時候一個很大的疑惑是個人服務到底要設計成什麼樣的顆粒度，應該更粗粒度一些，仍是更細粒度一些？答案是：沒有一個統一正確的服務顆粒度標準。那怎麼辦？我如何設計個人服務的顆粒度呢？雖然沒有統一的標準，可是咱們能夠依賴下面的因素來決定合適的服務粒度：
誰是服務的潛在消費方？其餘服務，業務流程仍是外部合做方？
服務在哪裏被消費，經過什麼樣的路徑被消費，也就是服務的拓撲結構是什麼？
服務的性能要求是什麼？
服務預期的業務範圍或者邊界是什麼？
在幾乎任何複雜的環境或者系統平臺中，咱們能夠預期到多種多樣類型的服務。這些服務具備不一樣的類型和顆粒度，能夠參考服務化分層中的內容，也能夠見下面的描述：
端到端的業務流程
業務流程一般跨越整個企業或者平臺多個業務域，一般是由底層服務構建而成
平臺業務服務
業務服務是最粗粒度的服務，業務服務提供高度抽象的，組合的業務功能給到平臺或者企業。業務服務的功能和數據同業務流程所須要的業務語義緊密結合。數據整合服務在這個層次提供端到端的業務流程所須要的整合後的數據。
子域服務
子域服務是中等粒度的，他們提供特別針對於每一個業務子域的業務相關服務, 被本域內的不一樣業務服務所使用，可是未必暴露出子域外
子域基礎服務
子域基礎服務一般是最小粒度的服務，他們提供更低層次的服務，用來提供子域內子域業務功能的基本功能支撐
基礎子域服務
子域基礎服務一般也提供教小粒度的服務，用於支撐上層業務功能服務的業務功能完整實現。
基礎架構服務層
基礎架構提供了在更高層級服務構建中細粒度的能力，獨立於任何業務域。這些服務須要和業務相關明確區分開來，例如安全認證，權限管理以及純粹技術編排服務。
4、服務角色
獨立於服務的粒度，職責範圍以及服務建立之外的另一個重要考量或者說是側面是：服務在服務組合或者流程編排中所承擔的角色是什麼？
那麼怎麼來區分不一樣的角色呢？咱們使用關注點隔離的架構原則。例如，咱們在構建應用中就使用了將數據同邏輯隔離做爲重要的概念。這樣不只提供了不一樣關注點解耦的可能以及機會，並且容許採用不一樣的方式，在不一樣的地方來實現這些不一樣的關注點。
對業務流程進行單獨管理的 BPM 就是一個很是好的例子，BPM 做爲另一個關注點分離的例子，將業務流程方案從其餘邏輯中分離出來，可使工做流程能夠在一個特定的層次或者環境內進行執行和管理, 這樣就能夠實現經過快速的創建新的流程模型來快速響應業務的變化。同時面向服務的架構 SOA 提供了將業務服務做爲構建業務流程的基礎構件的功能。業務規則系統 BRMS 一樣也做爲一個關注點分離的例子，將業務規則或者業務決策從其餘應用邏輯中區分開來，這樣業務規則和業務決策也能夠在一個特定的層次被執行和管理，從而就能夠很容易的被變動來支持新的業務需求。這裏，業務規則以及決策服務也是面向服務的機構來暴露出規則和決策服務來支撐規則和決策與業務流程的分離。
一般咱們經過較粗粒度的來定義三大類服務角色來構建不一樣的服務層次：
任務服務角色
任務服務一般實現一個完整的業務功能，既能夠是基本業務功能，也能夠是複雜的業務功能，如計算某個貨品在某個倉的補貨量，或者一個簡單的業務校驗，如此貨品在此倉是否可補。
此服務類型顆粒度範圍較廣，包含從獨立的子域基礎服務到大的平臺業務服務均可以具備任務服務角色，更小顆粒度的服務傾向於具備更通用的目的, 更大的可重用的潛力。業務服務幾乎老是承擔任務服務的角色，一般是小顆粒度服務較大的組合，能夠被設計成支持一個或者更多特定的流程。所以這些服務一般在跨業務流程中普遍複用的潛力更低。可是也是正常的，由於他們一般是有其餘可重用的服務組成的。
一般，具備業務角色的服務是主動服務，經過主動行爲來提供價值
實體服務角色
主要管理訪問業務實體的服務具備這個角色。業務實體的例子如用戶、類目、商品、價格、庫存、購物車，主要對應主要的業務信息。實體一般是中到大型實體，傾向於獨立於任何特定的業務流程, 而可作爲多個不一樣業務流程的組成部分。具備實體服務角色的服務一般經過適配和提供須要的信息來實現任務的方式來支撐任務服務。實體服務一般都具有較大的重用的潛力。
規則 / 決策服務角色
規則 / 決策服務是經過執行業務規則來提供業務決策的服務，如補貨計劃自動審覈服務。
規則 / 決策服務一般用做對複雜問題進行判斷或者支持變化頻繁的業務規則，如複雜且多變的審覈規則等。
規則 / 決策服務一般爲小到中等大小顆粒度，一般用來組裝成更大的服務。規則 / 決策服務是能夠不一樣層次不一樣類型的服務，包括平臺業務服務，子域服務，子域基礎服務等，可是一般狀況下規則 / 決策服服務也來支撐這些服務類型。
咱們經過組合這些不一樣類型的服務角色來提供靈活的業務能力，從而用來支持業務流程內的活動。咱們提供了一些基本原則來幫助咱們進行服務組合以便於幫咱們減小依賴，限制耦合以及最大化靈活性。
服務層次以及組合基本原則：
業務流程的任務經過任務服務實現，業務流程路由的核心規則由規則 / 決策服務來提供，而不是定義在流程網關內。這一塊內容後續詳細說明。
更高層次的任務爲核心的業務服務由其餘更小的服務組成
服務依賴嚴格單向原則，上層服務能夠依賴下層次服務以及同一層次服務，可是下層服務不能夠依賴上層服務
一個任務服務能夠組合規則 / 決策服務、實體服務以及其餘任務服務
可是一個實體服務不容許直接調用其餘實體服務
如今咱們能夠經過豐富的流程，實體和決策服務的集合，能夠建立新的不一樣的服務組合，把規則的靈活可變的好處同服務化架構的模塊化，靈活性以及重用性結合起來做爲業務系統平臺級別的基本架構方式。
服務化如何成功？
1、大規劃
大的規劃首先要明確 2-3 年內的服務化的目標：是快速地靈活支撐業務快跑？仍是業務支撐目的已經初步達成，準備將成功經驗產品化輸出到業界？
基於不一樣的目標的設定不一樣的規劃框架指導：
對於快速靈活支撐業務快跑爲服務化目標，核心指導原則是要要求提高對業務變化支撐的快速反應，產品技術能夠不重複建設的基本原則上，較大程度容許各個子域百花齊放，返回各域主動性去提高對業務的支撐效率，最大程度提高研發效率，對業務的快速支撐。
而對於核心目的是準備將成功經驗輸出到業界，則核心指導原則則務必要求產品化，技術體系化爲首要指導原則，要求統一的可持續發展的技術體系和精益求精的產品設計體系。
大的規劃切記事無鉅細，而是根據長期規劃設定明確的指導性原則和要求，在體系化的基礎上鼓勵協同和創新。
2、小目標
服務化不該該是運動式的大躍進推動，而應該是堅持試點、推廣、總結、擴大試點，從而由點到面，逐步落實的方法，由各域根據規劃的體系化要求，再各自狀況暨各自成熟度來設定各自服務化目標，制定一個個小目標，快速迭代，敏捷式的總結推動。
3、真共識
服務化要從上到下從目標到落地策略統一獲取共識，共識很是重要，要從技術高層到普通開發人員達成清晰明確的方向和落地體系。服務化是一個龐大的，迭代的，漸進的體系化工程，而不是一蹴而就的戰役式定勝負的項目，創建共識的根本是要講清楚服務化的目標、架構、設計、開發背後的清楚的邏輯，讓每一個人想的清楚，聽的明白
4、接地氣
接地氣同達成共識同樣，要用樸素的工程師語言講清楚目標和邏輯，而不是拿各類看上去很是光鮮亮麗的各類名詞來充當檯面，講的人解釋不清楚，聽得人一頭霧水，沒有體系化邏輯來支撐落地，最終很難達到服務化真正的目標的。
借用毛主席在延安文藝座談會上的講話：
「咱們的文藝工做者不熟悉工人，不熟悉農民，不熟悉士兵，也不熟悉他們的幹部。什麼是不懂？語言不懂，就是說，對於人民羣衆的豐富的生動的語言，缺少充分的知識。許多文藝工做者因爲本身脫離羣衆、生活空虛，固然也就不熟悉人民的語言，所以他們的做品不但顯得語言無味，並且裏面經常夾着一些生造出來的和人民的語言相對立的不倫不類的詞句。許多同志愛說「大衆化」，可是什麼叫作大衆化呢？就是咱們的文藝工做者的思想感情和工農兵大衆的思想感情打成一片。而要打成一片，就應當認真學習羣衆的語言。若是連羣衆的語言都有許多不懂，還講什麼文藝創造呢？英雄無用武之地，就是說，你的一套大道理，羣衆不賞識。在羣衆面前把你的資格擺得越老，越像個「英雄」，越要出賣這一套，羣衆就越不買你的帳。你要羣衆瞭解你，你要和羣衆打成一片，就得下決心，通過長期的甚至是痛苦的磨練。」
服務化落地的核心力量是一線工程師同窗們，必定要用樸素的工程師語言講透講明白，讓工程師同窗心中不惑，不能讓工程師同窗來猜，猜來猜去，不少時候目標就偏了，時間就浪費了，信心就磨散了。
5、結硬寨
服務化是一個龐大的，迭代的，漸進的體系化工程，不是快閃戰，不是突襲戰，是場持久戰，必定要有曾國藩的「結硬寨，打呆仗」的耐心和準備，踏踏實實落地迭代推動，小步快跑，在堅持體系化思考的基礎上進行持續總結改進，經過一個接一個戰鬥，一個小勝利接一個小勝利，一個戰役接一個戰役不停的攻城略地的基礎上逐漸邁向成功。
6、Think Fast & Slow
一句話，高效的方式就是慢想、快乾，明確目標，規劃架構，設計實施方案和落地步驟都須要認真的、耐心的思考，理清頭緒，搭建體系化的邏輯支撐，剩下就是執行和落地了。咱們不必定缺乏高執行力的人，可是必定缺乏能獨立思考並體系化行事的人。慢想，快乾提及來容易，但作起來難，要看有沒有耐心，能不能沉得住氣，而不是口號式的蠻幹，回頭看最有效率的必定是，Think Fast， Act Slow。
結尾 & 觀點
整體上來講，面向服務的架構經過應用分層架構的方式來分離業務流程和底層包括運營資源在內的各類資源，來支撐業務靈活性。
面向服務的架構提供的價值以及靈活性依賴於服務分層的質量，服務能夠具備各類各樣的粒度和類型。服務顆粒度很重要，可是知道服務如何被使用同樣重要：服務在支撐業務流程上承擔了三種基本角色：任務服務角色，實體服務角色，決策服務角色。
面向服務的架構很早就做爲軟件業界特別是互聯網架構風格取向，然而服務化卻很難被真正成功的實現，緣由多種多樣，這裏列一下一些相關的與此相關的我的的觀點，不喜能夠隨便噴。
觀點 1：
服務化失敗一般最最根本的問題不在於 HOW：用何種技術來實現它，而在於 WHAT：如何用業務本質的抽象來定義服務，定義分層，也就是首先摸摸揣在你胸口的業務本質 WHY：業務模型以及域模型等，你想清楚了沒有？而後再想一想如何利用服務分層和服務特性來搭建牛 B 的系統平臺
觀點 2：
產品同窗和技術同窗各自在服務化架構承擔什麼角色？我的觀點以下：
業務平臺產品同窗：最核心的角色和職責是業務架構師，也就是你要定義好整個平臺或者你所在域的業務模型，此模型必須能夠完整且明確的表達平臺業務本質。
平臺架構師：最核心要的職責基於上層的業務模型結合各域公共語義來定義好：1. 完整的平臺公共語義模型；2. 定義出各域業務責任邊界原則，用於職責劃分和斷定，從而避免總體業務功能和業務數據不一致以及缺失。
各域架構師：最核心的責任定義所負責域的域模型 (E/R 模型或者領域模型)，而後基於此設計各域應用架構和數據架構。
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。