玩過 Dubbo 的小伙伴應該都有聽說過一個概念叫做 SOA，每當我們說起微服務的時候，很多人就會去糾結這和 SOA 有啥關系呀？感覺換湯不換藥呀。

今天松哥來稍微和小伙伴們討論下這個話題，我們一起來看看 SOA 和微服務到底有何異同。

1. SOA

SOA，英文全稱是 Service-Oriented Architecture (SOA) governance，單純從字面來看，是面向服務的架構治理。但是小伙伴們在網上應該很難看到比較權威的關于 SOA 通俗易懂的解釋。我這里還是以 TienChin 項目為例，來和大家捋一捋 SOA。

假設 TienChin 中有一個用戶注冊的功能，現在前端的注冊有三個端：

1. 網頁
2. 手機 App
3. 小程序

如果采用傳統的 JavaWeb 開發方式，那么我可能得寫三遍注冊功能，為三個 Client 各自提供一個接口，然而小伙伴們稍微思考一下就會發現，注冊邏輯其實都差不多，區別可能僅僅是接口返回的數據格式有差異而已。因此，我們可以將注冊功能抽取出來，寫成一個單獨的服務，然后通過遠程服務調用如 HTTP 或者 Socket 等，去調用這個注冊的功能模塊。這就是一個簡單的 SOA 架構設計。

然而看了這個很多小伙伴都懵了，這不就是微服務嗎？

接下來我們就來說說 SOA 和微服務到底哪里不一樣。

2. SOA PK 微服務

2.1 服務間通信

首先第一點，就是服務之間的通信方式不同。

玩過 Dubbo 的小伙伴都知道，Dubbo 中常用的通信協議就是 Dubbo 協議，Dubbo 協議本質上其實就是 socket 通信。在 SOA 中，服務之間的通信往往都是采用的重量級協議如 SOAP 等。

而我們常用的微服務框架 Spring Cloud，小伙伴們知道，這里的通信基本上都是 REST 這種輕量級協議，有時候我們甚至是基于消息來驅動微服務，無論哪一種，微服務中服務之間的通信協議都更加輕量級。

2.2 數據庫設計

在 SOA 中，一般來說不太會進行分庫設計，也就是說整個系統還是使用的一個庫，系統可能會分為不同的服務，但是不同的服務操作的都是同一個庫。

微服務則不同，昨天的文章中，松哥畫的下面這張圖，基本上是每一個服務都有一個自己的庫，每個服務都是操作自己的庫，合同管理中需要調用用戶管理的數據，不能直接調用庫，得通過用戶管理提供的 REST 接口去調用。

2.3 服務規模

第三點就是服務的規模不同了。

SOA 中的每一個服務，整體上來說還是一個比較大的單體項目，因為 SOA 一般不會分的很細。而微服務則不同，在微服務中，我們會將服務都劃分的很細，每一個服務基本上都是只負責一個很小的功能模塊。

以前我們玩 SOA 的時候，基本上都還是傳統的 SSM 項目，小伙伴們知道，搭建一個 SSM 項目就已經很費事了，所以能少搭建就少搭建。但是后來有了 Spring Boot 就不一樣了，利用 Spring Boot，我們可以非常方便快捷的創建一個項目，那么此時我們就有足夠的條件把服務劃分的比較細致了。

所以呢，整體上看，SOA 往往是幾個比較大型的服務組合在一起，而微服務則往往是幾十甚至上百個服務組成。

好啦，臨近放假，今天就聊點簡單的不燒腦的哈哈～