一、簡介

在對比微服務架構和面向服務的架構（SOA）時，幾乎不可能在它們彼此的關系上達成一致意見。如果應用程序編程接口（API） 再加入混戰(zhàn)，就會讓理解它們的差異變得更加困難。一些人可能會說這些概念完全不同，它們各自解決自己的一組問題，而且擁有獨特的應用范圍。其他人可能更寬厚，認為它們實現(xiàn)了類似的目標，并且具有相同的工作原理。他們可能還會說微服務架構是一種 “細粒度的 SOA” 或 “SOA 的恰當應用”。

二、一種過于簡單的觀點

難以對比 SOA 和微服務的原因在于，它們的定義留有很大的解釋空間。如果您僅擁有這兩個概念的表面知識，可能會覺得它們很相似。一些關鍵方面（比如組件化、解耦和標準化通信協(xié)議）描述了最近幾十年的大部分軟件舉措，所以我們需要進行更深入地分析。

考慮以下簡單定義：

微服務架構是一種構造應用程序的替代性方法。應用程序被分解為更小、完全獨立的組件，這使得它們擁有更高的敏捷性、可伸縮性和可用性。

SOA將應用程序的功能公開為更容易訪問的服務接口，使得在下一代應用程序中使用它們的數(shù)據(jù)和邏輯變得更容易。

如下圖演示了這些定義。SOA 似乎擁有 企業(yè)范圍，應用程序在該范圍內(nèi)彼此通信。SOA 通過應用程序之間的標準化接口來公開服務。微服務架構似乎擁有 應用程序范圍，僅關注一個應用程序內(nèi)的結(jié)構和組件。

這些 SOA 和微服務的定義過于簡單。事實上，它們之間的關系要復雜得多。

三、SOA 舉措的分裂

在更詳細地分析 SOA 時，您可以看到它的原始意圖不僅僅是將接口公開為 SOAP Web 服務。SOA 基于兩種觀點，它們滿足了不同的需求。

3.1 集成引導的技術元素

第一種觀點包括需要深入集成到現(xiàn)有系統(tǒng)的復雜的專用數(shù)據(jù)格式、協(xié)議和傳輸機制中。然后需要使用標準化的機制（比如 SOAP/HTTP 或最近的 JSON/HTTP）來公開它們，使它們更易于在新應用程序中重用。這種觀點如下圖的左側(cè)所示。此觀點的部分或全部通常被稱為 企業(yè)服務總線 （ESB） 模式。但是，這個詞被隨意使用，以至于失去了它原有的意義。

執(zhí)行深入集成（集成中心或適配器）和以標準化方式（公開網(wǎng)關）將這些集成公開為服務或 API 的需求是必不可少的。這個方面與集成挑戰(zhàn)密切相關，與應用程序設計也有一點關聯(lián)。因此它似乎與微服務應用程序架構沒什么關系。

3.2 業(yè)務引導的功能元素

第二種觀點來自業(yè)務角度。關注點是：當前系統(tǒng)上的接口很大程度上沒有什么意義。它們對業(yè)務沒有意義，它們沒有提供下一代應用程序所需的東西。它們的粒度可能太細了，公開了系統(tǒng)內(nèi)太多的復雜數(shù)據(jù)模型。所需的數(shù)據(jù)可能分散在多個系統(tǒng)中。數(shù)據(jù)模型可能不同于業(yè)務部門使用的術語。

該需求要求重構功能，以便公開一些業(yè)務人員可切實構建到未來解決方案中的東西。這種重構要求創(chuàng)建新的應用程序，將跨現(xiàn)有的記錄系統(tǒng)的請求綁定在一起。在 SOA 參考架構中，這些應用程序通常稱為 服務組件（如下圖的右側(cè)）。這種觀點表達了與應用程序設計（進而與微服務架構）和功能分解為單獨組件的過程的關系。

3.3 混合這些觀點的挑戰(zhàn)

組織在哪種觀點具有更大挑戰(zhàn)的看法上存在差異。對于某些組織，他們最大的挑戰(zhàn)是集成的多樣性和復雜性。對于其他組織，重構和重新布局來實現(xiàn)正確的業(yè)務功能是主要的挑戰(zhàn)。上圖顯示了依據(jù)您認為哪種挑戰(zhàn)占主導，對這個問題的看法有何不同。

