[[420823]]

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

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

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

什么是 SOA

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

SOA 是一種**全企業(yè)范圍(enterprise-wide)**的應(yīng)用軟件開(kāi)發(fā)方法，其核心在于利用可重復(fù)使用的軟件組件(software components)或服務(wù)(services)。在 SOA 軟件架構(gòu)中，每項(xiàng)服務(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

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

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

從代碼層面直觀來(lái)說(shuō)，每個(gè)服務(wù)由以下三個(gè)部分組成：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

什么是微服務(wù)

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

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

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

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

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

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

圖片來(lái)源 http://blog.sina.com.cn/s/blog_90ad2e8b0102xykv.html

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

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

這兩種方法的主要區(qū)別歸結(jié)于范圍 scope。簡(jiǎn)單地說(shuō)，服務(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. 

兩者是相互補(bǔ)充，而不是競(jìng)爭(zhēng)。