架構:微服務 VS SOA

SOA在早些年被提出來,是一種面向服務的架構。由於其比較厚重,一般只在大公司有一些落地。在這幾年微服務的概念又被提了出來,而且非常火熱。SOA與微服務都提到了服務,那麼二者有什麼區別呢?

架構:微服務 VS SOA

SOA核心概念

如上圖,SOA將服務拆分,拆分的力度較大,拆分的目的是為了服務的共享。整體對外提供服務的是業務服務,而業務服務的能力是透過編排企業服務達到的。企業服務又會編排應用服務,應用服務實現自身能力的時候又會呼叫基礎服務。這樣的架構也會導致這樣的組織結構。這些不同型別的服務分別又不同的團隊負責開發。SOA的一個顯著特點就是平臺中介軟體的存在,也稱為EBS。平臺中介軟體在SOA中比較厚重。為了整合這些服務,需要平臺中介軟體進行粘合。平臺中介軟體一般會提供這些能力:1。協議的轉化。一般SOA裡面的服務所使用的協議是多樣的。比如一邊是json,一邊是xml,又比如一邊提供http服務,一邊提供rpc服務。對於協議的轉換可以做到平臺中介軟體裡面。2。服務的路由。有些平臺中介軟體提供服務的註冊,實現服務發現。在A服務呼叫B服務的時候,中介軟體可以根據負載或者例項的健康狀況選擇服務。3。可以整合一些如熔斷等能力。4。可以實現鑑權或者敏感資訊的過濾等。平臺中介軟體的厚重性也是很多公司放棄SOA的原因。但是對於非常複雜的企業應用,SOA還是很有用處的。

架構:微服務 VS SOA

微服務架構

從上圖發現微服務的架構要簡單得多。這也是很多人鍾愛微服務的原因。拆分好的微服務一般比較小,三個人左右就可以負責一個微服務。微服務的原則是“能不共享就不共享”,與SOA的“能共享就共享”的原則正好相反。正是因為微服務的獨立性,所以微服務可以被獨立部署,可以快速啟動,可以使用異構的技術,可以快速重構。也是因為獨立性的原因,一般微服務會違背“DRY”,會有一些重複程式碼散落在不同的服務中。另外,因為拆分服務的時候,資料庫也是要被拆分的,所以也會存在一部分資料的冗餘。在微服務架構中的API閘道器並不是SOA架構中的EBS。API閘道器要輕量很多。我們提到微服務,常常把“微”作為核心特點。在真正拆分服務的時候,也要注意,按照業務邊界拆分,不能過於“微”。因為服務過細,就會意味著服務數量很多,服務的依賴和互動就會很複雜,運維也很痛。另外,如果出現為了響應一次請求需要A呼叫B,B呼叫C,C呼叫D,D呼叫E的情況,那麼可能你的服務拆分得可能過於細了或者服務的邊界找錯了。過長的呼叫鏈會導致效能的下降,畢竟增加了那麼多次網路互動。還有一種情況就是,當你發現實現事務非常困難的時候,把涉及事務的幾個服務合到一起也許是個好主意。

上面簡單得對比了一下SOA與微服務的差別,後續的文章會繼續介紹如果構建微服務,包括API閘道器的構建、服務發現、故障隔離、跨服務事務等。歡迎大家持續關注~~