軟件架構編年史：單體架構

混沌初開，單體始現……

默認的架構風格就是構建一個單體。我的意思是，最開始應用程序就只有一個文件，然後應用程序開始由多個文件組成，從 20 世紀 90 年代開始纔出現由其它應用程序組成的應用 (儘管 20 世紀 80 年代就開始了最初的嘗試)。

◐ 模塊化軟件開發

模塊化編程是 20 世紀 60 年代末到 70 年代間提出的方案。它是從類到更粗粒度代碼單元的明確定義的進化。編程語言使用不同等級的明確性來實現模塊化。

例如，JAVA 在類這個層級的可見性有默認級別和 public 級別，默認級別意味着類只在它所屬的 package (模塊) 內可見，而 public 級別意味着這個類在 package (模塊) 內和 package (模塊) 外都可見。

◐  組件化軟件開發

組件是另一種模塊化風格。如我之前一篇文章 (譯) 所述，組件是按照領域概念劃分的模塊。理想情況下，它們是可以組成應用的獨立的“應用程序”。老生常談的例子是在 Unix 系統中廣泛使用的管道和過濾器架構，例如我們可以使用這樣的命令 ps -ef | grep php。另外的例子就是 Netflix 將微服務作爲應用的組件。

代碼的組織風格和模塊化軟件開發一樣，早在 20 世紀 60 年代末就已經存在了。

◐  現代的單體

現在，單體架構風格就是簡單地意味着所有應用代碼被部署並運行在單一節點的單一進程中。我們認爲它會用到模塊和組件，儘管事實往往並非如此。

這裏有兩個關鍵詞 “部署” 和“節點”要好好地理解。第一個詞 “部署” 的意思是運行時代碼的組織方式，無論代碼在物理上是存儲在一個還是多個代碼庫之中。而第二個詞 “節點” 的意思是即便是在橫向擴展的情況下我們將應用部署到了多個服務器，它依然是一個單體。

在單一節點的服務器上，單體的所有模塊都被集中到同一個內存映像裏，作爲單一節點上的單個進程運行。通過標準進程調用在同一個棧和堆內進行模塊間的通信。單個的內存映像讓應用變成了單體。如果模塊在不同的進程中運行，通信就變成了 IPC (進程間調用)。由於模塊進入了不同的進程邊界，你將要面臨分佈式計算的挑戰。這就進入了微服務的範疇。(感謝 dban 的反饋)。

儘管這種風格聲名狼藉，但它依然可以在大型應用中工作得很好。只是下面這些條件下表現得不足夠好：

• 不同的領域組件需要獨立可伸縮；

• 不同的組件需要不同的編程語言來編寫；

• 獨立可部署，因爲我們的發佈頻率比一個代碼庫的持續交付流水線要快，由於需要等待其它發佈的部署導致自身發佈的部署變慢，或者導致部署隊列增長太快無法及時響應。

這時，我們需要將單體按照面向服務的架構風格 (接下來的文章中將詳細介紹) 拆分成不同的應用程序。

◐  反模式：大泥球 / 意大利麪架構

“大泥球” 又稱意大利麪架構，是這種風格的反模式。這種反模式中，包結構和關係十分模糊，結構化的內聚和封裝完全沒有或極少，依賴毫無規則，子系統很難分辨，也很難修改和重構。系統晦澀、粘滯、脆弱、僵化：就是一個大泥球！

◐  引用來源

• 1997 – Brian Foote, Joseph Yoder – Big Ball of Mud

• 2012 – Len Bass, Paul Clements, Rick Kazman –Software Architecture in Practice

• 2017 – Herberto Graça – Microservices architecture: What the gurus say about it

• 2017 – Herberto Graca –Software Architecture Premises

• 2017* – Wikipedia –Modular programming

• 2017* – Wikipedia –Component-based software engineering

☼ 屐痕處處：2013 年 10 月 26 日攝於香港維多利亞港灣。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fZ9ntZTOC0WCxzAIeo6gVQ