? ? ? 從業務到中臺，必須經歷抽象建模的過程。這個過程分為兩個階段，分別是 0 級抽象中心建模的階段和 1 級抽象組件建模的階段。每個階段采用的建模抽象機制都是實體抽象法。下面以 0 級階段建模抽象為例進行說明。首先，我們梳理出企業功能需求，如某飲料企業的功能需求匯總表如下圖所示。

? ? ? 其次，找出每一個功能需求所對應的業務對象或實體。這一步需要剝離功能的差異性，抽象功能的共同點，才能保證定義合理。實體分為兩類：業務實體（叫“靜態實體”更容易理解）和過程實體。實體性質相同或者實體結構相似度較高，都可歸納為同一實體。在實體基礎上，為了滿足當前功能需求，我們需要定義出系統需要提供的能力。能力就是對實體施加的操作或發出的命令，這里的能力我們稱為領域能力。最后，根據能力的主題、實體的密切關系，定義出主題域（也可以稱為“業務域”）。業務域的命名一般由資深業務架構師來定義，以避免出現二義性。基于功能需求的抽象，輸出的產物見下表。

? ? ? 劃分出多個主題域后，技術架構師需要結合技術的實現，將領域進行組合規劃出中心。中心的劃分標準主要從實體的聚合度、中心的職責、中心顆粒度、能否獨立運營等方面來權衡。確定中心的過程也就是劃定功能邊界的過程。下圖是某企業的中心劃分結果。

? ? ? 業務中臺是一個充滿生命力的個體，它承載業務邏輯、沉淀業務數據、產生業務價值，并隨著業務不斷發展進化。它的設計遵循如下圖所示的 8 個原則。

? ? ? 一、分布式運行機制?

? ? ? 1.服務松耦合原則?

? ? ? （1）面向接口實現這是服務松耦合的基本要求，即每一個服務都按接口的定義進行實現。服務的消費方不需要依賴某個特定的服務實現，避免服務提供方的內部變更影響到消費方。另外，在服務提供方切換到其他系統時，不影響服務消費方的正常運行。

? ? ? （2）異步事件解耦服務間的事件通信采用異步消息隊列來實現。由于有消息隊列這個中介，因此生產者和消費者不必在同一時間都保持實時處理能力，而且消費生產者也不需要馬上等到回復。

? ? ? （3）服務提供者位置解耦服務消費者不需要直接了解服務提供者的具體位置信息，例如 IP 地址、端口。典型解決方法是服務注冊中心，服務提供者啟動時將自己注冊到服務注冊中心，服務消費者通過服務注冊中心查找具體服務提供者來訪問。同時，服務注冊中心可以提供負載均衡及 fail-over 的能力。

? ? ? （4）版本松耦合消費端不需要依賴服務契約的某個特定版本來工作，這就要求服務契約在升級時盡可能提供向下兼容性。

? ? ? 2.服務依賴原則?

? ? ? （1）有價值的領域模型 價值導向：確保業務中心的服務都與企業的商業理想保持一致，相關聯。 簡捷為美：業務邏輯和流程避免復雜化。 領域洞察：緊貼業務的核心目的，從業務原則指導業務邏輯的設計。?

? ? ? （2）服務間最小依賴 高內聚：同一類服務應歸在一起。 低耦合：服務間保持最小聯系。 能力與接口：業務流程和業務邏輯的操作都作為中心服務實現，而提供給外部調用的接口數據模型都會轉化為服務。 識別通用性：識別出每個通用能力的可擴展的類型，從設計上支持它不斷擴展，并在接口定義上滿足其不斷升級的需求。

? ? ???（3）能力實體具有層次性 能力與接口：分離接口實體與能力實體。 接口實體與限定元素：將接口實體核心元素與接口操作的限定元素分離。 接口實體的層次結構：建設接口實體和上下文限定元素的層次結構。?

? ? ? （4）延遲對技術組件的依賴

? ? ? 捆綁依賴：避免在無關的技術組件之間引入新的依賴。

? ? ? 延遲綁定：在使用點才捆綁依賴關系。

? ? ? 3.服務設計原則?

? ? ? （1）優化遠程調用服務間的遠程調用分為同步調用和異步調用兩種模式。應當分析服務調用場景，選擇較優的調用模式。

? ? ? （2）去掉冗余數據盡量去掉接口實體中客戶端不需要的冗余字段，既能減少網絡開銷，又能避免給前端解析帶去復雜性。

? ? ? （3）設計粗粒度的服務接口服務接口若能與前端一個用例或一個業務場景相對應（粒度較粗），則既能減少遠程調用次數，又能降低學習成本。

? ? ? （4）識別并設計通用的服務接口由于中心服務不限定應用范圍，因此一般要支持不同的應用。但不同應用在功能豐富性上有很大差異，這就決定了服務接口需要盡可能保證廣泛兼容性。譬如，服務接口的參數和返回值必須是被廣泛支持的較簡單的數據類型。

? ? ? （5）隔離服務內部的變化避免服務內部的領域模型直接傳導給客戶端。如未能提供合理的隔離措施，則當服務進行內部重構時，勢必導致客戶端頻繁變化。

