圖解《中台戰略》業務中台設計原則
- 2019 年 10 月 8 日
- 筆記
業務中台是一個充滿生命力的個體，
它承載業務邏輯、
沉澱業務數據、
產生業務價值，並隨著業務不斷發展進化。
它的設計遵循如下圖所示的若個原則：
業務中台設計原則
中台架構中，有服務的調用方和生產方，按角色關係劃分，共有以下四類關係：
1，服務生產方與服務生產方的關係
2，服務生產方與服務消費方之間的關係
3，服務生產方的管理者與服務生產方之間的關係
4，服務生產方與自己之間的關係
這每種關係之間都有對應的設計原則，稍後便看到。
按生產方與消費方之間的調用方式，分三種：
A、基於 HTTP/HTTPS 協議的 RESTFul API 調用（最大應用範圍）
B、基於 Socket/WebSocket 調用
C、基於 SDK 引入調用（受限於技術棧）
其中，A 與 B 的方式是跨語言、跨平台的，應用範圍最多；C 的方式受限於系統、語言等因素，B 的應用範圍小於 A，但研發成本一般又高於 A。所以 A 這種方式，基於 HTTP/HTTPS 協議的 RESTFul API 規範，應用範圍是最廣的。
按三種方式能夠覆蓋的通訊能力表示，如下圖所示：
A 的通用性最大，B 次之，C 最小。稍後便會看到，基於 A 方式的介面的設計原則。
目錄
01 平台角色之間的松耦合原則
02 服務生產方依賴原則
03 服務生產方自身的設計原則
04 服務生產方提供的介面能力的設計原則
05 服務生產之間依賴原則
01 松耦合原則（平台角色之間的設計關係）
（1）面向介面實現（服務生產方與服務消費方之間的調用關係）
這是服務松耦合的基本要求，即每一個服務都按 RESTFul API 進行提供。服務的消費方不需要依賴某個特定的服務程式碼的實現，避免服務提供方的內部變更影響到消費方。在服務提供方切換到其他系統時，不影響服務消費方的正常運行。
RESTFul API 定義的介面具有資源唯一性、無狀態性、和固定性。介面後面的邏輯可以由 Java、.Net、Python 或其它任何語言及框架實現，隨時亦可根據實際需要進行重構升級，但其介面的消費者，即介面的調用者，調用方式、地址、參數是不變的。
（2）非同步事件解耦（服務生產方相互之間的調用）
服務間的事件通訊採用非同步消息隊列來實現。由於有消息隊列這個中介，因此生產者和消費者不必在同一時間都保持實時處理能力，而且消費生產者也不需要馬上等到回復。
什麼是非同步模式？
舉個例子：用戶去快餐店吃飯，一個一個排隊點餐、取餐，這是同步模式；相反，在家通過App點餐，然後去忙別的事，外賣小哥送餐到賣，聽到鈴響，開門取餐，這就是非同步模式。
（3）服務提供者位置解耦（服務生產方之間的關係）
服務消費者不需要直接了解服務提供者的具體位置資訊，例如IP地址、埠。典型解決方法是服務註冊中心，服務提供者啟動時將自己註冊到服務註冊中心，服務消費者通過服務註冊中心查找具體服務提供者來訪問。同時，服務註冊中心可以提供負載均衡及fail-over的能力。
這相當於是提供了一個服務生產方的管理者。
舉個例子：用戶想發快遞，打電話到快遞網點，由網點安排快遞員A、B或C去用戶家裡取件，至於具體是派 A 還是 B，還是 C 去？無所謂。看誰近，看誰有空。快遞員將自己登記到網點，網點通過固定的電話向外提供服務。
（4）版本松耦合（服務生產方當前的自己與過去的自己之間的關係）
消費端不需要依賴服務契約的某個特定版本來工作，這就要求服務契約在升級時儘可能提供向下兼容性。
02 服務生產方依賴原則（服務生產方相互之間的關係）
（1）有價值的領域模型（什麼樣的業務對象應當抽離為獨立服務？）
確保業務中心的服務，都與企業的商業理想保持一致，業務邏輯和流程設計避免複雜化，緊貼業務的核心目的，從業務原則指導業務邏輯的設計。
（2）服務間最小依賴（橫向之間服務生產方之間的關係）
- 高內聚：同一類服務應歸在一起。
- 低耦合：服務間保持最小聯繫。
- 能力與介面：業務流程和業務邏輯的操作都作為中心服務實現，而提供給外部調用的介面數據模型都會轉化為服務。
- 識別通用性：識別出每個通用能力的可擴展的類型，從設計上支援它不斷擴展，並在介面定義上滿足其不斷升級的需求。
（3）能力實體具有層次性（縱向之間服務生產方之間的關係）
- 能力與介面：分離介面實體與能力實體。
- 介面實體與限定元素：將介面實體核心元素與介面操作的限定元素分離。
- 介面實體的層次結構：建設介面實體和上下文限定元素的層次結構。
（4）延遲對技術組件的依賴（服務生產方之間依賴作用的時機）
- 捆綁依賴：避免在無關的組件技術之間引入新的依賴。
- 延遲綁定：在使用時才捆綁依賴關係。
03 服務生產方自身的設計原則
（1）使用非同步模式，優化遠程調用（調用方式）
服務間的遠程調用分為同步調用和非同步調用兩種模式。應當分析服務調用場景，選擇較優的調用模式。
（2）去掉冗餘數據（介面如何定義）
盡量去掉介面實體中客戶端不需要的冗餘欄位，既能減少網路開銷，又能避免給前端解析帶去複雜性。
（3）設計粗粒度的服務介面（介面如何定義）
服務介面若能與前端一個用例或一個業務場景相對應（粒度較粗）則既能減少遠程調用次數，又能降低學習成本。
（4）識別並設計通用的服務介面（介面如何定義）
由於中心服務不限定應用範圍，因此一般要支援不同的應用。但不同應用在功能豐富性上有很大差異，這就決定了服務介面需要儘可能保證廣泛兼容性。譬如，服務介面的參數和返回值必須是被廣泛支援的較簡單的數據類型。
（5）隔離服務內部的變化（封裝）
避免服務內部的領域模型直接傳導給客戶端。如未能提供合理的隔離措施，則當服務進行內部重構時，勢必導致客戶端頻繁變化。
（6）服務介面先行（先行定義介面規範）
詳細規定服務與客戶端雙方對接的內容與形式等，對雙方形成強有力的約束和保障。
（7）服務介面向下兼容（對擴展開放，對修改關閉）
由於應用的廣泛性，在服務公開發布之後就要保證相當的穩定性，不能隨便重構，即使升級也要儘可能考慮向下兼容性。
（8）服務命名原則
強烈建議使用服務使用者專業領域內有意義的名稱，優先選用業務概念而不是技術概念。
使用名詞命名服務，使用動詞命名操作。
（9）服務顆粒度原則
服務應是內聚而完整的，能夠獨立完成一個職責。在服務內部可以是由多個邏輯上密切相關的程式碼塊共同組成。
（10）服務的無狀態性原則
微服務體系的基本要求是服務無狀態。無狀態的服務是可伸縮、高可用性的基礎。
04 服務生產方提供的介面能力的設計原則
操作表示業務動作，應當使用具體的業務含義而不是泛型操作來定義操作。相關的最佳實踐如下：
- 重要的服務不能依賴非重要服務。
- 任何服務調用都要設定超時時間。
- 任何服務的調用結果只有三種可能：成功、失敗或未知。
- 能非同步調用的服務盡量使用非同步調用，從而提高系統響應速度，降低系統之間的耦合性。
- 系統拆分時，粒度大小以一個系統3～8個開發人員維護為宜。
- 系統拆分時，往往先拆分數據服務層，因為數據服務層通常是復用性高的一層。
- 服務的實現不能有單點。
- 線上遵循fast-fail原則，避免服務調用時間過長，導致性能下降。fast-fail原則是只要發生錯誤，則調用立即返回。
- 需要對高壓場景下的服務調用鏈路進行特殊處理，可採用將鏈路縮短、預熱等方式。
- 服務設計過程中，要避免同類服務由不同服務單元提供。
- 服務要做到向後兼容，如果無法做到，則需要採取管控機制確保服務消費者升級服務。
- 服務化架構的變化要使組織的架構能適應這種變化。
- 在部署服務單元時，要將讀服務和寫服務分離，將核心服務和非核心服務分離，以保證整個服務單元的穩定性和可靠性。
- 服務化時，要同時考慮安全。
- 靜態資源也可以實現服務化，實現靜態資源與動態資源分離，從而提高性能。
- 通過在外層系統埋點，可以實現面向終端用戶服務的精細管理，比如服務的容量、服務的性能等。
- 需要將每個業務領域的通用規則沉澱成服務。
05 服務生產之間依賴原則（服務生產方之間的約束關係）
- 上可依賴下；
- 下不可依賴上；
- 上可跨級依賴下；
- 平級可允許單向調用，堅決禁止循環依賴；
- 高級別不可依賴低級別；
- 重要的服務不能依賴非重要服務。
–END–
文章摘自：機械工業出版社《中台戰略：中台建設與數字商業》 2019年9月出版。
《中台戰略》由中國領先的數字商業雲服務提供商阿里系雲徙科技官方出品，從成功要素、建設方法論、架構設計、成熟度模型4個維度詳解業務中台以及數據中台建設思路和方法，成功通過中台幫助近40家龍頭企業實現數字化轉型。
