實話實說，在我還沒有實習之前，我是連 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 可以獲取配套教程，目前尚在更新中。