中臺戰略全解讀：業務中臺建設

從業務到中臺，必須經歷抽象建模的過程。這個過程分爲兩個階段，分別是 0 級抽象中心建模的階段和 1 級抽象組件建模的階段。每個階段採用的建模抽象機制都是實體抽象法。下面以 0 級階段建模抽象爲例進行說明。

首先，我們梳理出企業功能需求，如某飲料企業的功能需求彙總表如圖 6-1 所示。

圖 6-1　功能需求彙總表

其次，找出每一個功能需求所對應的業務對象或實體。這一步需要剝離功能的差異性，抽象功能的共同點，才能保證定義合理。實體分爲兩類：業務實體（叫 “靜態實體” 更容易理解）和過程實體。實體性質相同或者實體結構相似度較高，都可歸納爲同一實體。在實體基礎上，爲了滿足當前功能需求，我們需要定義出系統需要提供的能力。能力就是對實體施加的操作或發出的命令，這裏的能力我們稱爲領域能力。

最後，根據能力的主題、實體的密切關係，定義出主題域（也可以稱爲 “業務域”）。業務域的命名一般由資深業務架構師來定義，以避免出現二義性。基於功能需求的抽象，輸出的產物見表 6-1。

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

業務中臺的 8 個設計原則

業務中臺是一個充滿生命力的個體，它承載業務邏輯、沉澱業務數據、產生業務價值，並隨着業務不斷髮展進化。它的設計遵循如圖 6-3 所示的 8 個原則。

1. 服務松耦合原則

（1）面向接口實現

表 6-1　功能需求抽象表

圖 6-2　中心規劃

圖 6-3　業務中臺設計的 8 大原則

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

（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 可以方便快速地實現分佈式事務。

擴展點機制

業務中臺自身提供了很多配置化功能，支持靈活快速地對業務功能進行擴展。除此之外，擴展點機制提供在不修改現有代碼的情況下，靈活擴展新功能。擴展點機制源於 Java 的 SPI 機制，當業務中臺的某一個業務點遇到新業務邏輯比當前邏輯差別較大時，可以使用擴展點機制來實現。

出處：https://www.infoq.cn/article/AJUmUIo2DvQZYzZi2VLc

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FEU8WVqPuagLmXlUvrOI6w