系統架構合理性的思考

最近牽頭在梳理部門的系統架構合理性，開始工作之前，我首先想到的是如何定義架構合理性？

從研發的角度來看如果系統上下文清晰、應用架構設計簡單、應用拆分合理應該稱之為架構合理。

基於以上的定義可以從以下三個方面來梳理評估：

1、系統的上下文清晰：明確的知道和周圍系統的調用關係，數據同步機制；

2、應用架構設計簡單：架構分層合理，功能定位清晰，不會出現功能邊界之外事情；

3、應用拆分合理：系統內的應用粒度在一個合理的範圍內；應用間調用鏈路不應過長。

系統的上下文清晰

系統上下文圖一詞最早是從Simon Brown的C4模型中借用而來的，該模型”通過在不同的抽象層次重新定義方框和虛線來抽象表達架構的含義“。

C4模型把系統分為四層，每層都代表著不同的視圖架構，關註點不同。第一層，講的系統上下文，系統高層次的抽象。

如下圖顯示個人銀行賬號在瀏覽賬戶過程中發生不同的系統之間交互。 如果把Internet Banking Sysytem 當成我們的目標系統，那麼E-mail System、MarinFrame Banking Sytem 就是它的伴生系統，也可以稱為外部系統，它給Internet Banking Sysytem 提供系統價值，屬於系統外，是黑盒。

系統上下文明確了目標系統和外部系統的關係，它和外部系統一起給目標用戶提供價值。繪製系統上下文的時候，需要註意目標系統和外部系統之間的依賴方向。北向依賴意味著外部系統調用目標系統的服務，需要考慮目標系統定義了什麼樣的服務契約；南向依賴意味著目標系統調用了外部系統的的服務，需要瞭解外部系統的介面、調用方式，通信機制，甚至當外部系統出現故障時，目標系統該如何處理。

除了參考以上的畫法，也可以用業務序列圖表示。它脫胎與UML的序列圖。序列圖可以從左側的角色開始，體現消息傳遞的次序。這隱含這一種驅動力：我們從左側的參與對象開始，尋找與之協作的執行步驟，然後層層傳進地推導出整個完整的協作流程。

企業序列圖，代表了企業級系統的抽象，目標系統和外部系統之間的協作關係，參與的系統是一個完整的整體，所以不需要也不應該參與系統的內部實現的細節，消息的方向更多的代表系統的責任。業務序列圖如下所示：

應用架構設計簡單

應用本身是有架構分層的，Martin Fowler 在《企業應用架構模式》 提出合理的系統分層應該包括表現層，領域邏輯層，數據源層。 表現層主要提供服務，處理用戶請求。領域層是處理邏輯，是系統的核心。數據源層與數據層、消息系統，與其他軟體包通信。

後續發展的領域驅動架構設計，演變成四層，在表現層下加入了應用層，同時把數據源層改為基礎設施層，突破了資料庫管理系統的限制。

基於以上的系統分層，無論你是採用的三層架構還是四層架構，應用代表著功能邊界，提供那些核心的能力，能做那些事情，那些事情不能做。

一個好的實踐經驗是參考領域驅動設計的業務域的方法論，梳理好系統的一二三級域，最多不超過四級，做好各級域的定義。好的域的定義代表著系統能力的邊界，讓你明白那些事情能做，那些事情不能做。

基於以上梳理好的系統業務域的定義和能力邊界，我們在梳理的時候通常會兩類系統，第一類是現有存量的系統且需求迭代相對頻繁的系統，這類系統關鍵是要梳理出有哪些核心的能力，是否在上述系統的域的定義範圍內的，是否其他系統有類似的能力，如果有的話，需要考慮合併。另外還需要考慮核心能力公開化、文檔化，至少讓部門內知道，有地可查，避免系統的重覆造輪子。

遇到第二類系統是存量系統且沒有需求迭代，業務上基本沒有調用量的。這類系統需要和業務溝通是否有下線計劃，是否有類似的系統可以替代，給業務決策提供技術參考。

應用拆分合理

需求開發中，一個項目或者需求的實現可能需要多個目標系統協同來實現，這涉及到目標系統的拆分的粒度，系統拆分成應用的粒度沒有統一標準，但是要在相對合理範圍內，可以參考的因素包括業務規劃，系統調用量級，基於業務規劃的架構設計，部門內的人數及分工。過多過少都是不好的。

如果一個新業務短期內看不到大的發展，在初步規劃應用的時候，可以先粗粒度拆分，部門內人數平均不能應該超過2-3個應用，再多必然面臨著一個需求實現的時候不同系統的切換成本。如果後續業務發展起來，部門內人數增多，因為分工更精細，可以考慮更細粒度的拆分，系統拆分必然會帶來另一個問題，系統之間該如何的協同以及系統的調用鏈路的長度。

基於以上講的系統分層的概念，部門內系統可以分為兩類，一類系統是業務網關，一類是通用的業務能力。業務網關面向用戶，用來協同應用的活動，不包含業務邏輯，不保留業務對象的狀態，相當於領域驅動設計應用層+表現層，有人稱作它為業務SOA，或者BFF層。

通用業務能力相當於領域邏輯層+基礎設施層，作為軟體的核心所在，保留了業務對象的狀態，對業務對象的持久化被委托給基礎設施層，基礎設施層作為其他層的支撐層，實現了和其他系統的通信，實現業務對象的持久化。

在以上兩類系統中，業務網關是依賴通用業務能力層，業務網關是北向依賴，通用業務能力層是南向依賴。 在一個功能的實現不建議鏈路長度不超過2。同時也要註意到系統之間相互依賴的情況，要重視，此點是系統穩定性的風險點。

成本量化：

基於以上三方面分析，梳理出的交付物:1、系統的上下文依賴；2、 系統的業務域定義及能力規劃地圖。3、應用調用鏈路的長度及相互的依賴關係；4、應用拆分粒度合理性的評估；5、系統中能力的下沉或者合併；6、業務量少的系統列表。

其中1-4，可以看作系統的行動指南或者原則，5-6是下一步的行動，更簡單的說是我們常做的系統的關停並轉。在業務部門系統關停並轉還需要考慮到成本問題，做好成本的量化。

首先需要評估關停並轉的付出的成本，其次要評估系統日常維護1-3年的成本包括人力成本和機器資源的成本，前者和後者的三年累計值相減，如果大於零，系統建議暫時不動，如果少於零，可以考慮關停並轉的計劃。

以上是我從研發角度系統架構合理性的思考。

架構合理性如果從業務角度來評估，可能就變成以下三個方面：一是能解決當下業務需求和問題。2、高效完成業務需求: 能以優雅且可復用的方式解決當下所有業務問題。3、前瞻性設計: 能在未來一段時間都能以第2種方式滿足業務，從而不會每次當業務進行演變時，導致架構翻天覆地的變化。

視角的不同必然代表著大家對同一件事情的看法不同。

作者：京東零售 高田林

來源：京東雲開發社區 轉載請註明來源