微服務架構談系列（3）：SOA VS 微服務

參考維基百科英文版，我們簡單梳理一下微服務的歷史：

2005 年：Dr. PeterRodgers 在 Web ServicesEdge 大會上提出了 “Micro-Web-Services” 的概念。
2011 年：一個軟件架構工作組使用了 “microservice” 一詞來描述一種架構模式。
2012 年：同樣是這個架構工作組，正式確定用 “microservice” 來代表這種架構。
2012 年：ThoughtWorks 的 James Lewis 針對微服務概念在 QCon San Francisco 2012 發表了演講。
2014 年：James Lewis 和 Martin Fowler 合寫了關於微服務的一篇學術性的文章，詳細闡述了微服務。

由於微服務的理念中也包含了 “服務” 的概念，而 SOA 中也有 “服務” 的概念，我們自然而言地會提出疑問：微服務與 SOA 是什麼關係，有什麼區別，爲何有了 SOA 還要提微服務？這幾個問題是理解微服務的關鍵，否則如果只是跟風拿來就用，既不會用，也用不好，用了不但沒有效果，反而還可能有副作用。

SOA 爲什麼被提出？

對於瞭解過 SOA 的人來說，第一次看到微服務這個概念肯定會有所疑惑：爲何有了 SOA 還要提微服務呢？等到簡單看完微服務的介紹後，很多人可能就有一個疑惑：這不就是 SOA 嗎？

我們看一下，什麼是 SOA？

OASIS 給予出的 SOA 定義：SOA 是一個範式，用於組織和利用可能處於不同所有權範圍控制下的分佈式系統。維基百科給出的 SOA 定義：“面向服務的體系結構（Service-oriented architecture）是構造分佈式系統的應用程序的方法。它將應用程序功能作爲服務發送給最終用戶或者其他服務。它採用開放標準、與軟件資源進行交互並採用表示的標準方式。”。百度百科：面向服務的體系結構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱爲服務）通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。看了這些規範定義，小編只想說一句，說人話！說人話，說人話！幸好，有人還搞了一個 SOA 標準模型。

以筆者瞭解的電信行業爲例，大量的系統由第三方廠商提供或者是外包廠商維護，形成若干的數據孤島和服務離散。A 系統要訪問 B 系統，需要 B 提供接口；C 需要訪問 B 系統，也需要 B 提供接口。由於異地系統的複雜性，大量豎井式應用無法響應日益變化和複雜的業務流程。

SOA 提出了一系列構建分佈式系統的原則，這些思考直到今天也依然適用：

服務具備明確定義的標準化的接口

服務應該是松耦合的

服務應該是無狀態的

服務是可以組合

服務的發現、註冊機制

微服務與 SOA 的關係

關於 SOA 和微服務的關係和區別，大概分爲幾個典型的觀點。

如下圖所示，這種觀點認爲 SOA 是一種架構理念，而微服務是 SOA 理念的一種具體實現方法。例如，“微服務就是使用 HTTP RESTful 協議來實現 ESB 的 SOA”，“使用 SOA 來構建單個系統就是微服務”“微服務就是更細粒度的 SOA”。

微服務是去掉 ESB 後的 SOA

如下圖所示，這種觀點認爲傳統 SOA 架構最廣爲人詬病的就是龐大、複雜、低效的 ESB，因此將 ESB 去掉，改爲輕量級的 HTTP 實現，就是微服務。

微服務是一種和 SOA 相似，但本質上不同的架構理念

如下圖所示，這種觀點認爲微服務和 SOA 只是有點類似，但本質上是不同的架構設計理念。相似點在於下圖中交叉的地方，就是兩者都關注 “服務”，都是通過服務的拆分來解決可擴展性問題。本質上不同的地方在於幾個核心理念的差異：是否有 ESB、服務的粒度、架構設計的目標等。

以上觀點看似都有一定的道理，但都有點差別，到底哪個纔是準確的呢？單純從概念上是難以分辨的，我們對比一下 SOA 和微服務的一些具體做法，再來看看到底哪一種觀點更加符合實際情況。

服務粒度

整體上來說，SOA 的服務粒度要粗一些，而微服務的服務粒度要細一些。例如，對一個大型企業來說，“員工管理系統” 就是一個 SOA 架構中的服務；而如果採用微服務架構，則 “員工管理系統” 會被拆分爲更多的服務，比如 “員工信息管理”“員工考勤管理”“員工假期管理”“員工福利管理” 等更多服務。

