前言

談到軟件系統(tǒng)設(shè)計(jì)的方法論，在代碼層面，有我們熟悉的23種 設(shè)計(jì)模式 （design pattern），對(duì)應(yīng)到架構(gòu)層面，則有所謂的 架構(gòu)模式 （architecture pattern）。它們分別從微觀和宏觀的角度指導(dǎo)著我們?cè)O(shè)計(jì)出良好的軟件系統(tǒng)，因此，作為一個(gè)軟件工程師，我們不僅要熟悉設(shè)計(jì)模式，對(duì)常見(jiàn)的架構(gòu)模式也要熟稔于心。正如看到一個(gè)設(shè)計(jì)模式的名字腦里就能浮現(xiàn)出大致的結(jié)構(gòu)圖，當(dāng)我們看到一個(gè)架構(gòu)模式的名字時(shí)，也要馬上想到對(duì)應(yīng)的架構(gòu)圖及其基本特點(diǎn)。比如，當(dāng)談到分層架構(gòu)時(shí)，我們就應(yīng)該想起它的架構(gòu)圖是怎樣的、有哪些出色的架構(gòu)特征（architecture characteristics）、系統(tǒng)是如何部署的、數(shù)據(jù)存儲(chǔ)的策略是哪種、等等。

一般地，架構(gòu)模式大致可以分成兩類(lèi)， 單體架構(gòu) （monolithic architecture）和 分布式架構(gòu) （distributed architecture）。本系列文章將會(huì)介紹以下8種常用的架構(gòu)模式：

單體架構(gòu)

• 分層架構(gòu)（Layered architecture）
• 管道架構(gòu)（Pipeline architecture）
• 微內(nèi)核架構(gòu)（Microkernel architecture）

分布式架構(gòu)

• 基于服務(wù)的架構(gòu)（Service-based architecture）
• 事件驅(qū)動(dòng)架構(gòu)（Event-driven architecture）
• 基于空間的架構(gòu)（Space-based architecture）
• 面向服務(wù)的架構(gòu)（Service-oriented architecture）
• 微服務(wù)架構(gòu)（Microservices architecture）

軟件設(shè)計(jì)中的謬誤

在介紹架構(gòu)模式前，我們先談?wù)勡浖O(shè)計(jì)中的 謬誤 （fallacy）。所謂謬誤，就是在設(shè)計(jì)軟件系統(tǒng)，特別是分布式系統(tǒng)時(shí)，我們先入為主地假設(shè)它們是正確，但實(shí)際上并非如此的一些觀念。這些觀念都是我們?cè)谠O(shè)計(jì)軟件時(shí)考慮不周的體現(xiàn)。

謬誤1：網(wǎng)絡(luò)是可靠的

網(wǎng)絡(luò)是不可靠的

很多軟件工程師常常假設(shè)網(wǎng)絡(luò)是可靠的，但實(shí)際并非如此。相比20年前，現(xiàn)在的網(wǎng)絡(luò)會(huì)可靠很多，但是仍然具有很大的不確定性。如上圖所述，Serivce B可能完全是正常運(yùn)行的，但是因?yàn)榫W(wǎng)絡(luò)的問(wèn)題，Service A發(fā)出的請(qǐng)求無(wú)法到達(dá)Service B。一種更糟糕的場(chǎng)景是，Service B可以收到Service A的請(qǐng)求，并處理了相關(guān)的數(shù)據(jù)，但是網(wǎng)絡(luò)問(wèn)題導(dǎo)致了Service A無(wú)法收到Service B的響應(yīng)，從而造成了 數(shù)據(jù)不一致 。網(wǎng)絡(luò)的不可靠也是為什么系統(tǒng)中常常出現(xiàn)服務(wù)通信超時(shí)、服務(wù)熔斷等的原因。

總而言之，如果假設(shè)網(wǎng)絡(luò)是可靠的，那么我們?cè)O(shè)計(jì)出來(lái)的軟件系統(tǒng)將會(huì)是不可靠的。

謬誤2：時(shí)延是0

時(shí)延不為0

如上圖所示，服務(wù)內(nèi)組件間的函數(shù)/方法級(jí)別的調(diào)用，耗時(shí)是微妙，甚至是納秒級(jí)別；但是服務(wù)間的遠(yuǎn)程調(diào)用（比如REST、消息隊(duì)列、RPC），耗時(shí)會(huì)是微秒級(jí)別，甚至在異常場(chǎng)景會(huì)達(dá)到了秒級(jí)！在設(shè)計(jì)系統(tǒng)，特別是分布式系統(tǒng)時(shí)，時(shí)延是一個(gè)無(wú)法被忽視的因素，我們必須清楚系統(tǒng)的平均時(shí)延，否則設(shè)計(jì)出來(lái)的方案可能根本不可行。比如，假設(shè)系統(tǒng)中服務(wù)間通信時(shí)延為100ms，如果一個(gè)請(qǐng)求的調(diào)用鏈涉及到10個(gè)服務(wù)，那么該請(qǐng)求的時(shí)延將會(huì)是1000ms！這么高的平均時(shí)延對(duì)于一般系統(tǒng)來(lái)說(shuō)是完全無(wú)法接受的。

