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