人類的智力存在上限和無法擴容可能是人類文明發展的最大障礙。為了解決這一問題，人類發展史上所有的科技發明，無一不是想方設法來擴容腦力。軟件作為一種模仿人類腦力活動的“生命體”，在其發展早期，也遇到類似問題，也就是Frederick P. Brooks, Jr.教授著名的“人月神話”觀點。為了解決這一問題，軟件科學發展很多方法論和技術，比如分布式，比如我們今天的主題：軟件架構和模式。

軟件架構概念

什麽是軟件架構

學習一個概念，如果知道這些概念要為了解決什麽問題，解決誰的問題，對深入掌握它有事半功倍的效果。對於軟件架構這個概念，業界並沒有一個統一、標準的定義，如果要看透看全面，我們也需要從不同視角來了解它。

什麽是軟件架構，不同視角下，有著完全不一樣的解讀。

從組成的角度看：架構=組件+交互：軟件系統的架構將系統描述為計算組件及組件之間的交互。這是《軟件構架實踐》作者Bass、《企業應用架構模式》作者Martin Fowler等人的觀點。

從決策的角度看：架構=重要決策集：架構表示對一個系統的成型起關鍵作用的設計決策，架構定系統基本就成型了，這裏的關鍵性可以由變化的成本來決定。這是UML的創始人Grady Booch等人的觀點。

從需求的角度看：架構實際上解決的是人的問題，系統架構的目標是解決利益相關者的關註點。

從演化的角度看：架構是用於管理復雜性、易變性和不確定性，以確保在長期的系統演化過程中，一部分架構的變化不會對架構的其它部分產生不必要的負面影響。這樣做可以確保業務和研發效率的敏捷，讓應用的易變部分能夠頻繁地變化，對應用的其它部分的影響盡可能地小。

什麽是好的架構

首先，找到所有的利益幹系人，並為他們服務。不同幹系人看待架構有不同的視角，這就是架構視圖。架構視圖分很多種，常見的有邏輯架構視圖、開發架構視圖、運行架構視圖、數據架構視圖和物理架構視圖等，這其中最常用的是邏輯架構視圖和物理架構視圖。邏輯視圖用於指導設計開發，物理視圖用於指導部署運維。

其次，發現並解決利益幹系人關註點背後真正的問題。發現問題永遠都比解決問題來的更加重要。

最後，符合康威定律，軟件架構要與組織架構要一致，只有這樣才能夠讓架構落地並推進。如果不一致，要麽調整軟件構架，要麽調整組織架構。

軟件架構模式

模式（Pattern）其實就是解決某一類問題的方法論。而軟件架構模式就是解決某一類軟件組織構架問題的現成形式。現有的軟件架構模式如下圖所示。其中分層架構、事件驅動架構、微服務架構、面向服務架構等在阮一峰的《軟件架構入門》一文有較詳細的介紹。但是還有不少問題沒有談及，比如，這麽多架構模式如何選擇？每種架構模式解決什麽問題？適用什麽場景？本節想對這塊重點做下比較說明，算是一個補充。

分層架構模式

適用場景：

復雜系統的各個部分需要獨立開發和演進。開發人員的關註點分離，系統模塊可以獨立地開發維護。

解決問題：

如何保證軟件模塊可以獨立開發和演進，模塊間盡可能少的交互，模塊支持可移植性、可修改性和可重用性等質量屬性？

解決方案：

為達到關註點分離，軟件以層為單位進行劃分，層是一組提供內聚服務模塊組合。層通過公共接口對外提供服務，層級調用必須是單向的。

模式缺點：

• 分層增加了系統的成本和復雜性；
• 額外的分層邏輯對系統性能有一定影響。

Broker架構模式

適用場景：

分布式系統。其提供的服務分布在不同服務器上。它們的互連關系、交換信息方式等交互復雜。系統對服務的可用性有較高要求。

解決問題：

如何實現分布式軟件系統，讓用戶不需要感知服務提供方的位置，並且用戶和服務提供方之間的綁定關系可以動態變化？

解決方案：

引入一個Broker組件，解耦客戶端和服務端。服務端註冊自己到Broker，通過暴露接口的方式允許客戶端接入服務。客戶端是通過Broker發送請求的，Broker轉發請求道服務端，並將請求的結果或異常回發給客戶端。通過使用Broker模式，應用可以通過發送消息訪問遠程的服務。