對許多組織而言，挑戰(zhàn)在于兩種觀點的混合讓人感到很痛苦。痛苦的原因是很難將兩種觀點合并到單個行動過程中。集成工具不是執(zhí)行業(yè)務邏輯的正確位置。相反地，您不希望您的業(yè)務應用程序充斥著技術集成問題。

大多數(shù) SOA 程序的目標都是實現(xiàn)功能方面。它們想獲得能夠輕松訪問的、可用來更有效地構建新應用程序的業(yè)務相關服務。但是，許多組織耗盡了精力，或者更常見的是預算不足，而技術集成難題仍未解決。在大型企業(yè)中，SOA 通常被認為是失敗的。這種想法可能是對的，因為它們未能提供最終的業(yè)務價值，盡管付出了巨大努力來改進記錄系統(tǒng)的可訪問性。但是，在較小的公司（或大型公司中更受限的環(huán)境）中，SOA 常常聲稱真正取得了業(yè)務成功，因為它們可快速克服集成問題，并將此轉(zhuǎn)變?yōu)楣δ苁找妗?/p>

這兩種 SOA 觀點使得與微服務的對比變得很困難。

四、API 與 SOA 公開的服務的對比

API 通常代表著低級編程代碼接口。在最近幾年，這個詞被再次挪用，用來表示通過 HTTP 提供的簡單接口。通常它等同于 REST 接口，這些接口使用 JSON 數(shù)據(jù)格式（有時為 XML）來提供數(shù)據(jù)，使用 HTTP 動詞 PUT、GET、POST 和 DELETE 來描述創(chuàng)建、讀取、更新和刪除操作。與早期 SOA 中更流行的基于 SOAP 的 Web 服務標準相比，這些協(xié)議和數(shù)據(jù)格式在使用上更加簡單。另外，它們更適合 JavaScript 等在創(chuàng)建 API 請求時常用的語言。

但是，SOA Web 服務與 API 之間的區(qū)別不是由協(xié)議和數(shù)據(jù)格式來定義的，因為二者沒有一致地使用它們。區(qū)別在于 API 和 SOA 服務背后的意圖。一個關鍵區(qū)別是它們的經(jīng)濟學原理。

4.1 可重用的 SOA

在 SOA 程序中，公開服務旨在公開每個業(yè)務功能，以便服務可得到盡可能多的重用。這樣，每個新項目就不需要經(jīng)歷再次與后端系統(tǒng)執(zhí)行集成的痛苦。典型的用戶是嘗試將全新的用戶界面放在舊記錄系統(tǒng)上的內(nèi)部應用程序。在這樣做時，集成非常困難，而且會花費很大一部分的 IT 項目預算。如果可以通過可重用的接口公開公司的所有核心功能，就可以大大削減項目成本。SOA 旨在節(jié)省成本，而不是創(chuàng)造新收入。

API 擁有不同的出發(fā)點，它假設集成已被簡化。這種簡化是通過早期的一項 SOA 舉措或通過升級后端系統(tǒng)提供更容易使用的現(xiàn)代接口來實現(xiàn)的。新的挑戰(zhàn)是為潛在的用戶設計一個有吸引力的接口。API 是為可能使用它們的上下文而設計的。例如，它們非常適合提供一種特定類型的移動應用程序所需的數(shù)據(jù)。

4.2 API 管理的黎明

隨著智能電話使用量增長，API 的受歡迎程度也在迅速增長。智能電話運行著豐富的客戶端應用程序，創(chuàng)造了一種顛覆性的新業(yè)務渠道。因此，應用程序開發(fā)人員需要簡單地訪問后端功能和數(shù)據(jù);他們需要 API。API 變成一種暢銷的產(chǎn)品，API 提供者為吸引開發(fā)人員的注意而展開激烈的競爭。API 的關注點不是 SOA 所關注的重用和成本節(jié)省。它的關注點是可使用性以及參與 API 經(jīng)濟中的競爭。API 是一種暢銷產(chǎn)品。

