來源：小技術君

前言

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

單體架構

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

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

•通訊層 — 服務的外部介面•封裝 — 業務邏輯或用例的清晰介面•領域實體 — 業務物件的資料表示，僅供內部使用•架構隔離 — 避免實體之間的跨領域連線

優勢

•開發便利性 — 所有程式碼都在一起。•部署便利性 — 所有程式碼一起部署。•網路效率 — 所有計算發生在程式內。•成本共享效率 — 每臺伺服器上有大型共享的 CPU 和記憶體池。

權衡

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

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

微服務

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

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

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

優勢

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

權衡

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

無伺服器

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

的架構風格。非同步、分散式處理，不要求程式碼始終保持熱和立即可用。

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

優勢

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

權衡

•資源效率懲罰 — 曾經共享相同 CPU、記憶體和磁碟需求的程式現在每個都有自己的最小要求。•成本效益差 — 只有在部署時有恆定需求，使每個函式執行像熱伺服器時。•網路懲罰 — 與單體和微服務相比，每個函式呼叫現在都是一個網路跳躍，而不是作為程式內計算共同存在。

隨著時間的推移演進

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