這一架構模式允許動態的改變、添加、刪除服務端，從客戶端的角度，這些都是透明的。

• Client -- 需要訪問遠程服務的客戶端
• Server -- 服務的提供者
• Broker -- 類似於消息的轉發器，負責控制和管理集群，Server 啟動時向 Broker 註冊，從而 Broker 在接到 Client 的消息後可以得知要將消息轉發給哪個 Server，然後在 Server 做出應答或發生異常後再將回應通知給 Client
• Client_Proxy -- Client 端的代理層，對 Client 隱藏連接、通訊等底層服務，讓 Client 在使用遠程服務時如同使用本地服務一樣簡單，他維系了 Client 與 Broker 的通信和連接
• Server_Proxy -- Server 端的代理曾，同樣，他接收請求、解包消息，讓 Server 與 Broker 的通信和連接被隱藏
• Bridge -- 用於多個集群的復雜網絡，協調多個 Broker 的數據、消息等工作

模式缺點：

• broker作為間接層，增加了clients和servers間的延遲，而且可能是通信瓶頸。
• broker是單點失效節點。
• broker增加系統復雜性。
• broker是易於成為安全攻擊的目標。
• broker難以測試。

MVC架構模式

適用場景：

包含有人機互動介面（UI）的系統。用戶希望從不同視角來查看數據，如柱狀圖、餅狀圖等。

解決問題：

如何實現用戶界面（UI）與應用邏輯的分離，並保證系統能響應用戶不同的輸入或對應用數據的修改？當底層應用數據變化時，用戶界面的多視角如何創建、維護和協調？

解決方案：

model-view-controller模式將系統劃分為3個組成要素：

• Model（模型）：應用的數據或狀態，以及應用邏輯。
• View（視圖）：按用戶請求顯示底層數據，提供給用戶的操作界面，是程序的外殼。
• Controller（控制）：協調管理model和view間的交互，將用戶行為轉化為對模型的修改或者對視圖的修改。

模式缺點：

• 引入一定的復雜性，不適用簡單的UI系統。
• 一些UI工具包不支持MVC模型。

管道過濾器（Pipe-And-Filter）架構模式

適用場景：

處理數據流的系統。輸入數據後，經過一系列的數據加工轉換後輸出。數據轉換動作重復、獨立、可復用，支持並發。

解決問題：

如何將系統切分為可復用、松散耦合的組件，並且組件間的交互足夠簡單？如何保證組件可以彈性組合，組件通用、低耦合、可復用，並且可並發執行？

解決方案：

管道和過濾器（Pipes and Filters）架構模式由過濾器和管道組成。每個處理步驟都被封裝在一個過濾器組件中 , 數據通過相鄰過濾器之間的管道進行傳輸。每個過濾器可以單獨修改 , 功能單一 , 並且它們之間的順序可以進行配置。Unix shell管道和編譯器都是典型的例子。

• 過濾器：一種組件，其功能是從輸入端口讀入數據，進過數據轉化後，再將數據寫入輸出端口輸出。
• 管道：一種連接器，其功能是將數據從一個過濾器的輸出端口傳輸到另一個過濾器的輸入端口。管道的輸入源和輸出地是單一的。管道不修改其傳輸的數據。

模式缺點：

• 共享狀態信息或者昂貴或者不靈活。
• 數據轉換額外開銷。

CS架構模式

適用場景：

分布式系統。系統中大量的分散的客戶端對共享的資源和服務進行訪問。

解決問題：

如何在資源和服務分布在多個物理服務器的分布式系統中，通過對共享資源進行集中管理，提高系統的可維護性和可復用性，改進其可擴展性和可用性？

解決方案：

CS架構模式由client和server2個要素組成。server提供服務，client請求server的服務，系統交互由client發起。系統可以有一個中央server，也可以是多個分布式server。

• Client：請求Server服務的組件。擁有描述請求服務的接口。
• Server：提供服務給Client的組件。擁有描述提供服務的接口。

模式缺點：

• Server可能是系統性能瓶頸。
• Server可能是單點失效節點。
• 系統一旦部署，調整代價大。

P2P架構模式

適用場景：

分布式系統。系統中每個組件的地位對等，都可以主動發起交互和對外提供服務。

解決問題：

地位對等組件間的互連公共協議如何實現？如何保證系統的高可用性和可擴展性？