與 SOA 服務相比，這一動態(tài)變化改變了對 API 的技術需求。API 需要復雜的門戶，以便開發(fā)人員能夠發(fā)現(xiàn)和試驗 API。它們還需要一些機制來供開發(fā)人員注冊使用和付費購買 API。API 提供者需要能夠設置支付計劃來適應各種 API 使用率。因為 API 是公開的，所以公開網(wǎng)關需要強大的安全功能。所有這些特性都需要是自助服務，而且最重要的是簡單。此變化引入了一種現(xiàn)在稱為 API 管理的全新 IT 功能。

為此，API 的關注點是作為某種向外部用戶公開的功能;API 與內(nèi)部 SOA 服務之間的分界線已變得很明確。隨著 API 管理技術日漸成熟，API 已帶來了諸如易用性和自我管理等收益。結(jié)果，許多公司現(xiàn)在還希望使用 API 技術和協(xié)議來公開公司內(nèi)部的服務，如下圖所示。SOA Web 服務和 API 之間的界線現(xiàn)在已經(jīng)變得有些模糊，而且?guī)缀鯚o關緊要。它們在起源、向哪些用戶公開和使用的數(shù)據(jù)模型上不同，但許多 SOA “服務” 也可以描述為內(nèi)部 API。

如今，API 這個詞通常用于指代任何通過 REST （HTTP/JSON） 或 Web 服務（SOAP/HTTP） 公開的接口。API 通常按其范圍進行分類，比如公共 API 或企業(yè) API。維持 SOA 舉措的企業(yè)有時會為內(nèi)部、企業(yè)級 API 保留 “服務” 這個詞。

API 這個詞表示 SOA 的 “服務公開” 方面的一次進化。它使用更簡單的協(xié)議，更加精于公開本身，包括開發(fā)人員門戶、策略控制和自我管理。

五、微服務：一種替代性架構

在考慮對比微服務和 SOA 之前，需要理解微服務架構的含義。從基本角度講，微服務是構建 應用程序的替代性架構。它們提供了更好的方法來解耦應用程序邊界 內(nèi)的組件。事實上，如果將微服務稱為 “微型組件”，它們的實際性質(zhì)會更加明確。

應用程序的邊界保持相同。如下圖所示，盡管應用程序在內(nèi)部被分解為不同的微服務組件，但從外部來看，應用程序仍是相同的。基于微服務的應用程序公開的 API 的數(shù)量和粒度不應與將 API 構建為孤立應用程序有任何不同。微服務中的第一個詞“微型” 表示內(nèi)部組件的粒度，而不是公開的接口的粒度。

在應用程序內(nèi)從邏輯上分離組件不是一個新概念。多年以來，大量不同的技術被開發(fā)出來，用于實現(xiàn)整個應用程序的各部分的干凈分離。應用服務器可在其內(nèi)部長期運行多個應用程序組件，如下圖中的中圖所示。微服務更進一步，在這些應用程序組件之間進行了絕對隔離。它們變成網(wǎng)絡上單獨運行的流程，如下圖中的右側(cè)所示。為了實現(xiàn)解耦，您還應分割您的數(shù)據(jù)模型來與微服務保持一致。

六、微服務的優(yōu)勢

完全獨立的微服務組件有助于實現(xiàn)完全自主的所有權，帶來以下優(yōu)勢：

敏捷性和生產(chǎn)力：開發(fā)微服務的團隊可以完全理解代碼庫。他們可以在快得多的周期中與其他組件獨立地構建、部署和測試代碼庫。因為微服務組件只是網(wǎng)絡上的另一個組件，所以您可以采用最適合所需功能的語言或框架來編寫它，并采用最合適的持久性機制。

這種方法可顯著減少要編寫的代碼量，使維護得到顯著簡化。它可以確保團隊能夠根據(jù)需要采用新技術或現(xiàn)有技術的新版本，而不是等待應用程序域的剩余部分跟上節(jié)奏。對于微服務粒度的定義，微服務組件應足夠簡單，以便在必要時在其下一次迭代中重寫。