? ? ? （6）服務接口先行詳細規定服務與客戶端雙方對接的內容與形式等，對雙方形成強有力的約束和保障。

? ? ? （7）服務接口向下兼容由于應用的廣泛性，在服務公開發布之后就要保證相當的穩定性，不能隨便重構，即使升級也要盡可能考慮向下兼容性。

? ? ? 4.服務命名原則?

? ? ? 強烈建議使用服務使用者專業領域內有意義的名稱，優先選用業務概念而不是技術概念。使用名詞命名服務，使用動詞命名操作。

? ? ? 5.服務顆粒度原則?

? ? ? 服務應是內聚而完整的，能夠獨立完成一個職責。在服務內部可以是由多個邏輯上密切相關的代碼塊共同組成。

? ? ? 6.服務的無狀態性原則?

? ? ?微服務體系的基本要求是服務無狀態。無狀態的服務是可伸縮、高可用性的基礎。

? ? ? 7.服務操作設計原則?

? ? ? 操作表示業務動作，應當使用具體的業務含義而不是泛型操作來定義操作。相關的最佳實踐如下：

• 重要的服務不能依賴非重要服務。
• 任何服務調用都要設定超時時間。
• 任何服務的調用結果只有三種可能：成功、失敗或未知。
• 能異步調用的服務盡量使用異步調用，從而提高系統響應速度，降低系統之間的耦合性。
• 系統拆分時，粒度大小以一個系統 3～8 個開發人員維護為宜。
• 系統拆分時，往往先拆分數據服務層，因為數據服務層通常是復用性高的一層。
• 服務的實現不能有單點。
• 線上遵循 fast-fail 原則，避免服務調用時間過長，導致性能下降。fast-fail 原則是只要發生錯誤，則調用立即返回。
• 需要對高壓場景下的服務調用鏈路進行特殊處理，可采用將鏈路縮短、預熱等方式。
• 服務設計過程中，要避免同類服務由不同服務單元提供。
• 服務要做到向后兼容，如果無法做到，則需要采取管控機制確保服務消費者升級服務。
• 服務化架構的變化要使組織的架構能適應這種變化。
• 在部署服務單元時，要將讀服務和寫服務分離，將核心服務和非核心服務分離，以保證整個服務單元的穩定性和可靠性。
• 服務化時，要同時考慮安全。
• 靜態資源也可以實現服務化，實現靜態資源與動態資源分離，從而提高性能。
• 通過在外層系統埋點，可以實現面向終端用戶服務的精細管理，比如服務的容量、服務的性能等。
• 需要將每個業務領域的通用規則沉淀成服務。

? ? ? 8.服務約束原則 上可依賴下。?

? ? ? 下不可依賴上。 上可跨級依賴下。 平級可允許單向調用，堅決禁止循環依賴。 高級別不可依賴低級別。 簡單就是美。 重要的服務不能依賴非重要服務。?

? ? ? 二、分布式運行機制?

? ? ? 中臺采用微服務風格進行建設，每一個業務中心都是獨立部署的，因此分布式運行機制是保障業務中臺正常運行的基礎。無狀態的微服務易于擴展和部署，對彈性伸縮、灰度發布等互聯網場景有良好的支持。同時微服務架構也帶來了復雜性，一個微服務應用一般由多個服務組成，每個服務又有多個實例，因此一套中臺系統部署上線后，至少有幾十個節點提供服務。為了管理眾多的微服務，我們需要解決諸如如何使配置一致、如何實時監控、如何發現新服務、錯誤如何定位等問題。

? ? ? 1.服務注冊與發現?

? ? ? 服務注冊是服務發現機制的核心，服務實例將自己的服務信息（包括網絡 IP、端口、服務名）注冊到服務注冊中心，服務注冊中心將服務信息以及服務健康狀態通過 API 暴露出來。服務消費方通過注冊中心獲取到服務實例信息，并通過 IP、端口、服務名的組合去請求服務提供方提供的服務。除了完成以上核心功能外，服務注冊與發現還需要實時監控服務實例的健康狀態，一旦服務實例不可用，將通知各服務消費方移除無效服務實例。另外，一個服務可能存在多個服務實例，需要根據不同的負載均衡算法來保持服務調用的均衡。

? ? ? 2.彈性伸縮?

? ? ? 在分布式集群里通過服務探針，可以監控應用和服務容器的狀態，自動調整服務實例的數量。擴容，在監控到服務容器出現瓶頸，包括負載、CPU、RT 指標都出現緊張時，能夠自動增加應用實例到集群中。縮容，在監控到服務容器負載減少出現資源浪費時，自動釋放服務實例減少成本。調整彈性伸縮的規則支持用戶靈活配置。

? ? ? 3.限流降級?