解決方案：

P2P模式由peer和connector 2個要素組成。所有的peer地位對等，不是單點失效節點。peer間通過request/reply connector連接並直接交互。

Peer：運行在網絡節點上的獨立組件。特定peer組件（如圖中的超級節點ultrapeer）可以提供路由、索引、查找等功能。

Request/reply connector：用於連接peer網絡，查找其他peer節點和調用其他peer節點上的服務。

模式缺點：

• 數據一致性、數據有效性、數據備份和恢復，安全等實現方案復雜。
• 對於小的P2P系統，性能、可用性等質量目標較難以達到。

面向服務架構（SOA）模式

適用場景：

異構的分布式系統。服務提供方提供服務，並由用戶使用。用戶不需要了解服務的實現細節，即可理解和使用它們。

解決問題：

一個系統中，服務組件運行在不同的平臺，由不同的編程語言開發，由不同的組織提供，分布在各網絡節點中，如何保證這些組件的互操作性？

解決方案：

采用中央管理模式來確保各服務能夠交互運作，服務間通過連接件交互，通過網絡對外提供或使用服務。SOA模式由如下幾個要素組成。

• 應用服務（Service）：提供服務或調用服務。即服務提供者或服務使用者，或兩種角色兼具。
• 企業服務組件（Enterprise Service Bus）：一種在服務提供者和使用者之間傳輸、轉化消息的中間件。
• 服務註冊：服務提供者通過它註冊服務，服務使用者通過它在運行時發現服務。
• 編排服務：基於商業流程和工作流，協調服務提供者和服務使用者間的交互。
• 連接件：服務通過連接件進行相互通信和操作。分為SOAP、RESTful、Asynchronous messaging三種實現協議。

模式缺點：

• SOA系統構建復雜，成本高。
• 無法控制服務的演化。
• 中間件會引入系統性能開銷，服務可能會成為系統性能瓶頸。

微服務架構模式

適用場景：

分布式系統。基於服務的企業應用，支持網頁、手機客戶端等不同的訪問方式。

解決問題：

單塊架構的應用可能過於龐大和復雜，難以維護，嚴重影響效率。而且無法進行分布式部署和彈性擴容。

解決方案：

微服務架構模式是一種將商業邏輯切分為一系列可以獨立開發和部署的服務的架構。其中各項服務都擁有自己的進程，利用輕量化機制或RESTful接口實現通信。這些服務圍繞業務功能建立而成，且憑借自動化部署機制實現獨立部署。這些服務匹配一套最低限度的中央式管理機制，且各服務可通過不同編程語言編寫而成，擁有自己獨立的數據庫，由不同的開發團隊開發。

模式缺點：

• 微服務有額外成本的，需要搭建框架、發布、監控等基礎設施。
• 微服務架構可能帶來過多的操作；因為分布部署跟蹤問題難。
• 微服務應用是分布式系統，會帶來固有的復雜性。
• 隨著微服務數量不斷增加，其管理復雜性也將增加。

發布訂閱架構模式

適用場景：

系統中有大量的獨立的數據生產者和數據消費者，數據生產者和消費者的數量和種類動態變化。它們通過數據交互，但數據在它們之間不共享。

解決問題：

如何建立一種消息傳輸機制，使生產者和消費者之間相互不感知？

解決方案：

發布訂閱模式由3個要素組成。組件通過消息或事件交互。發布者將消息發布到總線上，訂閱者註冊它們感興趣的事件，訂閱管理器負責將這些事件的副本發送給訂閱者。

• Publisher：通過發布接口發布事件。
• Subscriber：通過訂閱接口訂閱事件。
• Subscription Manager：接收發布者發布的事件，並將事件發布給訂閱該事件的訂閱者。

模式缺點：

• 增加系統響應時延，對系統的可擴展性和消息傳遞時間的可預測性有負面影響。
• 難以控制消息序列。
• 難以保證消息傳遞的可靠性。

共享數據架構模式

適用場景：

系統中不同的計算組件需要共享和操作大量數據，這些數據不單獨屬於某一個組件。

解決問題：

系統如何存儲和操作這些持久化數據？

解決方案：

共享數據模式由三部分組成。

• 共享數據庫：協調數據訪問器間的通信，功能包括數據存儲、性能屬性、訪問控制等。
• 數據訪問器：發起數據訪問。只與數據庫進行交互。
• 數據讀寫連接件：負責數據的讀寫。

