轉載自：https://www.jianshu.com/p/a095c59baf31
很多時候會聽到微服務、SOA之間有着聯繫也有着區別，最近在看一本《企業IT架構轉型之道》，僅以本文寫下自己的理解。
“煙囪式”的架構
公司老的IT架構屬於傳統的“煙囪式”架構，也就是每個業務線之間由不同的開發團隊獨立建設，技術棧不同，互不聯繫。大多數的架構會被打包成爲war包並且被部署到Apache Tomcat Web容器中， 整個結構趨於傳統的單體架構，業務邏輯耦合在一個項目中。
這樣的架構有幾個主要的弊端：
- 重複開發。每個業務線中間同樣的模塊會重複開發，比如會員營銷模塊，A業務線要建一個會員營銷系統，B業務線也要建一個會員營銷系統，這會造成很大的開發資源浪費；
- 技術棧不統一。可能A系統用的是Spring MVC, B系統用的就是Spring Boot/Cloud。這會造成公司內部IT架構無法統一規劃，且技術能力難以積累的問題；
- 數據分佈廣，格式不統一，導致數據難以打通。A系統的會員存在A系統的MySQL庫中，B系統的會員存在B系統的Oracle庫中，如果要識別A系統中的001會員和B系統中的002會員是同一個人，也許只能在數倉中實現了。
總結：這樣的架構的好處就是可以互不影響地獨立部署獨立迭代了，適合業務線較少且比較獨立的公司採用。
SOA
SOA 全稱是: Service Oriented Architecture，中文釋義爲 “面向服務的架構”它是一種設計理念，其中包含多個服務， 服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署運行，服務之間 通過網絡進行調用。
SOA的核心理念爲：松耦合帶來的服務重用，通過服務編排助力業務的快速響應和創新。
在SOA時代，有兩種SOA的主要實現方式，分別是Web Service 和ESB。
Web Service
Web Service使得運行在不同的機器及操作系統上的服務的相互發現和調用稱爲可能，並且可以通過某種協議交換數據。
下面是Web Service的工作原理圖。
從上圖可以看到，每個服務之間是對等的，並且互相是解耦合的。通過WSDL定義的服務發現接口進行訪問，並通過SOAP協議進行通信（SOAP協議通常是在HTTP/HTTPS上傳輸XML實現的協議），但是每個服務都要依賴中心化Web Service 目錄來發現存在的服務。
Web Service存在的問題如下：
- 依賴中心化的服務發現機制。
- 使用SOAP協議，而SOAP協議通常用XML格式來序列化通信數據，由於XML格式數據冗餘太大，導致SOAP協議太重。
- 服務化管理和治理設施並不完善。
ESB（企業服務總線）
簡單來說 ESB 就是一根管道，用來連接各個服務節點。ESB的存在是爲了集成基於不同協議的不同服務，ESB 做了消息的轉化、解釋以及路由的工作，以此來讓不同的服務互聯互通。從名稱就能知道，它的概念借鑑了計算機組成原理中的通信模型——總線，所有需要和外部系統通信的系統，統統接入ESB，豈不是完美地兼容了現有的互相隔離的異構系統，可以利用現有的系統構建一個全新的松耦合的異構的分佈式系統。ESB做了消息的轉換解釋與路由等工作，讓不同的服務互聯互通。
傳統的ESB的服務調用方式是，每一次服務的調用者要向服務提供者進行服務交互請求時都必須通過中心的ESB來進行路由。
每一次服務交互的路線是：
服務調用者-->ESB（接收服務請求）-->服務提供者（服務處理）-->ESB（服務提供返回結果）-->服務調用者（服務返回）
經過服務總線路由過的服務交互，共出現4次網絡會話創建和數據傳輸。傳統企業服務總線的架構就暴露出“硬傷”，例如，10臺ESB服務器有一臺實例出現了問題，無法正常提供服務路由的能力，服務路由壓力就落在了剩下的9臺ESB服務器上，原本由出問題的那臺服務器提供的服務路由職能就分攤到了剩下的9臺上，每臺的負載水位就超過88%，個別服務器可能更高，在服務器處於高水位運行的時候，出現問題的概率會大增。導致其他服務器也不堪重負而“罷工”。
“雪崩”事故後，故障恢復的時間和成本非常高昂，因爲傳統的一臺一臺重啓服務器已經不能進行故障的恢復，因爲一旦服務啓動起來，前端的訪問洪流會立即再次壓垮啓動後的服務器，唯一正確的方式是先切斷前端應用對企業服務總線的服務請求，讓這10臺服務器全部啓動後，在開放服務請求，這樣才能恢復系統的運行。
正確理解ESB在SOA中的作用
平心而論，ESB的確是SOA中一個非常重要的集成層組件（Integration Layer），不論是OpenGroup發佈的SOA參考架構，還是幾大主流SOA供應商（參考IBM通過參考架構實施SOA解決方案 ，Oracle與F5的SOA參考架構，Microsoft的BizTalk ESB Toolkit中對ESB的定義），都將ESB置於SOA架構的核心位置。
事實上，ESB在SOA中扮演着重要的角色，在技術層解決了SOA的整合問題，耦合了應用與應用之間的集成邏輯，使得SOA更靈活，更易於擴展，更敏捷。有了ESB，新建的服務消費者應用程序不需要關心服務的提供者在哪裏，使用何種通訊協議，與其交互的數據是怎樣的……，它只需向ESB發出請求，使用開放的、標準的通訊協議。相反，若某個可重用的價值較大的服務位於某一個遺留系統中，而由於種種原因，該遺留系統不能在短期內重寫，此時ESB可以架起該服務與其使用者之間溝通的橋樑。當然，ESB的作用遠不止這些，業內也有很多討論，本文不再贅述。
然鵝，ESB和SOA存在其缺點：
ESB架構雖然能夠屏蔽內部服務變化對外部的影響， 但是服務的功能是“穩定”的，也就是說服務對外提供的功能是基本不變的，其接口設計是自頂向下的設計，在接下來的時間裏，就幾乎沒有新的服務功能的增加和提升。
但是，服務是最不需要“業務穩定”的，服務需要新的業務不斷接入來達到對自身的“滋養”。
從SOA到微服務
SOA的出現其實是爲了解決歷史問題：企業在信息化的過程中會有各種各樣互相隔離的系統，需要有一種機制將他們整合起來，所以纔會有上邊所述的ESB的出現。同樣的，也造成了SOA初期的服務是很大的概念，通常指定的一個可以獨立運作的系統（這樣看，好像服務間天然的松耦合）。這種做法相當於是「把子系統服務化」。
而微服務沒有歷史包袱，輕裝上陣，服務的尺寸通常不會太大，關於服務的尺寸，在實際情況中往往是一個服務應該能夠代表「實際業務場景中的一塊不可分割或不易分割的業務實體」。將服務的尺寸控制在一個較小的體量可以帶來很多的好處：
- 更易於實現低耦合、高內聚
- 更易於維護
- 更易於擴展
- 更易於關注實際業務場景
微服務架構倡導將軟件應用設計成多個可獨立開發、可配置、可運行和可維護的子服務，子服務之間通過良好的接口定義通信機制，通常使用 RESTful 風格的 API 形式來通信 ，因爲RESTful 風格的 API 通常是在 HTTP 或者 HTTPS 通道上傳輸 JSON 格式的數據來實現的， HTTP協議有跨語言、跨異構系統的優點， 當然，也可以通過底層的 進制協議、消息隊列協議等進行交互。這些服務不需要中心化的統 管理，每個服務的功能可自治，並且可以由不同的語言、系統和平臺實現。
微服務的架構如下圖所示：
我們看到微服務架構的 些特點與 SOA 服務化架構相似， 事實上微服務架構與 SOA服務化架構並不衝突，它們一脈相承，卻略有不同：
- 目的不同
微服務使用 系列的微小服務來實現整體的業務流程，目的是有效地拆分應用，實現敏捷開發和部署，在每個微小服務的團隊裏，減少了跨團隊的溝通，讓專業的人做專業的事，縮小變更和法代影響的範圍，並達到單一微服務更容易水平擴展的目的。
SOA 服務化涉及的範圍更廣 些，強調不同的異構服務之間的協作和契約 ，並強調有效集成、業務流程編排、歷史應用集成等，典型代表爲 Web Service 和ESB。 - 部署不同
微服務將完整的應用拆分成多個細小的服務，通常使用敏捷擴容、縮容的 Docker 技術來實現自動化的容器管理 每個微服務運行在單 的進程內，微服務中的部署互相獨立互不影響。
SOA 服務化通常將多個業務服務通過組件化模塊方式打包在 War 包裏，然後統部署在一個應用服務器上。 - 服務粒度不同
微服務倡導將服務拆分成更細的粒度，通過多個服務組合來實現業務流程的處理，拆到職責單一，甚至小到不能再進行拆分。
SOA對粒度沒有要求，在實踐中服務通常是粗粒度的，強調接口契約的規範化，內部實現可以更粗粒度。
Java中的微服務
在Java的生態中，已經有很多十分成熟的，可以拿來實現MSA的中間件，比較出名的有：
-
Spring全家桶
用起來很舒服，只有你想不到，沒有它做不到。 -
Dubbo
很多國內的企業還在用，可以支持RESTful風格的API，但更多的還是會使用Dubbox的默認的基於RPC的API，調用遠程API像調用本地API一樣。這樣做無疑帶來了很多優勢，但同時其基於接口的方式增加了服務間的耦合，怎麼說呢，各有利弊。(上個月成爲了apache top-level project) -
Thrift（需要自己實現一些基礎的東西）。
通常，MSA的實現通常要滿足下面幾個條件： -
服務足夠的小，需要根據自己的實際需求決定服務的大小。
-
服務可以獨立開發、部署、測試。
-
使用輕量級通信方式。
-
數據分離
參考文章：
平臺、中臺與康威定律 - 傳統企業IT架構轉型的辛酸史
The Apache Software Foundation Blog