實話實說，在我還沒有實習之前，我是連 SOA 是啥都不知道的，只聽說過微服務，畢竟微服務實在太火了，想不知道都難，我覺得實習的時候肯定也是微服務，進組之後發現是 SOA 架構，當時都懵了，看了很多文件做了很多筆記都還是不太明白 SOA 是啥，後來又困惑於 SOA 和微服務的區別是啥，我還去翻了一下《鳳凰架構》這本書，遺憾的是，由於我剛剛接觸 SOA，微服務也沒有實際上手過，所以儘管周志明老師的文字已經非常小白向，但是我還是沒能懂 SOA 和微服務到底有啥實質上的區別。
這倆天看見了 IBM 的一篇文章，真的醍醐灌頂，本文對這篇文章的部分段落進行翻譯，然後結合之前看過的資料加入一些自己的理解，原文地址在這裡，感興趣的小夥伴可自行去閱讀英文原文哈：https://www.ibm.com/cloud/blog/soa-vs-microservices
什麼是 SOA
SOA 的全稱是 Service-Oriented Architecture，面向服務的架構。注意這是一種架構哈，我剛開始還以為是跟 Dubbo 一樣的這種框架，hhh，這裡為我的無知道歉。
SOA 是一種全企業範圍（enterprise-wide）的應用軟體開發方法，其核心在於利用可重複使用的軟體元件（software components）或服務（services）。在 SOA 軟體架構中，每項服務都由執行特定業務功能所需的程式碼（code）和資料集（data integrations）組成 。
In SOA software architecture, each service is comprised of the code and data integrations required to execute a specific business function
更通俗點來說，SOA 就是把系統按照實際業務拆分成剛剛好大小的、合適的、獨立部署的模組，各個模組包含各自所需的程式碼和資料集，並且每個模組之間相互獨立。
? 舉個例子，一個銀行網站可能會包含以下幾種服務：檢查客戶的信用、登入網站或處理抵押貸款申請。這三種服務分別包含與各自業務相關的程式碼和資料集。
從程式碼層面直觀來說，每個服務由以下三個部分組成：
- interface 介面：暴露給消費者使用的介面
- contract 契約：規定了服務提供者和服務消費者應該如何互動
- implementation 介面實現：介面的具體實現
SOA 於 20 世紀 90 年代末出現，是應用開發和整合發展的重要階段。在 SOA 架構火起來之前，將單體應用程式（monolithic application）與另一個系統中的資料或功能連線起來需要複雜的點對點整合（point-to-point integration），並且一旦出現一個新專案，開發人員又得為這個新開發專案重新建立這些整合。而通過 SOA 將這些通用功能暴露出來（或者說共享出來），開發人員就無需每次都要重新寫一遍重複程式碼了。
當然，這種方式既是一種好處，也是一種風險。由於很多應用程式都共享訪問了某個服務，那如果這個服務出現問題了，這些應用程式也會受到級聯影響。
? 舉個通俗點的例子：（來自知乎高贊，稍作修改：光太狼 - https://www.zhihu.com/question/42061683）
比如現我有一個資料庫，一個 JavaWeb 的網站客戶端，一個安卓 App 客戶端，一個 IOS 客戶端。
現在我要從這個資料庫中獲取註冊使用者列表，如果按照單體應用程式的設計思想，那麼就是這樣的思路：JavaWeb裡面寫一個查詢方法從資料庫裡面查資料然後在網頁顯示，安卓 App 裡面寫一個查詢方法查詢後在 App 上顯示，IOS 同樣如此。這樣，同樣的一套查詢方法出現了三次，程式碼非常冗餘，三個地方都有相同的業務程式碼，如果需要改動的話三個地方都要改，而且要改的一模一樣。當然問題不止這一個。
於是乎出現了這樣的設計思想，比如用 Java（或者是其他語言皆可）單獨建立一個工程部署在一臺伺服器上，並且寫一個方法（或稱函式）執行上述查詢操作，然後使其他人可以通過某種途徑（可以是 HTTP 連結，或者是基於 Socket 的 RPC 呼叫）訪問這個方法得到返回資料，返回的資料型別是通用的 JSON 或者 Xml 資料，就是說把這個查詢操作封裝到一個工程中去，然後暴露訪問該操作的方式，形成 “服務”（服務介面）。
這樣一來，JavaWeb 這邊可以訪問這個服務然後得到資料使用，安卓和 IOS 這裡也可以通過這個服務得到資料。而且最重要的是，要修改關於註冊使用者的業務方法只要改這個服務就好了，很好的解耦。同理，其他業務比如商品、廣告等業務都可以單獨形成服務部署在單獨伺服器上。
還有一種情況就是一旦哪天突然有一堆人要註冊，假設這堆人僅僅只是註冊而不做其他事情，其他業務比如商品、廣告服務等都不忙，唯獨註冊這個服務壓力很大，而原有的一臺部署了註冊服務的伺服器已經承受不了這麼高的併發，這時候就可以單獨叢集部署這個註冊服務，提供多幾臺伺服器提供註冊服務，而其他服務不用動，維持原樣就好了。
當然，以上舉的例子其實並不能完全稱為 SOA，還不夠完整，因為它少了 服務治理 這一環節。
什麼是服務治理，就是當服務越來越多，呼叫方也越來越多的時候，它們之間的關係就變得非常混亂，需要對這些關係進行管理。
還是上面的例子，假如我有一個使用者服務，一開始有呼叫方 1 和呼叫方 2 來使用這個服務，後來越來越多，將近上百個呼叫方，這個時候作為服務方，它只知道提供服務，卻不知道具體為誰提供了服務。而對於開發者來說，知道這 N 個呼叫方和 N 個服務方之間的關係是非常重要的。
所以這個時候就需要能進行服務治理的框架，比如 Dubbo + Zookeeper、Spring Cloud 等，有了服務治理功能，我們就能清晰地看到服務被誰誰誰呼叫，誰誰誰呼叫了哪些服務，哪些服務是熱點服務需要配置伺服器叢集，而對這個服務叢集的負載均衡也是服務治理可以完成的重要功能之一。
這個時候就是更加完善一點的 SOA 了。當然，還可以更進一步，加上 服務監控跟蹤 等等之類的。
什麼是微服務
? 直接舉例：一個線上購物網站會有一些不同的功能，比如產品目錄、購物車和下單等等。
使用 SOA 的開發公司一般會將購物網站拆分成主要的業務邏輯組，並將每個部分作為獨立應用分別開發，最後整合到一起。具體開發流程包括事先定義好需要暴露給外部呼叫的服務介面，比如新增購物車操作和下單操作，然後圍繞服務介面進行開發。
這樣，如果其他應用比如火車票模組也需要下單操作，那麼直接呼叫這個服務介面就行了，不用重新新增
各位應該能看出 SOA 這裡存在的一個問題，那就是由於圍繞主要的業務邏輯來劃分，所以 SOA 的粒度是比較大的。比如說，我們現在圍繞新增購物車和下單這兩個主要業務邏輯定義了兩個服務介面，但是新增購物車和下單這兩個服務中都存在顯示商品名稱這種粒度比較小的通用功能，這樣，我們就不得不在這兩個服務介面中寫一套差不多的程式碼。
而使用微服務架構的開發公司會將購物車切分成較小的任務導向服務，不再是購物車應用了，而可能是顯示商品名稱服務、新增/移除商品服務、運費服務、匯率服務和訂單撰寫服務。購物車功能可能也會用到一些常用的服務——它們會用在這整個購物網站的很多地方，比如顯示商品名稱服務、顯示產品圖片服務、檢視庫存服務等。通用程式碼被封裝成各種服務，待需要時用在各種功能中。
看下面這張網圖，雖然有點不清晰，但是真的很通俗易懂了 ?：
SOA 和微服務的主要區別：範圍
相信大家看完上面的例子也能夠理解了。
這兩種方法的主要區別歸結於範圍 scope。簡單地說，服務型架構（SOA）粒度比較大，服務於企業範圍，而微服務架構粒度比較小，服務於應用範圍。
所以 If you accept the difference in scope, you may quickly realize that the two can potentially complement each other, rather than compete.
兩者是相互補充，而不是競爭。
? 關注公眾號 | 飛天小牛肉，即時獲取更新
-
博主東南大學碩士在讀，攜程 Java 後臺開發暑期實習生，利用課餘時間運營一個公眾號『 飛天小牛肉 』，2020/12/29 日開通，專注分享計算機基礎（資料結構 + 演算法 + 計算機網路 + 資料庫 + 作業系統 + Linux）、Java 技術棧等相關原創技術好文。本公眾號的目的就是讓大家可以快速掌握重點知識，有的放矢。關注公眾號第一時間獲取文章更新，成長的路上我們一起進步
-
並推薦個人維護的開源教程類專案： CS-Wiki（Gitee 推薦專案，現已累計 1.8k+ star）, 致力打造完善的後端知識體系，在技術的路上少走彎路，歡迎各位小夥伴前來交流學習 ~ ?
-
如果各位小夥伴春招秋招沒有拿得出手的專案的話，可以參考我寫的一個專案「開源社群系統 Echo」Gitee 官方推薦專案，目前已累計 900+ star，基於 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 並提供詳細的開發文件和配套教程。公眾號後臺回覆 Echo 可以獲取配套教程，目前尚在更新中。