可伸縮性：微服務開發(fā)團隊可以在運行時與其他組件獨立地擴展微服務組件，實現(xiàn)資源的高效使用和對工作負載變化的快速反應。從理論上講，一個組件的工作負載可以轉(zhuǎn)移到對任務最合適的基礎架構上。它還可以與剩余組件獨立地重新放置，以便充分利用網(wǎng)絡位置。精心編寫的微服務提供了非凡的按需可伸縮性，這一領域的早期創(chuàng)新者和采用者已證明這一點。這些微服務也得到了最佳布置，以便充分利用彈性功能，以富有成本效益的方式訪問大量資源的原生云環(huán)境。

恢復能力：獨立的運行時可以立即提供與其他組件中的故障獨立的恢復能力。借助小心地解耦的設計，比如避免同步依賴關系和使用斷路器模式，可以編寫每個微服務組件來滿足自己的可用性需求，而不是在整個應用程序域中引入這些需求。容器等技術和輕量型運行時使微服務組件能夠快速且獨立地失敗，而不是讓所有不相關的功能區(qū)域都失效。同樣地，它們是以一種高度無狀態(tài)的方式編寫的，以便可以立即重新分布工作負載并幾乎同時地調(diào)出新運行時。

這些優(yōu)勢的示例是組織轉(zhuǎn)而使用微服務的一些最常見的原因。

七、選擇微服務時要考慮的關鍵因素

在決定是否將應用程序編寫為微服務時，必須理解以下因素，以確保您的組織準備好處理它們：

新技術模式。微服務是一種完全不同的應用程序構建方法。因為它們在網(wǎng)絡上，所以它們需要網(wǎng)絡上的一組全新的組件。一些支持技術已經(jīng)存在，包括服務發(fā)現(xiàn)、工作負載編排、容器管理和日志框架。但是，您必須將它們放入一個緊密結(jié)合的集合中，這需要大量實驗、技能和經(jīng)驗。您必須確定滿足您的需求的完美的微服務設置的構成要素，它們可能與其他企業(yè)的微服務不同。

應用程序適合性。微服務并不適合每個應用程序。目前微服務社區(qū)中的一種悖論是，讓新的、相對簡單的、具有高度凝聚性數(shù)據(jù)模型的應用程序采用微服務的概念，這樣做不會獲得任何優(yōu)勢。另外，將一個復雜的現(xiàn)有應用程序重構到微服務架構中是一項繁重的工作。

如果不是在舊版或新式應用程序上，您會何時使用微服務？一種 建議是，在以傳統(tǒng)方式編寫的應用程序達到復雜性的拐點之前，不要使用微服務。但是，要讓此方法發(fā)揮作用，則需要從一開始就編寫一個適當構建的應用程序，并選擇在正確的時刻執(zhí)行過渡。

不同的設計范例。微服務應用程序架構需要不同的設計方法。要從微服務方法獲得最佳結(jié)果，您可能需要：

您還需要：

如果需要利用重要的快速可伸縮性優(yōu)勢，請確保您的應用程序邏輯是無狀態(tài)的。

如果將您自己與下游組件分離，則需要熟悉異步通信的細微的潛在副作用。

理解實現(xiàn)斷路器模式的邏輯后果。

認識到 HTTP/JSON 通信相比于進程中通信的錯誤處理限制。

考慮鏈式交互中的網(wǎng)絡延遲。

接受最終的一致性模型，而不是您所習慣的事務性交互。

理解如何處理沒有中央操作數(shù)據(jù)存儲的事件源應用程序。

DevOps 成熟性。微服務需要一種成熟的交付能力。持續(xù)集成、部署和全自動測試都必不可少。編寫代碼的開發(fā)人員必須負責代碼的生產(chǎn)部署。構建和部署鏈需要重大更改，以便為微服務環(huán)境提供正確的關注點分離。

八、微服務如何融入到 SOA 環(huán)境和集成挑戰(zhàn)中

如果我們 SOA 的心理模式注重集成方面，那么微服務是完全分離的。它是編寫集成架構嘗試連接的應用程序的一種替代方法，如圖 1所示。

