本文來自Firat Atagun的《架構演化中的軟體設計原則》，文中給出了軟體架構演化過程中出現的4種經典架構，就每種架構，分析了其主要特點並在幾個度量維度給出結論。在文章的最後，Firat Atagun給出了4種架構的多維對比。本文的完整演講稿是架構演化中的軟體設計原則。

1 分層架構

分層架構是最常見的架構，也被稱為n層架構。多年以來，許多企業和公司都在他們的專案中使用這種架構，它已經幾乎成為事實標準，因此被大多數架構師、開發者和軟體設計者所熟知。

分層架構中的層次和元件是水平方向的分層，每層扮演應用程式中特定的角色。根據需求和軟體複雜度，我們可以設計N層，但大多數應用程式使用3-4層。有太多層的設計會很糟糕，將導致複雜度的上升，因為我們必須維護每一層。在傳統的分層架構中，分層包括表現層、業務或者服務層，以及資料訪問層

分層無需知道其他層如何去做，比如業務層無需知道資料訪問層是如何查詢資料庫的，相反，業務層在呼叫資料層的特定方法時，只需關注需要部分資料還是全部資料。這就是我們所說的關注點分離。這是非常強大的功能，每層負責其所負的責任。

分層架構中的核心概念是管理依賴。如果我們使用依賴倒置原則和測試驅動開發(Test Driven Development)，我們的架構會有更好的健壯性。因為，我們要保證所有可能的用例都有測試用例。

我們需要這樣的冗餘，即使業務層沒有處理業務規則，也要通過業務層來呼叫資料層，這叫分層隔離。對於某些功能，如果我們從表現層直接訪問資料層，那麼資料層後續的任何變動都將影響到業務層和表現層。

分層架構中的一個重要的概念就是分層的開閉原則。如果某層是關閉的，那麼每個請求都要經過著一層。相反，如果該層是開放的，那麼請求可以繞過這一層，直接到下一層。

分層隔離有利於降低整個應用程式的複雜度。某些功能並不需要經過每一層，這時我們需要根據開閉原則來簡化實現。

分層架構是SOLID原則的通用架構，當我們不確定哪種架構更合適的時候，分層架構將是一個很好的起點。我們需要注意防止架構陷入汙水池反模式

此外，分層架構可以演變為巨石應用（Monolith），導致程式碼庫難以維護。

分層架構分析：

• 敏捷性：總體敏捷性是指對不斷變化的環境作出反應的能力。由於其整體風格（Monolith）的性質，可能會變得難以應對通過所有層的變化，開發者需要注意依賴性和分層分離。
• 易於部署：大型應用程式的部署會是個麻煩。一個小要求，可能需要部署整個應用程式。如果能做好持續交付，可能會有所幫助。
• 可測試性：使用Mocking和Faking，每一層可以獨立測試，因此測試上很容易。
• 效能：雖然分層應用程式可能表現良好，但是因為請求需要經過多個分層，可能會存在效能問題。
• 可伸縮性：因為耦合太緊以及整體風格（Monolith）的天生特質，很難對分層應用程式進行伸縮。然而，如果分層能夠被構建為獨立的部署，還是可以具備伸縮能力的。但是，這樣做的代價可能很昂貴。
• 易於開發：這種模式特別易於開發。許多企業採用這種模式。大多數開發者也都知道、瞭解，並且可以輕鬆學習如何使用它。

2 事件驅動架構

事件驅動架構（Event Driven Architecture）是一種流行的分散式非同步架構模式，用於建立可伸縮的應用程式。這種模式是自適應的，可用於小規模或者大規模的應用程式。事件驅動架構可以與調停者拓撲（Mediator Topology）或者代理者拓撲（Broker Topology）一起使用。理解拓撲的差異，為應用程式選擇正確的拓撲是必不可少的。

調停者拓撲

調停者拓撲需要編排多種事件。比如在交易系統中，每個請求流程必須經過特定的步驟，如驗證、訂單、配送，以及通知買家等。在這些步驟中，有些可以手動完成，有些可以並行完成。

通常，架構主要包含4種元件，事件佇列（Event Queue）、調停者（Mediator）、事件通道（Event Channel）和事件處理器（Event Processor）。客戶端建立事件，並將其傳送到事件佇列，調停者接收事件並將其傳遞給事件通道。事件通道將事件傳遞給事件處理器，事件最終由事件處理器處理完成。

事件調停者不會處理也不知道任何業務邏輯，它只編排事件。事件調停者知道每種事件型別的必要步驟。業務邏輯或者處理髮生在事件處理器中，事件通道、訊息佇列或者訊息主題用於傳遞事件給事件處理器。事件處理器是自包含和獨立的，解耦於架構。理想情況下，每種事件處理器應只負責處理一種事件型別。

通常，企業服務匯流排、佇列或者集線器可以用作事件調停者。正確選擇技術和實現能夠降低風險。

代理者拓撲

不像調停者拓撲，代理者拓撲不使用任何集中的編排，而是在事件處理器之間使用簡單的佇列或者集線器，事件處理器知道處理事件的下一個事件處理器。

