微服務架構與SOA架構的區別與聯絡
場景:
如果我們開啟支付寶首頁，去看我們的餘額，它會展示你的總資產，昨日收益、累計收益等資訊。假如這個頁面所展示的資訊，都來自各個不同的系統/應用，我們通過各個介面把這些資料展示出來。如果我們現在要在前端頁面展示這幾項資料的話，我們應該怎麼去展示呢？
在這種情況下，我們不可能讓客戶端與6個不同的應用/系統都一一去通訊來去完成資料的展示。而是6個應用/系統之間進行彼此通訊來完成呼叫，最後客戶端只需要呼叫一個介面來獲取資料即可，而不是與每一個應用/系統進行通訊。我們的架構可能是如下的樣子：
一個電商系統，比如淘寶，我們在首頁會展示很多資料資訊，例如：首頁資訊、商品資訊、個人資訊、推送資訊等等很多。如果首頁展示的資料來自100個不同的應用/系統，那麼通過如上架構，我們在後端便會出現幾百個乃至上千個通訊的互動，那麼後端的結構就會變得非常的龐大和複雜。所以在這樣的架構下，我們需要對上面結構作出一些調整 ，所以我們就引入了SOA架構
0.圖示區別
1.什麼是SOA架構
SOA（全稱：Service Oriented Architecture），中文意思為 “面向服務的架構”，你可以將它理解為一個架構模型或者一種設計方法，而並不是服務解決方案。其中包含多個服務， 服務之間通過相互依賴或者通過通訊機制，來完成相互通訊的，最終提供一系列的功能。一個服務通常以獨立的形式存在與作業系統程序中。各個服務之間通過網路呼叫 。
跟 SOA 相提並論的還有一個 ESB（企業服務匯流排），簡單來說ESB就是一根管道，用來連線各個服務節點。為了整合不同系統，不同協議的服務，ESB 可以簡單理解為：它做了訊息的轉化解釋和路由工作，讓不同的服務互聯互通；
我們將各個應用之間彼此的通訊全部去掉，在中間引入一個ESB企業匯流排，各個服務之間，只需要和ESB進行通訊，這個時候，各個應用之間的互動就會變得更加的清晰，業務架構/邏輯等，也會變得很清楚。原本雜亂沒有規劃的系統，梳理成了一個有規劃可治理的系統，在這個過程中，最大的變化，就是引入了ESB企業匯流排。
SOA 所解決的核心問題
-
系統整合：站在系統的角度，解決企業系統間的通訊問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規範、服務管理規範；這一步解決的核心問題是【有序】
-
系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生。目的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速複用；這一步解決的核心問題是【複用】
-
業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；前面兩步都是從技術層面來解決系統呼叫、系統功能複用的問題。第三步，則是以業務驅動把一個 業務單元封裝成一項服務。這一步解決的核心問題是 【高效】
2.微服務架構
微服務架構其實和SOA架構類似，微服務是在SOA上做的昇華。微服務架構重點強調的一個是"業務需要徹底的元件化和服務化"，原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。這樣的小應用和其他各個應用之間，相互去協作通訊，來完成一個互動和整合，這就是微服務架構。
元件化：元件表示一個可以獨立更換和升級的單元，就以PC機為例，PC中的 CPU、記憶體、顯示卡、硬碟一樣，獨立更換升級而不影響其他單元。如果我們把PC作為元件以服務的方式構建，那麼這臺PC只需要維護主機板和一些必要的外部裝置。CPU、記憶體、硬碟都是以元件方式提供服務，PC需要呼叫CPU做計算處理，只需要知道CPU這個元件的地址即可。
微服務的特徵
1. 通過服務實現元件化
2. 按業務能力來劃分服務和開發團隊
3. 去中心化
4. 基礎設施自動化（devops、自動化部署）
3.SOA 和微服務架構的差別
1. 微服務去中心化，去掉ESB企業匯流排。微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化
-
Docker容器技術的出現，為微服務提供了更便利的條件，比如更小的部署單元，每個服務可以通過類似Node或者Spring Boot等技術跑在自己的程序中。
-
SOA注重的是系統整合方面，而微服務關注的是完全分離
原文連結：https://blog.csdn.net/lzb348110175/article/details/96738781
更多資訊請關注公眾號：「軟體老王」，關注不迷路，軟體老王和他的IT朋友們，分享一些他們的技術見解和生活故事。