[[420823]]

本文轉(zhuǎn)載自微信公眾號「飛天小牛肉」，作者飛天小牛肉。轉(zhuǎn)載本文請聯(lián)系飛天小牛肉公眾號。

實話實說，在我還沒有實習(xí)之前，我是連 SOA 是啥都不知道的，只聽說過微服務(wù)，畢竟微服務(wù)實在太火了，想不知道都難，我覺得實習(xí)的時候肯定也是微服務(wù)，進組之后發(fā)現(xiàn)是 SOA 架構(gòu)，當(dāng)時都懵了，看了很多文檔做了很多筆記都還是不太明白 SOA 是啥，后來又困惑于 SOA 和微服務(wù)的區(qū)別是啥，我還去翻了一下《鳳凰架構(gòu)》這本書，遺憾的是，由于我剛剛接觸 SOA，微服務(wù)也沒有實際上手過，所以盡管周志明老師的文字已經(jīng)非常小白向，但是我還是沒能懂 SOA 和微服務(wù)到底有啥實質(zhì)上的區(qū)別。

這倆天看見了 IBM 的一篇文章，真的醍醐灌頂，本文對這篇文章的部分段落進行翻譯，然后結(jié)合之前看過的資料加入一些自己的理解，原文地址在這里，感興趣的小伙伴可自行去閱讀英文原文哈：https://www.ibm.com/cloud/blog/soa-vs-microservices

什么是 SOA

SOA 的全稱是 Service-Oriented Architecture，面向服務(wù)的架構(gòu)。注意這是一種架構(gòu)哈，我剛開始還以為是跟 Dubbo 一樣的這種框架，hhh，這里為我的無知道歉。

SOA 是一種**全企業(yè)范圍(enterprise-wide)**的應(yīng)用軟件開發(fā)方法，其核心在于利用可重復(fù)使用的軟件組件(software components)或服務(wù)(services)。在 SOA 軟件架構(gòu)中，每項服務(wù)都由執(zhí)行特定業(yè)務(wù)功能所需的代碼(code)和數(shù)據(jù)集(data integrations)組成 。

In SOA software architecture, each service is comprised of the code and data integrations required to execute a specific business function

更通俗點來說，SOA 就是把系統(tǒng)按照實際業(yè)務(wù)拆分成剛剛好大小的、合適的、獨立部署的模塊，各個模塊包含各自所需的代碼和數(shù)據(jù)集，并且每個模塊之間相互獨立。

 舉個例子，一個銀行網(wǎng)站可能會包含以下幾種服務(wù)：檢查客戶的信用、登錄網(wǎng)站或處理抵押貸款申請。這三種服務(wù)分別包含與各自業(yè)務(wù)相關(guān)的代碼和數(shù)據(jù)集。

從代碼層面直觀來說，每個服務(wù)由以下三個部分組成：

1. interface 接口：暴露給消費者使用的接口
2. contract 契約：規(guī)定了服務(wù)提供者和服務(wù)消費者應(yīng)該如何互動
3. implementation 接口實現(xiàn)：接口的具體實現(xiàn)

SOA 于 20 世紀 90 年代末出現(xiàn)，是應(yīng)用開發(fā)和集成發(fā)展的重要階段。在 SOA 架構(gòu)火起來之前，將單體應(yīng)用程序(monolithic application)與另一個系統(tǒng)中的數(shù)據(jù)或功能連接起來需要復(fù)雜的點對點集成(point-to-point integration)，并且一旦出現(xiàn)一個新項目，開發(fā)人員又得為這個新開發(fā)項目重新創(chuàng)建這些集成。而通過 SOA 將這些通用功能暴露出來(或者說共享出來)，開發(fā)人員就無需每次都要重新寫一遍重復(fù)代碼了。

當(dāng)然，這種方式既是一種好處，也是一種風(fēng)險。由于很多應(yīng)用程序都共享訪問了某個服務(wù)，那如果這個服務(wù)出現(xiàn)問題了，這些應(yīng)用程序也會受到級聯(lián)影響。

