聊聊軟件架構

時間 2019-12-01

原文原文鏈接

人類的智力存在上限和沒法擴容多是人類文明發展的最大障礙。爲了解決這一問題，人類發展史上全部的科技發明，無一不是千方百計來擴容腦力。軟件做爲一種模仿人類腦力活動的「生命體」，在其發展早期，也遇到相似問題，Frederick P. Brooks, Jr.教授著名的「人月神話」觀點就是對這一現象的總結。爲了解決這一問題，軟件科學發展了不少方法論和技術，好比分佈式，好比咱們今天的主題：軟件架構和模式。html

軟件架構概念

什麼是軟件架構

學習一個概念，若是知道這些概念要爲了解決什麼問題，解決誰的問題，對深刻掌握它有事半功倍的效果。對於軟件架構這個概念，業界並無一個統1、標準的定義，若是要看透看全面，咱們也須要從不一樣視角來了解它。程序員

什麼是軟件架構，不一樣視角下，有着徹底不同的解讀。算法

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

從決策的角度看：架構=重要決策集：架構表示對一個系統的成型起關鍵做用的設計決策，架構定系統基本就成型了，這裏的關鍵性能夠由變化的成原本決定。這是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個要素。