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