舉個通俗點的例子：(來自知乎高贊，稍作修改：光太狼 - https://www.zhihu.com/question/42061683)

比如現(xiàn)我有一個數(shù)據(jù)庫，一個 JavaWeb 的網(wǎng)站客戶端，一個安卓 App 客戶端，一個 IOS 客戶端。

現(xiàn)在我要從這個數(shù)據(jù)庫中獲取注冊用戶列表，如果按照單體應(yīng)用程序的設(shè)計思想，那么就是這樣的思路：JavaWeb里面寫一個查詢方法從數(shù)據(jù)庫里面查數(shù)據(jù)然后在網(wǎng)頁顯示，安卓 App 里面寫一個查詢方法查詢后在 App 上顯示，IOS 同樣如此。這樣，同樣的一套查詢方法出現(xiàn)了三次，代碼非常冗余，三個地方都有相同的業(yè)務(wù)代碼，如果需要改動的話三個地方都要改，而且要改的一模一樣。當(dāng)然問題不止這一個。

于是乎出現(xiàn)了這樣的設(shè)計思想，比如用 Java(或者是其他語言皆可)單獨創(chuàng)建一個工程部署在一臺服務(wù)器上，并且寫一個方法(或稱函數(shù))執(zhí)行上述查詢操作，然后使其他人可以通過某種途徑(可以是 HTTP 鏈接，或者是基于 Socket 的 RPC 調(diào)用)訪問這個方法得到返回數(shù)據(jù)，返回的數(shù)據(jù)類型是通用的 JSON 或者 Xml 數(shù)據(jù)，就是說把這個查詢操作封裝到一個工程中去，然后暴露訪問該操作的方式，形成 “服務(wù)”(服務(wù)接口)。

這樣一來，JavaWeb 這邊可以訪問這個服務(wù)然后得到數(shù)據(jù)使用，安卓和 IOS 這里也可以通過這個服務(wù)得到數(shù)據(jù)。而且最重要的是，要修改關(guān)于注冊用戶的業(yè)務(wù)方法只要改這個服務(wù)就好了，很好的解耦。同理，其他業(yè)務(wù)比如商品、廣告等業(yè)務(wù)都可以單獨形成服務(wù)部署在單獨服務(wù)器上。

還有一種情況就是一旦哪天突然有一堆人要注冊，假設(shè)這堆人僅僅只是注冊而不做其他事情，其他業(yè)務(wù)比如商品、廣告服務(wù)等都不忙，唯獨注冊這個服務(wù)壓力很大，而原有的一臺部署了注冊服務(wù)的服務(wù)器已經(jīng)承受不了這么高的并發(fā)，這時候就可以單獨集群部署這個注冊服務(wù)，提供多幾臺服務(wù)器提供注冊服務(wù)，而其他服務(wù)不用動，維持原樣就好了。

當(dāng)然，以上舉的例子其實并不能完全稱為 SOA，還不夠完整，因為它少了 服務(wù)治理 這一環(huán)節(jié)。

什么是服務(wù)治理，就是當(dāng)服務(wù)越來越多，調(diào)用方也越來越多的時候，它們之間的關(guān)系就變得非常混亂，需要對這些關(guān)系進行管理。

還是上面的例子，假如我有一個用戶服務(wù)，一開始有調(diào)用方 1 和調(diào)用方 2 來使用這個服務(wù)，后來越來越多，將近上百個調(diào)用方，這個時候作為服務(wù)方，它只知道提供服務(wù)，卻不知道具體為誰提供了服務(wù)。而對于開發(fā)者來說，知道這 N 個調(diào)用方和 N 個服務(wù)方之間的關(guān)系是非常重要的。

所以這個時候就需要能進行服務(wù)治理的框架，比如 Dubbo + Zookeeper、Spring Cloud 等，有了服務(wù)治理功能，我們就能清晰地看到服務(wù)被誰誰誰調(diào)用，誰誰誰調(diào)用了哪些服務(wù)，哪些服務(wù)是熱點服務(wù)需要配置服務(wù)器集群，而對這個服務(wù)集群的負載均衡也是服務(wù)治理可以完成的重要功能之一。

這個時候就是更加完善一點的 SOA 了。當(dāng)然，還可以更進一步，加上 服務(wù)監(jiān)控跟蹤 等等之類的。

什么是微服務(wù)

直接舉例：一個在線購物網(wǎng)站會有一些不同的功能，比如產(chǎn)品目錄、購物車和下單等等。

使用 SOA 的開發(fā)公司一般會將購物網(wǎng)站拆分成主要的業(yè)務(wù)邏輯組，并將每個部分作為獨立應(yīng)用分別開發(fā)，最后集成到一起。具體開發(fā)流程包括事先定義好需要暴露給外部調(diào)用的服務(wù)接口，比如添加購物車操作和下單操作，然后圍繞服務(wù)接口進行開發(fā)。

這樣，如果其他應(yīng)用比如火車票模塊也需要下單操作，那么直接調(diào)用這個服務(wù)接口就行了，不用重新添加

各位應(yīng)該能看出 SOA 這里存在的一個問題，那就是由于圍繞主要的業(yè)務(wù)邏輯來劃分，所以 SOA 的粒度是比較大的。比如說，我們現(xiàn)在圍繞添加購物車和下單這兩個主要業(yè)務(wù)邏輯定義了兩個服務(wù)接口，但是添加購物車和下單這兩個服務(wù)中都存在顯示商品名稱這種粒度比較小的通用功能，這樣，我們就不得不在這兩個服務(wù)接口中寫一套差不多的代碼。

而使用微服務(wù)架構(gòu)的開發(fā)公司會將購物車切分成較小的任務(wù)導(dǎo)向服務(wù)，不再是購物車應(yīng)用了，而可能是顯示商品名稱服務(wù)、添加/移除商品服務(wù)、運費服務(wù)、匯率服務(wù)和訂單撰寫服務(wù)。購物車功能可能也會用到一些常用的服務(wù)——它們會用在這整個購物網(wǎng)站的很多地方，比如顯示商品名稱服務(wù)、顯示產(chǎn)品圖片服務(wù)、查看庫存服務(wù)等。通用代碼被封裝成各種服務(wù)，待需要時用在各種功能中。

看下面這張網(wǎng)圖，雖然有點不清晰，但是真的很通俗易懂了 ：

圖片來源 http://blog.sina.com.cn/s/blog_90ad2e8b0102xykv.html

SOA 和微服務(wù)的主要區(qū)別：范圍

相信大家看完上面的例子也能夠理解了。

這兩種方法的主要區(qū)別歸結(jié)于范圍 scope。簡單地說，服務(wù)型架構(gòu)(SOA)粒度比較大，服務(wù)于企業(yè)范圍，而微服務(wù)架構(gòu)粒度比較小，服務(wù)于應(yīng)用范圍。

所以 If you accept the difference in scope, you may quickly realize that the two can potentially complement each other, rather than compete. 

兩者是相互補充，而不是競爭。