模式缺點：

• 共享數據庫可能會成為系統性能瓶頸。
• 共享數據庫是單點失效節點。
• 數據的生產者和消費者的耦合度高。

黑板架構模式

適用場景：

一個新興的或者不成熟的領域，沒有確定的或優化的問題解決方案。軟件系統需要集成多種形態不同的模塊，以便實現復雜的、非確定性的控制策略。如語音識別、如人工智能領域等。

解決問題：

問題設計多個專業子領域，每個子領域都有一套獨立的算法。鑒於領域不成熟，可能需要嘗試不同的算法。因為涉及不可靠的數據，只能求近似解，無法找到最優解。算法的執行順序不確定時還可能要求支持並行性。

解決方案：

Blackboard架構模式對還未找到確定解決策略的問題很有幫助。在Blackboard模式中，多個專業子系統通過集思廣益，獲得可能的部分解或近似解。

Blackboard架構背後的理念是，一系列獨立的程序攜手合作，在公共數據結構（即blackboard）上進行計算，中央控制器根據結果狀態對知識源進行協調控制。
在解決問題的過程中，系統通過合並、修正或否決部分解來完成工作。每個部分解都針對一個子問題，是這個子問題的最終解在特定階段的表現形式。所有的可能解構成解空間，並被組織成多個抽象層級，其中最低層為輸入的內部表示，最高層包含系統要解決的整個問題的可能解。
之所以使用名稱“黑板”(blackboard)，是因為它讓人想起專家們站在黑板前協作解決問題的情形。專家們通常自行決定接下來該由誰來到黑板前，而在這裏介紹的模式中，如果有多個程序都能提供幫助，將由調停者(moderator)組件決定這些程序的執行順序。

黑板模式包含3個要素。

• 黑板：中央數據存儲區，解空間中的元素及控制數據都存儲在這裏。黑板提供了一個接口，讓所有知識源都能夠對其進行讀寫。
• 知識源：一個獨立的子系統，解決整個問題的特定方面。
• 控制組件：運行一個監視黑板內容變化的循環，並決定接下來采取什麽措施。

模式缺點：

• 無最優解。
• 並發支持程度低。
• 難以開發、測試。

事件驅動架構模式

適用場景：

異步系統。系統對進入的獨立、異步事件，不管事件量多寡急緩，都需要對事件進行按需及時處理，

解決問題：

如何構建可以處理異步到達消息/事件的分布式系統，並且具有彈性的擴展能力？

解決方案：

部署獨立的事件處理器用於事件處理，對到達的事件進行排隊。分發器從隊列中拉取事件，並基於調度策略把事件分發到合適的事件處理器進行處理。事件驅動架構（event-driven architecture）由四部分組成。

• 事件隊列（event queue）：接收事件的入口。
• 分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元。
• 事件通道（event channel）：分發器與處理器之間的聯系渠道。
• 事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操作。

模式缺點：

• 涉及異步編程（要考慮遠程通信、失去響應等情況），開發相對復雜
• 難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾
• 分布式和異步特性導致這個架構較難測試

MapReduce架構模式

適用場景：

對PB數量級的巨量數據進行快速分析、計算的業務場景。

解決問題：

如何高效率地對巨量數據進行分布式、並行排序，並提供一種分析、使用的簡單方法。

解決方案：

MapReduce模式提供一種對分散的巨量數據的並行分析方法。這種並行方法保證低時延和高可用性。map執行數據的提取和轉換，reduce對map結果進行合並。改模式分為3部分。

• Map（映射）：對一些獨立元素組成的列表的每一個元素進行指定的操作，可以高度並行。
• Reduce（規約）：對一個列表的元素進行合並。
• Infrastructure（基礎設施）：負責map和reduce實例的部署，數據守護，異常監測和恢復。

模式缺點：

• MapReduce開銷較大，特別是數據集較小時。
• 要求數據集能劃分為相似大小的子數據集。
• 多個reduce間協調操作復雜。

參考資料

《軟件架構設計：程序員向架構師轉型必備》
《聊聊架構：洞見架構之道》

Architectural patterns

List of software architecture styles and patterns

每個架構師都應該研究下康威定律

Software Requirements and Architecture Engineering

（完）

聊聊軟件架構