微服務與SOA架構

1、前言

面向服務架構（SOA）已經存在不少年了，這是一種用於設計軟件的偉大原則。在SOA中，全部組件都是獨立自主的，並能爲其它組件提供服務。要替換掉系統中的某些部分而不對整個系統形成較大的影響，本是個難題，然而只要維護好系統各模塊之間的低耦合，該難題便能迎刃而解。大致上，SOA與微服務架構是很是相像的。微服務是細粒度的SOA組件。換句話說，某單個SOA組件能夠被拆分紅多個微服務，而這些微服務經過分工協做，能夠提供與原SOA組件相同級別的功能，以下圖所示

微服務是細粒度的SOA組件，他們是關注點更窄的輕量級服務。微服務與SOA之間的另外一個不一樣之處是服務互聯和編寫服務時所使用的技術。J2EE是一個遵循企業級標準的用於編寫SOA架構的技術棧。java命名與目錄接口（JNDI）、企業級Javabean（EJB）以及企業服務總線（ESB）都是SOA應用賴以構建和維護的生態土壤。即使ESB是標準， 在2005年以後畢業的工程師卻鮮有據說過ESB的，至於用過ESB的那就更少了。而當代的，例如Rubyon Rails這樣的框架甚至不會去考慮如此複雜的軟件部件。

而另外一方面，微服務推崇執行的標準（例如HTTP）倒是人們普遍瞭解並共同使用的。咱們能夠經過選擇合適的語言或工具來構建某個組件微服務。SOA與微服務還有一個更大的區別：領域模型。在基於微服務的軟件中，每一個微服務應該在本地存儲自身管理的數據，並在領域模型分別隔離到單個服務中。而在面向SOA的軟件中，數據每每存儲在單個大型的數據庫中，服務之間會共享領域模型。

2、面向服務的架構SOA

面向服務的架構是一種軟件體系結構，應用程序的不一樣組件經過網絡上的通訊協議向其餘組件提供服務。通訊能夠是簡單的數據傳遞，也能夠是兩個或者多個服務彼此協調鏈接。這些獨特的服務之星一些小功能，例如驗證付款、建立用戶帳戶或者提供社交登陸等。

面向服務的架構不太關心如何應用程序進行模塊化構建，更多的是關於如何經過分佈式、單獨維護和部署的軟件組件的集成來組成應用程序。這些經過技術和標準來實現，經過技術和標準使得組件可以更容易地經過網絡進行通訊和協做。

SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）。而軟件代理則能夠扮演這兩個角色。 該consumer層是用戶與SOA交互的點，和provider層則由SOA架構內的全部服務所組成。

SOA首先在90年代中期得名， 當時一家名爲Gartner Group的公司認識到了這個軟件架構的新趨勢，並在全球推廣。 經過這樣作，他們設法大大加快了這種架構模式的採用和進一步發展。然而，使用分佈式服務做爲軟件體系結構的最先記錄可追溯到二十世紀80年代初。

3、微服務架構

微服務架構在某種程度上是面向服務的架構SOA繼續發展的產物。基本上，這種架構類型開發軟件，網絡和移動應用程序做爲獨立服務套件（又稱微服務）的一種特殊方式。這些服務的建立僅限於一個特定的業務功能，如用戶管理、用戶角色、電子商務、搜索引擎、社交媒體登陸等。此外，他們是徹底獨立的，也就是說它們能夠寫入不一樣的編程語言並使用不一樣的數據庫。集中式服務管理幾乎不存在，微服務使用輕量級HTTP、REST或 Thrift API進行通訊。乍一看， 微服務架構彷佛談論的是與SOA相同的事情。不過，若是引用微軟服務領域的先驅Martin Flower的話，他曾經說過，「咱們應該把SOA看做微服務的超集」。

4、SOA VS MicroServices

SOA	微服務架構
應用程序服務的可重用性的最大化	專一於解耦
系統性的改變須要修改總體	系統性的改變是建立一個新的服務
DevOps和持續交付正在變得流行，但還不是主流	強烈關注DevOps和持續交付
專一於業務功能重用	更重視「上下文邊界」的概念
通訊使用企業服務總線ESB	對於通訊而言，使用較少精細和簡單的消息系統
支持多種消息協議	使用輕量級協議，例如HTTP，REST或Thrift API
對部署到它的全部服務使用通用平臺	應用程序服務器不是真的被使用，一般使用雲平臺
容器（如Docker）的使用不太受歡迎	容器在微服務方面效果很好
SOA服務共享數據存儲	每一個微服務能夠有一個獨立的數據存儲
共同的治理和標準	輕鬆的治理，更加關注團隊協做和選擇自由

下面進一步解釋上面所述的不一樣之處：

一、開發方面

在這兩種體系結構中，可使用不一樣的編程語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發能夠在多個團隊中組織，可是在SOA中，每一個團隊都須要瞭解常見的通訊機制。另外一方面，使用微服務，服務能夠獨立於其餘服務運行和部署。所以，頻繁部署新版本的微服務或獨立擴展服務會更容易。

二、上下文邊界

SOA鼓勵組件的共享，而微服務嘗試經過上下文邊界來最小化共享。上下文邊界是指以最小的依賴關係將組件及其數據解耦爲單個單元。因爲SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務更慢。

三、通訊

在SOA中，ESB可能成爲影響整個系統的單一故障點。因爲每一個服務都經過ESB進行通訊，若是其中一個服務變慢，可能會阻塞ESB並請求該服務。另外一方面，微服務在容錯方面要好得多。例如，若是一個微服務存在內存錯誤，那麼只有該服務會受到影響，其它的將繼續處理請求。

四、互操做性

SOA經過消息中間件組件促進了多種異構協議的使用。微服務試圖經過減小集成選擇的數量來簡化架構模式。所以，若是您想要在異構環境中使用不一樣協議來集成多個系統，需須要考慮SOA。若是您的全部服務均可以經過相同的遠程訪問協議訪問，那麼微服務對您來講是一個更好的選擇。

五、大小size

微服務架構中的前綴「微」是指內部組件的粒度，意味着它們必須比SOA架構的服務每每要小得多。微服務中的服務組件一般有一個單一的目的，他們作得很好。另外一方面，在SOA服務中通​​常包含更多的業務功能，而且一般將它們實現爲完整的子系統。

5、總結

咱們不能簡單的說一種架構比另外一種架構更好，這主要取決於您正在構建的應用程序的目的。SOA更適合須要與許多其餘應用程序集成的大型複雜企業應用程序環境。也就是說小型應用程序不適合SOA架構，由於它們不須要消息中間件組件。而微服務架構，在另外一方面，是更適合較小和良好的分割的基於web的系統。另外，若是您在開發移動或web應用程序，微服務做爲開發人員能夠爲您提供更大的控制權。最後，能夠得出結論，由於它們服務於不一樣的目的，微服務和SOA確實是不一樣類型的體系結構。

 

更多精彩內容，首發公衆號【素小暖】，歡迎關注。