但是，如果我們的 SOA 的心理模式注重將應用程序重新布局為對業(yè)務更有意義的 “服務組件”，圖 2 中的右側(cè)顯示的服務組件可能看起來更像微服務組件。微服務架構現(xiàn)在可視為 SOA 的一次進化。為了演示這一點，讓我們對比一下兩個極端。

首先，考慮一家新的創(chuàng)業(yè)公司，該公司對一種完全在線的產(chǎn)品（比如社交媒體或交易）有一種新想法。因為它最初沒有現(xiàn)有的架構可用，所以該公司必須創(chuàng)建一套新應用程序來滿足該業(yè)務的獨特方面。然后，該公司可以選擇將非核心增值業(yè)務的部分業(yè)務外包，并使用軟件即服務 （SaaS） 應用程序來提供客戶關系管理功能。

從很大程度上講，該公司的格局可能會從頭建立。主要關注點可能是它在一個持續(xù)可用的環(huán)境（綠場的概念）中以極少的宕機時間快速添加新功能的能力。該公司可能想根據(jù)無法預測的客戶需求來實現(xiàn)靈活的伸縮（即擴展和精減）。它可能希望實現(xiàn)一種全天候的、高度可用的在線存在感。

微服務架構是該公司的許多格局的邏輯選擇，如圖 6所示。

新應用程序可能位于單個微服務框架中，該框架提供了非功能性能力，比如可伸縮性、可用性和資源管理。您可能預料到低級集成問題很少，因為所有微服務組件和所涉及的 SaaS 應用程序都將使用常見的協(xié)議（比如 HTTP/JSON API）進行通信。SOA 公開寶貴的功能的一個關鍵目標是，為了它可以在整個企業(yè)中得到結(jié)合使用。在這個示例中，精心實現(xiàn)的 SOA 和微服務架構之間的界線已變得模糊。如果想象一下 SOA 的完美實現(xiàn)，它可能看起來和這個示例一樣，但只有新公司能夠創(chuàng)建這種性質(zhì)的架構。

本文不會探討 SOA “服務組件” 是否在大小上與微服務組件相當。微服務組件的粒度和它們的分組方式完全是另一個話題。

現(xiàn)在我們來考慮一個相反的示例，一家已經(jīng)發(fā)展起來的大型公司，幾十年來它已經(jīng)建立了自己的 IT 格局。這個企業(yè)可能是一家傳統(tǒng)的銀行或保險公司，可能擁有數(shù)百或者甚至數(shù)千個重要應用程序是使用可追溯到數(shù)十年前的技術構建的。該企業(yè)內(nèi)可能擁有嚴格的部門劃分，比如醫(yī)療、養(yǎng)老金和一般保險，或者零售和投資銀行。每個業(yè)務部門可能都擁有專門處理其核心業(yè)務的獨立應用程序。這些部門還可能有一套應用程序，比如對于人力資源，其應用程序會盡可能共享。

該公司可能是通過并購競爭對手發(fā)展起來的。在該格局中，您會發(fā)現(xiàn)應用程序之間存在大量的數(shù)據(jù)重復。根據(jù)最初為客戶服務的公司，客戶帳戶可能分散在許多系統(tǒng)中。同一個客戶在多個系統(tǒng)中的關聯(lián)性可能不是很直觀。這些后端應用程序通常很難在內(nèi)部進行更改。在此環(huán)境中，SOA 的一項艱巨任務就是將后端系統(tǒng)重新想象為對未來的業(yè)務需求更有用的某種東西。

集成挑戰(zhàn)也很復雜。它可能需要集成工具（如 圖 7 所示），使得人們在存在協(xié)議、傳輸和數(shù)據(jù)格式上的挑戰(zhàn)的情況下，仍能訪問來自后端應用程序的數(shù)據(jù)和功能。主要出于歷史原因，這種集成做法通常被打上 “SOA” 的標簽，盡管它僅關注一半的 SOA 挑戰(zhàn)。它被標為 SOA 是因為集成是大多數(shù) SOA 舉措處理的第一個區(qū)域。在許多情況下，這是他們在可用資金范圍內(nèi)完成的全部工作。