服務通信

SOA 採用了 ESB 作爲服務間通信的關鍵組件，負責服務定義、服務路由、消息轉換、消息傳遞，總體上是重量級的實現。微服務推薦使用統一的協議和格式，例如，RESTful 協議、RPC 協議，無須 ESB 這樣的重量級實現。Martin Flower 將微服務架構的服務通信理念稱爲 “Smart endpoints anddumb pipes”，簡單翻譯爲 “聰明的終端，愚蠢的管道”。之所以用“愚蠢” 二字，其實就是與 ESB 對比的，因爲 ESB 太強大了，既知道每個服務的協議類型（例如，是 RMI 還是 HTTP），又知道每個服務的數據類型（例如，是 XML 還是 JSON），還知道每個數據的格式（例如，是 2017-01-01 還是 01/01/2017），而微服務的 “dumb pipes” 僅僅做消息傳遞，對消息格式和內容一無所知。

服務交付

SOA 對服務的交付並沒有特殊要求，因爲 SOA 更多考慮的是兼容已有的系統；微服務的架構理念要求 “快速交付”，相應地要求採取自動化測試、持續集成、自動化部署等敏捷開發相關的最佳實踐。如果沒有這些基礎能力支撐，微服務規模一旦變大（例如，超過 20 個微服務），整體就難以達到快速交付的要求，這也是很多企業在實行微服務時踩過的一個明顯的坑，就是系統拆分爲微服務後，部署的成本呈指數上升。

應用場景

SOA 更加適合於龐大、複雜、異構的企業級系統，這也是 SOA 誕生的背景。這類系統的典型特徵就是很多系統已經發展多年，採用不同的企業級技術，有的是內部開發的，有的是外部購買的，無法完全推倒重來或進行大規模的優化和重構。因爲成本和影響太大，只能採用兼容的方式進行處理，而承擔兼容任務的就是 ESB。

微服務更加適合於快速、輕量級、基於 Web 的互聯網系統，這類系統業務變化快，需要快速嘗試、快速交付；同時基本都是基於 Web，雖然開發技術可能差異很大（例如，Java、C++、.NET 等），但對外接口基本都是提供 HTTP RESTful 風格的接口，無須考慮在接口層進行類似 SOA 的 ESB 那樣的處理。

綜合上述分析，我們將 SOA 和微服務對比如下表所示。

對比維度

SOA

微服務

| |

服務粒度

粗

細

| |

服務通信

重量級，ESB

輕量級，例如 HTTP/ RESTful

| |

服務交付

慢

快

| |

應用場景

企業級

互聯網

因此，我們可以看到，SOA 和微服務本質上是兩種不同的架構設計理念，只是在 “服務” 這個點上有交集而已，因此兩者的關係應該是第三種模式。

其實，Martin Fowler 在他的微服務文章中，已經做了很好的提煉：

In short, the microservice architectural style is an approach to

developing asingle application as a suite of small services,

each running in its own process and communicating with

lightweight mechanisms, often an HTTP resource API. These services

are built around business capabilities and independently deployable

by fully automated deployment machinery.

上述英文的三個關鍵詞分別是：small、lightweight、automated，基本上濃縮了微服務的精華，也是微服務與 SOA 的本質區別所在。

通過前面的詳細分析和比較，似乎微服務本質上就是一種比 SOA 要優秀很多的架構模式，那是否意味着我們都應該把架構重構爲微服務呢？

其實不然，SOA 和微服務是兩種不同理念的架構模式，並不存在孰優孰劣，而只是應用場景不同而已。我們介紹 SOA 時候提到其產生歷史背景是因爲企業的 IT 服務系統龐大而又複雜，改造成本很高，但業務上又要求其互通，因此纔會提出 SOA 這種解決方案。如果我們將微服務的架構模式生搬硬套到企業級 IT 服務系統中，這些 IT 服務系統的改造成本可能遠遠超出實施 SOA 的成本。

曾經 SOA 架構下迷途

在技術上，ESB 架構雖然實現了業務邏輯與服務集成的解耦，可以更好地進行中央化的服務治理，也暴露出一些問題：