? ? ? 在互聯網應用場景下，用戶的訪問并不總是均勻平穩的，時常會出現瞬時的高峰，比如活動期間。分布式應用服務需要提供限流功能，時刻感知流量的變化，并做出相應調整。限流的策略可分為限制訪問的絕對數量和控制流速（整流）。整流的算法有令牌桶算法，限制總數可通過設置規則來實現。降級是指某個服務被調低級別后，本服務的消費者在調用時即刻返回失敗，這樣服務實例將不會被調用。當然，也可以設置一個默認返回值。降級的規則支持用戶靈活配置。

? ? ? 4.灰度發布

? ? ? ?灰度發布的技術用于兩個不同版本同時在線上并行的情形，既可用于業務試錯，也可用于版本發布。一旦確認新版本達到目的，就可以平滑地從舊版本切換到新版本上。灰度發布需要解決兩個方面的問題，才能順利達成目的。

? ? ? （1）多版本部署多版本部署分為客戶端部署和服務端部署兩個方面。客戶端如果是原生系統，可以用熱更新技術實現，比如 Android 的 CodePush。客戶端如果是 H5，則需要在服務器端部署一套 CSS 和頁面。服務端部署要求應用服務、中臺服務都要單獨部署一套，通過版本來區分。如果需要對 MQ 的數據消費進行隔離，則需要重新定義 Topic 或 Tag。

? ? ? （2）流量切分流量切分包括入口流量切分和中臺服務流量切分。入口流量的切分策略通常包括按服務器權重、IP 地址段或用戶標簽等來切分流量。中臺服務流量切分通過分布式服務發現機制，植入流量切分規則，控制流量的方向。

? ? ? 5. 消息隊列服務?

? ? ? 消息隊列服務是互聯網應用場景下非常重要的一個技術中間件。在業務上，通過消息隊列既可以提高用戶體驗，又可以支撐 IM 業務等；在技術上既可以解耦系統，又可以削峰填谷等。消息隊列具有高性能、高可用、最終一致性等技術特點，是技術架構的重要組成部分。

? ? ? （1）異步通信消息發送方將耗時較長且無須實時處理的操作封裝為消息，發送給消息隊列服務。發送方無須等待消息被消費方處理完成，可以繼續做其他事情。消費方則可以按自己的節奏完成消息的消費。異步通信可用于系統間的解耦，各系統獨立自主，互不影響；也可用于減少請求響應時間，提升用戶體驗。

? ? ? （2）高可用消息隊列服務以集群的方式部署，常見的有 1 主多備或 2 主 2 備等。消息服務接收到消息后，會同時分發給多個備份服務各自創建一個備份。當一臺消息隊列服務掛掉后，另一臺消息備份服務可以無縫對接，及時提供服務。在 RPC 調用方面，提供了負載均衡、服務注冊與發現功能，保證了消息隊列服務在高并發場景下的高可用。

? ? ? （3）高可靠消息隊列服務提供了極高的可靠性，不過應用開發時還需要統一提供 retry 機制，進一步提高可靠性，降低應用開發的復雜性。消息隊列服務在收到消息后，會立即執行消息的持久化處理。比較常見的持久化方式包括存儲到文件和存儲到數據庫兩種。持久化機制包括同步雙寫和異步復制，保證了數據的高可靠性。

? ? ? （4）基于消息的最終一致性使用半消息技術，保證只要一個事件發生后，關聯的結果事件一定會發生。半消息解決了如下問題：

? ? ? 事件發生后，事件消息發送卻失敗；

? ? ? 事件消息發送成功后，消息代理推送給消息消費方卻失敗；

? ? ? 消費方重復消費此消息。

? ? ? 使用半消息技術，在事件發生前，先成功發送一個半消息，這樣就保證了事件發生的消息一定能夠發送成功。消息代理增加了事件結果查詢功能，保證了事件觸發成功后一定將消息推送給消費方。消息代理保證消息推送至少 1 次，但要求消費方自己實現冪等性，避免出現異常。冪等性的保證，可以通過為每一個事件創建唯一 ID，消費方增加一個過濾服務，每處理一個事件都會通過存儲這個事件 ID 來實現。當消費方收到事件消息后，過濾服務會查詢本事件 ID 是否已經消費過。

? ? ? 6.分布式事務

? ? ? ? 分布式事務技術（DTP）用于保證跨多個資源事務的一致性，目前 X/Open XA 標準已由眾多廠家實現來支持分布式事務。DTP 模型的典型應用場景是兩階段提交協議，多個資源管理器（RM）由一個事務管理器（TM）進行管理，事務管理器控制著全局事務和分支事務。DTP 模型分別通過準備階段和提交階段來協作完成全局事務：準備階段，由 TM 通知各 RM 準備事務，并接收 RM 的準備結果；提交階段，由 TM 通知各 RM 提交分支事務，并接收 RM 的執行結果。RM 執行結果都成功，那么 TM 返回成功，如果任意一個 RM 執行失敗，原則上 TM 都會執行回滾。但在實踐過程中，RM 失敗的情況也有不同，TM 可按照客戶的需要判定是否回滾所有事務。目前，各大云廠商都提供了分布式全局事務，其中阿里云的 GTS 已經實現了分布式全局事務。在應用場景涉及的系統和步驟不是特別多的情況下，GTS 可以方便快速地實現分布式事務。