進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，考慮平均時(shí)延還不夠，更重要的是95th和99th百分點(diǎn) 。一個(gè)系統(tǒng)的平均時(shí)延可能僅僅只有數(shù)十毫秒，但是95th百分點(diǎn)的時(shí)延卻達(dá)到了數(shù)百毫秒，很多時(shí)候，這也恰恰成為了拖垮整系統(tǒng)性能的那塊“短板”。

謬誤3：帶寬是無(wú)限的

帶寬是有限的

在單體架構(gòu)中，業(yè)務(wù)流程都在單服務(wù)內(nèi)閉環(huán)，消耗的帶寬很少甚至為0，因此帶寬并不是主要關(guān)注點(diǎn)。一旦將系統(tǒng)拆分成分布式架構(gòu)，一個(gè)業(yè)務(wù)流程可能涉及多個(gè)服務(wù)間的通信，帶寬就成了必須考慮的因素。 帶寬的不足，會(huì)導(dǎo)致網(wǎng)絡(luò)變慢，從而影響系統(tǒng)的時(shí)延（謬誤2：時(shí)延是0）和可靠性（謬誤1：網(wǎng)絡(luò)是可靠的） 。

如上圖所示，假設(shè)在一個(gè)Web系統(tǒng)中，Service A負(fù)責(zé)處理前端請(qǐng)求，Service B負(fù)責(zé)管理用戶(hù)信息（包括姓名、性別、年齡等45個(gè)屬性）。Service A每處理一個(gè)請(qǐng)求都需要向Service B查詢(xún)用戶(hù)姓名（200 bytes），而在一次請(qǐng)求中，Service B卻返回了用戶(hù)的所有信息（500 kb）。如果系統(tǒng)每秒處理2000次請(qǐng)求，每次請(qǐng)求消耗500 kb帶寬，那么每秒消耗的總帶寬會(huì)是1 Gb！如果Service B僅僅返回必須的姓名，那么同等條件下，每秒消耗的總帶寬僅僅是400 kb。

此類(lèi)問(wèn)題就是所謂的 stamp coupling ，解決方法也很多，比如在請(qǐng)求中添加屬性選擇，使用GraphQL替代REST。 相比于這些技術(shù)手段，更重要的是確定服務(wù)間通信所需的最小數(shù)據(jù)集，并在進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)將其作為一個(gè)重點(diǎn)關(guān)注的因素 。

謬誤4：網(wǎng)絡(luò)是安全的

網(wǎng)絡(luò)是不安全的

VPN、防火墻等的廣泛使用，使得很多工程師在設(shè)計(jì)系統(tǒng)時(shí)忽略了“ 網(wǎng)絡(luò)是不安全的 ”這一重要原則。特別是從單體架構(gòu)演進(jìn)到分布式架構(gòu)以后，系統(tǒng)被攻擊的概率將會(huì)大大增加。 因此，在分布式系統(tǒng)中，每個(gè)服務(wù)都必須是安全的endpoint，這樣才能確保任何未知或惡意的請(qǐng)求都被攔截掉 。當(dāng)然，安全是有代價(jià)的，這也是像微服務(wù)架構(gòu)這類(lèi)細(xì)服務(wù)粒度的系統(tǒng)，一次業(yè)務(wù)請(qǐng)求中調(diào)用鏈過(guò)長(zhǎng)后性能極速下降的重要原因。

謬誤5：網(wǎng)絡(luò)拓?fù)湟怀刹蛔?/h3>

網(wǎng)絡(luò)拓?fù)涫菚r(shí)常變化的

這里的網(wǎng)絡(luò)拓?fù)渲傅氖窍到y(tǒng)運(yùn)行時(shí)所涉及到的網(wǎng)絡(luò)設(shè)備，包括所有的路由器、防火墻、集線器、交換機(jī)等。很多工程師會(huì)假設(shè)網(wǎng)絡(luò)拓?fù)涫枪潭ǖ模欢⒎侨绱恕?/p>

假設(shè)如下場(chǎng)景，為架構(gòu)師的你在周一早上回到公司后，發(fā)現(xiàn)組內(nèi)同事都在為系統(tǒng)中所有的服務(wù)間通信都在不斷出現(xiàn)響應(yīng)超時(shí)現(xiàn)象而抓狂，但奇怪的是周末并沒(méi)有做服務(wù)變更。經(jīng)過(guò)幾個(gè)小時(shí)的攻關(guān)后，你發(fā)現(xiàn)周一凌晨2點(diǎn)時(shí)有過(guò)一次網(wǎng)絡(luò)升級(jí)，而恰恰是這次“次要”的網(wǎng)絡(luò)升級(jí)，推翻之前設(shè)計(jì)系統(tǒng)時(shí)的時(shí)延假設(shè)，從而觸發(fā)了本次事故。

因此， 軟件工程師也需要與網(wǎng)絡(luò)管理員時(shí)常聯(lián)系，確保在每次網(wǎng)絡(luò)升級(jí)前都明確網(wǎng)絡(luò)拓?fù)涞淖兏c(diǎn)，從而做出相應(yīng)的調(diào)整 。

