前言

在這篇文章中，我將演示在決定使用單體架構(gòu)、微服務架構(gòu)和無服務器架構(gòu)時的權(quán)衡的簡化心智模型。目標是突顯每種風格的固有優(yōu)勢和缺陷，并提供關(guān)于何時選擇哪種架構(gòu)風格的指導。

單體架構(gòu)

對于小團隊或項目來說是理想的入門架構(gòu)。它簡單易上手，通常在需要超過一個團隊的規(guī)模之前能夠提供很多收益。

在構(gòu)建單體架構(gòu)時，務必從模塊化開始，即使可能會增加樣板代碼。這意味著構(gòu)建組件并在層之間保持嚴格的邏輯分離（更多詳見Clean Architecture）。

• 通信層 — 服務的外部接口
• 封裝 — 業(yè)務邏輯或用例的清晰接口
• 領域?qū)嶓w — 業(yè)務對象的數(shù)據(jù)表示，僅供內(nèi)部使用
• 架構(gòu)隔離 — 避免實體之間的跨領域連接

優(yōu)勢

?開發(fā)便利性 — 所有代碼都在一起。?部署便利性 — 所有代碼一起部署。?網(wǎng)絡效率 — 所有計算發(fā)生在進程內(nèi)。?成本共享效率 — 每臺服務器上有大型共享的 CPU 和內(nèi)存池。

權(quán)衡

• 組織規(guī)模的限制 — 由于開發(fā)、部署和代碼的緊密耦合，需要協(xié)調(diào)的開銷增加。
• 技術(shù)債務的風險 — 容易采取捷徑，構(gòu)建緊密耦合的代碼。

當您的團隊看起來像上面的插圖時，這表明您應該考慮演進您的架構(gòu)到微服務。開發(fā)中的復雜性增加會高風險地降低質(zhì)量，從而導致生產(chǎn)力減緩。這產(chǎn)生了一個矛盾的效果，即您雇傭的人越多，交付就變得越慢和不可預測。

微服務

對于業(yè)務需求開始增長并且團隊分成多個團隊時，這是理想的架構(gòu)。這個里程碑自然地與將單體架構(gòu)拆分成自然的、上下文邊界的微服務相配合，以便團隊可以更獨立地擴展。

設計你想要的組織，架構(gòu)會追隨著，躊躇著走來

我強烈建議采用Inverse Conway Maneuver策略，打破您的通信模式，否則促使單體的熟悉模式將繼續(xù)像膠水一樣將團隊粘在一起。

優(yōu)勢

• 獨立交付 — 減少依賴關(guān)系。
• 明確所有權(quán) — 實現(xiàn)強大的所有權(quán)模型。
• 組織規(guī)模 — 促進團隊間相對獨立的并行努力。
• 獨立擴展 — 計算隔離允許平臺的各部分獨立擴展。

權(quán)衡

• 協(xié)調(diào)標準 — 標準的變化可能泄漏到架構(gòu)中，降低一致性和整體可維護性。
• 網(wǎng)絡延遲懲罰 — 曾經(jīng)在單個服務中共同存在的進程現(xiàn)在正在進行引入端到端計算的網(wǎng)絡調(diào)用，引入了延遲。
• 資源共享減少 — 曾經(jīng)共享相同 CPU、內(nèi)存和磁盤需求的進程現(xiàn)在部署有自己的專用資源。
• 成本增加 — 與單體相比，每個服務的額外網(wǎng)絡 I/O 和資源會導致額外的成本。

無服務器

對于不需要實時保證的某些工作負載來說，這是理想

的架構(gòu)風格。異步、分布式處理，不要求代碼始終保持熱和立即可用。

截至撰寫本文時，該行業(yè)正在朝著編寫更經(jīng)濟的系統(tǒng)的“綠色”方向發(fā)展，以減少我們計算的碳足跡。我認為這種架構(gòu)風格是生態(tài)系統(tǒng)的一個強大補充，但并不能完全取代它的前輩的必要性。

優(yōu)勢

• 精益擴展 — 僅擴展所需的無服務器函數(shù)。
• 成本效益 — 僅在需要時使用最少的資源部署資源。（警告：僅當計算是間歇性的時候。在計算需要保持熱時，請查看下面的權(quán)衡。）

權(quán)衡

• 資源效率懲罰 — 曾經(jīng)共享相同 CPU、內(nèi)存和磁盤需求的進程現(xiàn)在每個都有自己的最小要求。
• 成本效益差 — 只有在部署時有恒定需求，使每個函數(shù)運行像熱服務器時。
• 網(wǎng)絡懲罰 — 與單體和微服務相比，每個函數(shù)調(diào)用現(xiàn)在都是一個網(wǎng)絡跳躍，而不是作為進程內(nèi)計算共同存在。

隨著時間的推移演進

那么，當您的業(yè)務或產(chǎn)品的需求不斷增長時，您的架構(gòu)演進可能是什么樣子呢？