單體架構、SOA、微服務

一、單體架構

二、單體架構的拆分

三、SOA與微服務的區別

四、微服務的優缺點

五、微服務的消息

六、服務集成

七、數據的去中心化

1、單體架構

Web應用程序發展的早期，大部分web工程是將全部的功能模塊(service side)打包到一塊兒並放在一個web容器中運行，不少企業的Java應用程序打包爲war包。其餘語言(Ruby，Python或者C++)寫的程序也有相似的問題。

假設你正在構建一個在線商店系統：客戶下訂單、覈對清單和信用卡額度，並將貨物運輸給客戶。很快，大家團隊必定能構造出以下圖所示的系統。

這種將全部功能都部署在一個web容器中運行的系統就叫作單體架構（也叫：巨石型應用）。

單體架構有不少好處：IDE都是爲開發單個應用設計的、容易測試——在本地就能夠啓動完整的系統、容易部署——直接打包爲一個完整的包，拷貝到web容器的某個目錄下便可運行。

可是，上述的好處是有條件的：應用不那麼複雜。對於大規模的複雜應用，單體架構應用會顯得特別笨重：要修改一個地方就要將整個應用所有部署(PS：在不一樣的場景下優點也變成了劣勢);編譯時間過長;迴歸測試周期過長;開發效率下降等。另外，單體架構不利於更新技術框架，除非你願意將系統所有重寫(代價過高你願意老闆也不肯意)。

2、單體架構的拆分

詳細一個網站在業務大規模爬升時會發生什麼事情?併發度不夠?OK，加web服務器。數據庫壓力過大?OK，買更大更貴的數據庫。數據庫太貴了?將一個表的數據分開存儲，俗稱「分庫分表」。這些都沒有問題，good job。不過，老外的抽象能力比咱們強，看下圖Fig2。

這張圖從三個維度歸納了一個系統的擴展過程：

(1)x軸，水平復制，即在負載均衡服務器後增長多個web服務器;

(2)z軸擴展，是對數據庫的擴展，即分庫分表(分庫是將關係緊密的表放在一臺數據庫服務器上，分表是由於一張表的數據太多，須要將一張表的數據經過hash放在不一樣的數據庫服務器上);

(3)y軸擴展，是功能分解，將不一樣職能的模塊分紅不一樣的服務。從y軸這個方向擴展，才能將巨型應用分解爲一組不一樣的服務，例如訂單管理中心、客戶信息管理中心、商品管理中心等等。

3、SOA與微服務

SOA:服務導向式架構（SOA）是集成多個較大組件（通常是應用）的一種機制，它們將總體構成一個彼此協做的套件。通常來講，每一個組件會從始至終執行一塊完整的業務邏輯，一般包括完成總體大action所需的各類具體任務與功能。組件通常都是鬆耦合的，但這並不是SOA架構模式的要求。

微服務：是一種架構設計模式。

在微服務架構中，業務邏輯被拆分紅一系列小而鬆散耦合的分佈式組件，共同構成了較大的應用。每一個組件都被稱爲微服務，而每一個微服務都在總體架構中執行着單獨的任務，或負責單獨的功能。每一個微服務可能會被一個或多個其餘微服務調用，以執行較大應用須要完成的具體任務；系統還爲任務執行——好比搜索或顯示圖片任務，或者其餘可能須要屢次執行的任務提供了統一的解決處理方式，並限制應用內不一樣地方生成或維護相同功能的多個版本。

1）. 負責單個功能

2）. 單獨部署

3）. 包含一個或多個進程

4）. 擁有本身的數據存儲

5）. 一支小團隊就能維護幾個微服務

6）. 可替換的

相對於SOA，區別以下：

SOA嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

4、微服務的優缺點

微服務架構模式有不少好處。

第一，經過分解巨大單體應用爲多個服務方法解決了複雜性問題。

在功能不變的狀況下，應用被分解爲多個可管理的分支或服務。每一個服務都有一個用 RPC- 或者消息驅動 API 定義清楚的邊界。

第二，這種架構使得每一個服務均可以有專門開發團隊來開發。

開發者能夠自由選擇開發技術，提供 API 服務。

第三，微服務架構模式使得每一個微服務獨立部署，開發者再也不須要協調其它服務部署對本服務的影響。

最後，微服務架構模式使得每一個服務獨立擴展。你能夠根據每一個服務的規模來部署知足需求的實利。

微服務架構也有不足。其中一個跟他的名字相似，「微服務」強調了服務大小，實際上，有一些開發者鼓吹創建稍微大一些的，10-100 LOC服務組。儘管小服務更樂於被採用，可是不要忘了微服務只是結果，而不是最終目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

另一個不足之處在於，微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者須要在 RPC 或者消息傳遞之間選擇並完成進程間通信機制。此外，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

另一個關於微服務的挑戰來自於分區的數據庫架構。同時更新多個業務主體的事務很廣泛。這種事務對於單體式應用來講很容易，由於只有一個數據庫。在微服務架構應用中，須要更新不一樣服務所使用的不一樣的數據庫。

測試一個基於微服務架構的應用也是很複雜的任務。另一個挑戰在於，微服務架構模式應用的改變將會波及多個服務。部署一個微服務應用也很複雜，一個單體應用只須要在複雜均衡器後面部署各自的服務器就行了。每一個應用實例是須要配置諸如數據庫和消息中間件等基礎服務。每一個服務都有多個實例，這就造成大量須要配置、部署、擴展和監控的部分。除此以外，你還須要完成一個服務發現機制（後續文章中發表），以用來發現與它通信服務的地址（包括服務器地址和端口）

