架構設計的三個原則
在進行架構設計時，我認為需要遵循如下原則：
- 一致原則
- 簡單原則
- 演進原則
一致原則
一致性是軟件架構質量原則的根基，遵循一致原則的軟件架構可以有效地保證整個架構解決方案的清晰直接，降低了解決方案的復雜度。尤其對于一個大規模系統，往往需要多個團隊共同開發完成，如果不遵循一致原則，就會導致整個平臺的建設缺乏完整性和規范性，各個子系統各自為政，業務功能重復開發，技術實現五花八門，服務集成復雜低效，信息冗余制造出知識壁壘。
一致原則具體體現為：
(1) 架構風格的一致性
針對相同的業務復雜度和技術復雜度，要形成統一的架構風格。例如，對外公開的業務能力采用微服務架構風格，保證各個服務的高內聚低耦合，確保了整個系統的可擴展能力;數據采集、治理和分析業務采用基于Lambda架構模式的大數據架構風格，為數據的處理建立批處理層與速度處理層，滿足不同業務場景的數據需求;服務之間的異步消息協作采用事件驅動架構風格，保證服務之間消息傳遞的高效性與實時性，提高整個系統的響應能力。
(2) 技術選型的一致性
針對相同或相似的問題，應采用相同的方案和技術，從而使得開發人員在掌握了其中一種解決方案后，針對相似的問題，可以推導出相同的解決方案，降低了方案的復雜度，規避了重復開發，降低了代碼的維護成本。以微服務架構為例，技術選型涉及的內容主要包括微服務組件、日志處理、權限管理、分布式事務、數據庫訪問、消息通信機制、緩存技術、安全策略、開發語言、框架版本、監控運維，同時，還要求開發團隊遵循一致的編碼規范。
簡單原則
軟件架構的目的就是為了控制軟件系統的復雜度。分析軟件系統的復雜度成因，主要來自規模、結構和變化。
對于規模引起的復雜度，可以通過“分而治之”的思想來解決，也就是將整個系統按照業務維度拆分為多個細小而簡單的模塊(組件或服務)，每個服務的規模都是團隊或團隊成員可以控制的。
結構引起的復雜度取決于參與協作的模塊(組件或服務)的數量，數量越多，模塊之間的關系就越復雜，因為協作產生的依賴很容易讓整個系統變得混亂而無序，增加了開發和維護的成本。要降低復雜度，就需要清晰地定義模塊的邊界，合理地分配職責，以減少不必要的依賴關系;同時，定義一致而穩定的協作接口，讓模塊之間的協作變得有序，清晰地體現彼此之間的調用鏈，明確消息數據的傳遞方向。
需求的變化總是會帶來解決方案的調整，最終使得持續變化的解決方案變得越來越復雜。如何有效地應對需求變化?一方面需要團隊提前識別出可能發生變化的熱點功能，另一方面也需要注意避免對未來做出過度設計。若能識別出變化的熱點功能，就能通過封裝或抽象的設計原則，讓實現方案盡可能具有可擴展能力，將變化產生的影響降到最低。然而，未來的變化總是不可預測的，如果不能確定未來是否會發生變化，則不要引入太多的間接和抽象，形成過度設計，增加了解決方案的復雜度。
遵循簡單原則的架構體現為：
- 引入領域驅動設計的限界上下文模式幫助合理地識別微服務，明確微服務之間的協作模式，確定業務需求與微服務之間的映射關系，減少不必要的微服務協作;
- 采用前后端分離，避免了前端用戶體驗復雜度與后端業務復雜度之間混合導致的復雜度疊加，也可以保證前、后端開發團隊明確前后端協作的接口，進行并行開發;
- 保持模塊之間接口的松耦合，從架構上考慮數據分析場景與業務處理場景的分離，以定義數據平臺的邊界，驅動出數據交換的接口，確定數據平臺和業務服務之間的協作方式;
- 識別復用的業務能力：站在產品高度和全面視角分析業務能力，將滿足單一職責的業務能力封裝為高內聚的服務或組件，完成功能的復用，降低系統的代碼規模，保證了系統的簡單性。
演進原則
架構設計不是一蹴而就的，由于需求會不斷發生變化，架構設計也需要針對變化的需求做出調整。由于架構做出的設計和決策往往是一個軟件系統最為重要的部分，對架構做出的調整成本和難度都比較大，因此，在進行架構設計時，應考慮解決方案的演進能力，即能夠隨著需求的變化以最小的修改成本實現架構方案的不斷演進。
遵循演進原則的架構應滿足：
(1) 響應變化的能力
演進能力的一個體現是響應變化的能力，一個設計原則是將變化產生的影響控制到最小范圍。這一原則確定了架構方案需要按照變化的方向進行模塊的劃分，從而順應變化，同時，保證業務復雜度與技術復雜度的正交關系，避免業務的變化影響到技術實現的變化，反之亦然。我們可遵循企業架構的設計思想，根據不同的觀察視角將整個系統架構劃分為業務架構、應用架構、數據架構和技術架構。其中，為了降低變化影響，讓系統的應用架構和數據架構對準業務架構，即按照業務能力對系統的模塊(組件或服務)進行職責劃分，同時保證每個應用模塊中的領域模型與數據模型對應;對于技術架構，則通過分層架構模式將業務與技術分離，保證二者的松散耦合。
(2) 職責分配與合理抽象
識別和設計微服務的質量直接影響到系統的演進能力，整個系統需要針對領域進行分析，從業務能力的角度進行功能的職責分配，保證每個微服務是內聚的，同時，通過有效識別變化的熱點，對其利用抽象降低彼此之間的耦合，保證了具體實現的可擴展能力與可替換能力。
(3) 架構模式的運用
對于業務系統而言，通過采用微服務架構模式、事件驅動架構模式和分層架構模式，盡可能保證整個業務系統的松散耦合，提高系統架構的演化能力;對于數據平臺，可采用基于流處理的管道-過濾器模式，通過將數據處理功能拆分為一個個過濾器(processor)，然后在管道中自由組合這些過濾器，滿足整個數據處理流程的需要。這一模式保證了功能的復用性和可擴展性。
【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】