謬誤6：只有一個(gè)網(wǎng)絡(luò)管理員

網(wǎng)絡(luò)管理員往往不止有一個(gè)，特別是在“云”時(shí)代，數(shù)據(jù)中心分散在多個(gè)地域，理所當(dāng)然也存在著多個(gè)局域網(wǎng)。運(yùn)行在“云”上的系統(tǒng)很有可能跨越多個(gè)數(shù)據(jù)中心，因此工程師們應(yīng)當(dāng)感知各個(gè)數(shù)據(jù)中心的網(wǎng)絡(luò)管理員對(duì)網(wǎng)絡(luò)的相關(guān)操作，提前做出應(yīng)對(duì)措施，避免出現(xiàn)因網(wǎng)絡(luò)拓?fù)渥兏ㄖ囌`5：網(wǎng)絡(luò)拓?fù)湟怀刹蛔儯┒鴮?dǎo)致的服務(wù)通信超時(shí)，甚至觸發(fā)服務(wù)熔斷。

謬誤7：通信成本為0

通信成本不為0

這里的通信成本并非指網(wǎng)絡(luò)時(shí)延，而是指每增加一次服務(wù)間調(diào)用所導(dǎo)致的錢(qián)的花銷(xiāo)。很多工程師在設(shè)計(jì)系統(tǒng)時(shí)常常忽視掉通信成本，大家都在鼓吹分布式架構(gòu)相對(duì)了單體架構(gòu)的優(yōu)越性，卻忘記了它帶來(lái)的服務(wù)器、防火墻、網(wǎng)關(guān)等硬件的數(shù)量增加，這些都是白花花的銀子。

因此，在進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，我們也應(yīng)該將硬件資源和網(wǎng)絡(luò)拓?fù)浼{入考慮因素。

謬誤8：網(wǎng)絡(luò)是同質(zhì)的

網(wǎng)絡(luò)并非同質(zhì)的

很多工程師都會(huì)假設(shè)網(wǎng)絡(luò)是同質(zhì)的，也就是所有的網(wǎng)絡(luò)設(shè)備都來(lái)自同一硬件廠商，這當(dāng)然也是一個(gè)謬誤。實(shí)際上， 一個(gè)大的通信網(wǎng)絡(luò)中，硬件設(shè)備往往來(lái)自于不同的廠商，這得益于網(wǎng)絡(luò)協(xié)議標(biāo)準(zhǔn)的統(tǒng)一 。廠商間設(shè)備的協(xié)作測(cè)試畢竟不會(huì)太充分，在一些特殊場(chǎng)景下極有可能存在網(wǎng)絡(luò)丟包，從而影響了網(wǎng)絡(luò)的可靠性（謬誤1：網(wǎng)絡(luò)是可靠的）、時(shí)延（謬誤2：時(shí)延是0）以及帶寬（謬誤3：帶寬是無(wú)限的）。

一切從“大泥球”開(kāi)始

“大泥球”架構(gòu)是著名的反模式架構(gòu)，最初在1997年由Brian Foote 和 Joseph Yoder提出。在“大泥球”架構(gòu)里，系統(tǒng)沒(méi)有進(jìn)行內(nèi)部的模塊劃分，代碼耦合嚴(yán)重，調(diào)用關(guān)系混亂，就像一個(gè)大的泥球。如上圖所示，每一個(gè)點(diǎn)代表一個(gè)類(lèi)，紅線則表示類(lèi)之間的耦合關(guān)系。這樣的架構(gòu)對(duì)需求變更極不友好，往往牽一發(fā)而動(dòng)全身，而且在部署、可測(cè)試性、性能等方面也存在著很多問(wèn)題。所有的架構(gòu)師都在極力避免“大泥球”的出現(xiàn)，但很不幸的是，它仍然在實(shí)際項(xiàng)目中很常見(jiàn)，特別是項(xiàng)目伊始，代碼質(zhì)量和結(jié)構(gòu)還沒(méi)被嚴(yán)格管控起來(lái)前。

有反模式的出現(xiàn)，必然就有解決它的方法，這便是架構(gòu)模式，從下一篇文章開(kāi)始，我們將逐個(gè)介紹常見(jiàn)的8種架構(gòu)模式。

總結(jié)

跟設(shè)計(jì)模式類(lèi)似，架構(gòu)模式是軟件工程師們多年來(lái)在架構(gòu)設(shè)計(jì)方面的經(jīng)驗(yàn)總結(jié)。每種架構(gòu)模式并沒(méi)有絕對(duì)的優(yōu)劣之分，我們不能說(shuō)微服務(wù)架構(gòu)就一定比單體分層架構(gòu)優(yōu)越，它們都有著各自的應(yīng)用場(chǎng)景。分布式架構(gòu)比單體架構(gòu)有著更好的可擴(kuò)展性、容錯(cuò)性，但也帶來(lái)了更高的復(fù)雜性，比如分布式事務(wù)。因此，我們應(yīng)該熟知各個(gè)架構(gòu)模式的特點(diǎn)，這樣才能在特定的業(yè)務(wù)場(chǎng)景使用合適的架構(gòu)模式。