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