由於過度強調業務系統的可複用性，而不是對企業 IT 架構的治理和重構。大量服務集成的實現邏輯被下沉到 ESB 內部；而微服務 / 服務化架構下的註冊中心是單純的註冊機制。

ESB 基於一箇中心化的消息處理系統，集中式 EAI 的模式，本身會成爲一個單點，可擴展性和性能的挑戰。

上圖 from 百度百科

另，EAI 模式下的 SOA，實施過程中服務的定義往往沒有站在全局架構下思考，宏觀未有企業信息架構指導、微觀未有類似 DDD 的指引，協議翻譯和集成終於服務的合理抽取。

微服務架構下迷途

大略是老馬提出微服務有以下幾個特徵：

通過服務實現組件化；
按業務能力來劃分服務與組織團隊；
服務即產品；
智能終端與啞管道；
去中心統一化；
基礎設施自動化；
Design for failure；
進化設計

還有人說微服務是 RESTful 協議；微服務技術棧可以變。我想說，這些未必是微服務的必要條件。

迷信微服務不可取，我們看一下微服務具體有哪些坑。

服務劃分過細，服務間關係複雜

服務劃分過細，單個服務的複雜度確實下降了，但整個系統的複雜度卻上升了，因爲微服務將系統內的複雜度轉移爲系統間的複雜度了。

從理論的角度來計算，n 個服務的複雜度是 n×(n-1)/2，整體系統的複雜度是隨着微服務數量的增加呈指數級增加的。下圖形象了說明了整體複雜度。

粗粒度劃分服務時，系統被劃分爲 3 個服務，雖然單個服務較大，但服務間的關係很簡單；細粒度劃分服務時，雖然單個服務小了一些，但服務間的關係卻複雜了很多。

服務數量太多，團隊效率急劇下降
開發工程師要設計多個接口，打開多個工程，調試時要部署多個程序，提測時打多個包。
測試工程師要部署多個環境，準備多個微服務的數據，測試多個接口。
運維工程師每次上線都要操作多個微服務，並且微服務之間可能還有依賴關係。
調用鏈太長，性能下降
調用鏈太長，問題定位困難（略）
沒有自動化支撐，無法快速交付
沒有自動化測試支撐，每次測試時需要測試大量接口。
沒有自動化部署支撐，每次部署 6~7 個服務，幾十臺機器，運維人員敲 shell 命令逐臺部署，手都要敲麻。
沒有自動化監控，每次故障定位都需要人工查幾十臺機器幾百個微服務的各種狀態和各種日誌文件。
沒有服務治理，微服務數量多了後管理混亂

信奉微服務理念的設計人員總是強調微服務的 lightweight 特性，並舉出 ESB 的反例來證明微服務的優越之處。但具體實踐後就會發現，隨着微服務種類和數量越來越多，如果沒有服務治理系統進行支撐，微服務提倡的 lightweight 就會變成問題。主要問題如下。

服務路由：假設某個微服務有 60 個節點，部署在 20 臺機器上，那麼其他依賴的微服務如何知道這個部署情況呢？
服務故障隔離：假設上述例子中的 60 個節點有 5 個節點發生故障了，依賴的微服務如何處理這種情況呢？
服務註冊和發現：同樣是上述的例子，現在我們決定從 60 個節點擴容到 80 個節點，或者將 60 個節點縮減爲 40 個節點，新增或減少的節點如何讓依賴的服務知道呢？
微服務引入的技術複雜度，如分佈式事務

信奉微服務理念的設計人員總是強調微服務的 lightweight 特性，並舉出 ESB 的反例來證明微服務的優越之處。但具體實踐後就會發現，隨着微服務種類和數量越來越多，如果沒有服務治理系統進行支撐，微服務提倡的 lightweight 就會變成問題。

末了，總結一下。不要照搬微服務，如同當年的 SOA 一樣，獲得對應的收益必然要付出相應的成本。如果對於自己團隊的業務階段、技術水平、業務特性識別不清楚，可能南轅北轍。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651043433&idx=1&sn=05641de30854056d2d11de4b605c9064&chksm=8c4c636dbb3bea7b290f5d3f6e01fd31ea1ae712b551a783b6b34c74a785fbe56a363dfc3bc6&scene=178&cur_album_id=1343963749467717633#rd

猜你喜歡