前言

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

單體架構

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

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

• 通信層 — 服務的外部接口
• 封裝 — 業務邏輯或用例的清晰接口
• 領域實體 — 業務對象的數據表示，僅供內部使用
• 架構隔離 — 避免實體之間的跨領域連接

優勢

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

權衡

• 組織規模的限制 — 由于開發、部署和代碼的緊密耦合，需要協調的開銷增加。
• 技術債務的風險 — 容易采取捷徑，構建緊密耦合的代碼。

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

微服務

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

設計你想要的組織，架構會追隨著，躊躇著走來

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

優勢

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

權衡

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

無服務器

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

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

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

優勢

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

權衡

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

隨著時間的推移演進

那么，當您的業務或產品的需求不斷增長時，您的架構演進可能是什么樣子呢？