因其分散式和非同步的性質，事件驅動架構的實現相對複雜。我們需要面對很多問題，比如網路分割槽、調停者失敗、重新連線邏輯等。由於這是一個分散式且非同步的模式，如果你需要事務，那就麻煩了，你得需要一個事務協調器。分散式系統中的事務非常難以管理，很難找到標準的工作單位模式。

另一個充滿挑戰的概念是契約。架構師聲稱服務的契約應該預先定義，而應變是非常昂貴的。

事件驅動架構分析：

• 敏捷性：由於事件和事件處理器之間解耦，並且可獨立維護，因此這種模式的敏捷性很高。變化可以快速、輕鬆地完成，而不會影響整個系統。
• 易於部署：由於架構是解耦的，因此很容易部署。元件可以獨立部署，並且可以在調停者上註冊。部署在代理者拓撲上也相當簡單。
• 可測試性：雖然獨立測試元件很容易，但測試整個應用程式很有挑戰。因此端到端的測試是很難的。
• 效能：事件驅動架構效能非常好，因為它是非同步的。此外，事件通道和事件處理器可以並行工作，因為它們是解耦的。
• 可伸縮性：事件驅動架構的伸縮性非常好，因為元件之間解耦，元件可以獨立擴充套件。
• 易於開發：這種架構的開發不是很容易。需要明確定義契約，錯誤處理和重試機制得處理得當。

3 微核心架構

微核心架構（Microkernel architecture）模式也被稱為外掛架構（plugin architecture）模式。這是產品型應用程式的理想模式，由兩部分組成：核心系統和外掛模組。核心系統通常包含最小的業務邏輯，並確保能夠載入、解除安裝和執行應用所需的外掛。許多作業系統使用這種模式，因此得名微核心。

外掛彼此獨立，因此解偶。核心系統持有註冊器，外掛將自己註冊其上，因此核心系統知道哪裡可以找到它們以及如何執行它們。

這種模式非常適合桌面應用程式，但是也可以在Web應用程式中使用。事實上，許多不同的架構模式可以作為整個系統的一個外掛。對於產品型應用程式來說，如果我們想將新特性和功能及時加入系統，微核心架構是一種不錯的選擇。

微核心架構分析：

• 敏捷性：由於外掛可以獨立開發並註冊到核心系統，微核心架構具有很高的敏捷性。
• 易於部署：依賴於核心系統的實現，能做到不需要重新啟動整個系統來完成部署。
• 可測試性：如果外掛開發是獨立的，測試就可以獨立且隔離地進行。還可以Mock核心系統來測試外掛。
• 效能：這取決於我們有多少外掛在執行，但效能可以調優。
• 可伸縮性：如果整個系統被部署為單個單元，這個系統將難以擴充套件。
• 易於開發：這種架構不容易開發。實現核心系統和註冊會很困難，而且外掛契約和資料交換模型增加了難度。

4 微服務架構

儘管微服務的概念還相當新，但它確實已經快速地吸引了大量的眼球，以替代整體應用和麵向服務架構（SOA）。其中的一個核心概念是具備高可伸縮性、易於部署和交付的獨立部署單元（Separately Deployable Units）。最重要的概念是包含業務邏輯和處理流程的服務元件（Service Component）。拿捏粒度設計服務元件是必要而具有挑戰性的工作。服務元件是解耦的、分散式的、彼此獨立的，並且可以使用已知協議來訪問。

微服務的發展是因為整體應用和麵向服務應用程式的缺陷。整體應用程式通常包含緊耦合的層，難以部署和交付。比如，如果應用程式總在每次應對變化時垮掉，這是一個因耦合而產生的大問題。微服務將應用程式分解為多個部署單元，因此很容易提升開發和部署能力，以及可測性。雖然面向服務架構非常強大，具有異構連線和鬆耦合的特性，但是價效比不高。它很複雜、昂貴，難於理解和實現，通常對於大多數應用程式來說矯枉過正。微服務簡化了這種複雜性。

跨服務元件的程式碼冗餘是完全正常的。開發微服務時，為了受益於獨立的部署單元，以及更加容易的部署，我們可以違反DRY原則。其中的挑戰來自服務元件之間的契約，以及服務元件的可用性。

微服務架構分析：

• 敏捷性：由於服務元件可以各自獨立開發，彼此沒有耦合，因此微服務架構具有很高的敏捷性。獨立部署單元能夠對變化作出迅速的反應。
• 易於部署：相比其他的架構模式，微服務的優勢是服務元件即是單獨部署單元。
• 可測試性：服務元件的測試可以獨自完成。微服務的可測試性很高。
• 效能：依賴於服務元件和這種特定模式的分散式性質。
• 可伸縮性：獨立部署單元天然具備很好的伸縮性。
• 易於開發：每個服務元件可以各自獨立實現。

編後語

《博文共賞》是InfoQ中文站新推出的一個專欄，精選來自國內外技術社群和個人部落格上的技術文章，讓更多的讀者朋友受益，本欄目轉載的內容都經過原作者授權。文章推薦可以傳送郵件到[email protected]。