5、微服務消息

1）同步消息 – REST, Thrift

同步消息就是客戶端須要保持等待，直到服務器返回應答。REST是微服務中默認的同步消息方式，它提供了基於HTTP協議和資源API風格的簡單消息格式，多數微服務都採用這種方式（每一個功能表明瞭一個資源和對應的操做）。

Thrift是另一個可選的方案。它採用接口描述語言定義並建立服務，支持可擴展的跨語言服務開發，所包含的代碼生成引擎能夠在多種語言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等建立高效的、無縫的服務，其傳輸數據採用二進制格式，相對 XML 和 JSON 體積更小，對於高併發、大數據量和多語言的環境更有優點。

2）異步消息 – AMQP, STOMP, MQTT

異步消息就是客戶端不須要一直等待服務應答，有應到後會獲得通知。某些微服務須要用到異步消息，通常採用AMQP, STOMP, MQTT。

3）消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務中另一個很重要的因素。SOA的web服務通常採用文本消息，基於複雜的消息格式（SOAP）和消息定義（xsd）。微服務採用簡單的文本協議JSON和XML，基於HTTP的資源API風格。若是須要二進制，經過用到Thrift, ProtoBuf, Avro。

4）服務約定 – 定義接口 – Swagger, RAML, Thrift IDL

若是把功能實現爲服務，併發布，須要定義一套約定。單體架構中，SOA採用WSDL，WSDL過於複雜而且和SOAP緊耦合，不適合微服務。

REST設計的微服務，一般採用Swagger和RAML定義約定。

對於不是基於REST設計的微服務，好比Thrift，一般採用IDL（Interface Definition Languages），好比Thrift IDL。

6、服務集成

SOA體系下，服務之間經過企業服務總線（Enterprise Service Bus）通訊，許多業務邏輯在中間層（消息的路由、轉換和組織）。

微服務架構傾向於下降中心消息總線（相似於ESB）的依賴，將業務邏輯分佈在每一個具體的服務終端。

大部分微服務基於HTTP、JSON這樣的標準協議，集成不一樣標準和格式變的再也不重要。另一個選擇是採用輕量級的消息總線或者網關，有路由功能，沒有複雜的業務邏輯。下面就介紹幾種常見的架構方式。

1）、點對點方式 – 直接調用服務

點對點方式中，服務之間直接用。每一個微服務都開放REST API，而且調用其它微服務的接口。

圖：經過點對點方式通訊

很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨着應用複雜度的提高，會變得愈來愈不可維護。這點有些相似SOA的ESB，儘可能不採用點對點的集成方式。

2）、API-網關方式

API網關方式的核心要點是，全部的客戶端和消費端都經過統一的網關接入微服務，在網關層處理全部的非業務功能個。一般，網關也是提供REST/HTTP的訪問API。服務端經過API-GW註冊和管理服務。

圖：經過API-網關暴露微服務

用咱們網上商店的例子，在圖5中，全部的業務接口經過API網關暴露，是全部客戶端接口的惟一入口。微服務之間的通訊也經過API網關。

採用網關方式有以下優點：

a.有能力爲微服務接口提供網關層次的抽象。好比：微服務的接口能夠各類各樣，在網關層，能夠對外暴露統一的規範接口。

b.輕量的消息路由、格式轉換。

c.統一控制安全、監控、限流等非業務功能。

d.每一個微服務會變得更加輕量，非業務功能個都在網關層統一處理，微服務只須要關注業務邏輯

目前，API網關方式應該是微服務架構中應用最普遍的設計模式。

3）、消息代理方式

微服務也能夠集成在異步的場景下，經過隊列和訂閱主題，實現消息的發佈和訂閱。一個微服務能夠是消息的發佈者，把消息經過異步的方式發送到隊列或者訂閱主題下。做爲消費者的微服務能夠從隊列或者主題共獲取消息。經過消息中間件把服務之間的直接調用解耦。

圖：異步通訊方式

一般異步的生產者/消費者模式，經過AMQP、MQTT等異步消息規範。

7、數據去中心化

單體架構中，不一樣功能的服務模塊都把數據存儲在某個中心數據庫中。

圖：單體架構，用一個數據庫存儲全部數據

微服務方式，多個服務之間的設計相互獨立，數據也應該相互獨立（好比，某個微服務的數據庫結構定義方式改變，可能會中斷其它服務）。所以，每一個微服務都應該有本身的數據庫。

圖：每一個微服務有本身私有的數據庫，其它微服務不能直接訪問。

數據去中心話的核心要點：

1）、每一個微服務有本身私有的數據庫持久化業務數據

2）、每一個微服務只能訪問本身的數據庫，而不能訪問其它服務的數據庫

3）、某些業務場景下，須要在一個事務中更新多個數據庫。這種狀況也不能直接訪問其它微服務的數據庫，而是經過對於微服務進行操做。

數據的去中心化，進一步下降了微服務之間的耦合度，不一樣服務能夠採用不一樣的數據庫技術（SQL、NoSQL等）。在複雜的業務場景下，若是包含多個微服務，一般在客戶端或者中間層（網關）處理。

寫在最後，說起架構，沒有絕對最好的架構，只有最適合業務的架構。技術架構應該從業務中來，到業務中去，其抽象於業務而高於業務。做爲技術開發的咱們，不能一味的追求架構而架構，咱們必須在公司業務發展，團隊資源中間作一個合適的選擇，而後隨着業務的發展逐步重構與優化。

 

轉自https://zhuanlan.zhihu.com/p/52189005