但是，公司需要使用 SOA 實現(xiàn)的另一個方面是，將數(shù)據(jù)和功能改造為更加以業(yè)務為中心的功能。他們需要確定如何滿足移動等新渠道，這些渠道需要使用與傳統(tǒng)應用程序完全不同的服務粒度。為了實現(xiàn)這些方面，公司需要提供當前系統(tǒng)中可能沒有的響應能力、可用性和可伸縮性。必須編寫應用程序，以一種特殊風格滿足這些新渠道，這種風格支持快速的敏捷變更，提供了極高的可伸縮性，而且提供了卓越的可用性。

人們很容易看到對這些新應用程序使用微服務架構的吸引力。如 圖 7 所示，大型企業(yè)中對微服務的初始使用專注于新的互動參與體系應用程序。SOA 概念可能被早期的以集成為中心的工作所影響。因此，微服務通常被視為不同于 SOA，它提供了更高的敏捷性、可伸縮性和響應能力，但在許多情況下，這些取決于 SOA 的集成階段的基礎工作。

九、在未來將微服務、SOA 和 API 組合在一起

從架構的角度講，SOA 有 3 個關鍵元素：

深入集成使老化的系統(tǒng)能夠公開其數(shù)據(jù)和功能，以便使用一個接口來發(fā)現(xiàn)這些數(shù)據(jù)和功能;

服務公開標準化并簡化這些接口向更廣泛的受眾公開的方式;

服務組件將接口進一步組合到更寶貴的業(yè)務資產(chǎn)中;

9.1 深入集成

一些系統(tǒng)仍需要集成中心所提供的深入集成功能，以便將它們的基礎功能和數(shù)據(jù)公開為 API。其他系統(tǒng)可能能夠在升級到新版本時直接提供 API。當 SOA 傾向于將深入集成功能整合到一個集中化功能中時，關鍵區(qū)別就會顯現(xiàn)出來。更高級的工具和技術應支持集成，以便更頻繁地與應用程序所有者進行聯(lián)合，如 圖 8 中的集成中心的位置所示。

9.2 服務公開

此外，所有系統(tǒng)只要想要保持關聯(lián)，都需要提供 API。應用程序級 API 需要一個輕量型的控制層，如 圖 8 中的 API 網(wǎng)關所示。這個控制層是來自 SOA 的服務公開概念的一種演化。它已變成更廣泛、更分散化的 API 公開。

API 網(wǎng)關和管理功能可能是整個企業(yè)的一種通用資源。它是 “分散化的”，應用程序團隊可以自行發(fā)布 API，同樣也可以自行訂閱他們所需的 API，而不再需要一個額外的團隊。您可以在整個企業(yè)中以標準方式獲得標準化的流量管理和監(jiān)視、日志記錄、審計和安全性機制，同時保留業(yè)務人員所需的敏捷性。這些相同的 API 網(wǎng)關也可用來幫助管理與業(yè)務合作伙伴和外部 SaaS 功能的交互。

9.3 服務組件

傳統(tǒng)的、更加孤立的應用程序仍適合一些實現(xiàn)。但是，微服務提供了一種構建某些類型的應用程序的替代方法，提供了傳統(tǒng)應用程序無法提供的敏捷性、可伸縮性和恢復能力。微服務應用程序在互動層最常見，這一層最需要它們的具體特征，支持創(chuàng)建新的特定于渠道的功能和面對互聯(lián)網(wǎng)的 API。

十、結(jié)束語

對于 SOA 打算實現(xiàn)的目標，至少有兩種不同的觀點。SOA 與微服務架構之間的直接對比可能充滿困難。SOA 的概念存在于現(xiàn)代架構中，但已通過多種方式發(fā)生了演變。集成工具、模式和標準也已發(fā)生演變，所以功能和數(shù)據(jù)更容易公開。服務公開已演變?yōu)?API，簡化了公開、使用、管理，在某些情況下，還可以從業(yè)務功能中牟利。新應用程序架構（包括微服務架構）使得開發(fā)人員能夠更密切地關注業(yè)務邏輯，不斷將基礎架構細節(jié)推送到他們所在的環(huán)境。這些開發(fā)方式的組合有助于以更敏捷的風格構建解決方案，有助于應用程序獲得全新的彈性可伸縮性和容錯水平。