一、簡介

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

二、一種過于簡單的觀點

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

考慮以下簡單定義：

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

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

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

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

三、SOA 舉措的分裂

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

3.1 集成引導的技術元素

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

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

3.2 業務引導的功能元素

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

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

3.3 混合這些觀點的挑戰

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

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

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

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

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

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

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

4.1 可重用的 SOA

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

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

4.2 API 管理的黎明

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

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

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

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

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

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

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

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

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

六、微服務的優勢

完全獨立的微服務組件有助于實現完全自主的所有權，帶來以下優勢：

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

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

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

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

這些優勢的示例是組織轉而使用微服務的一些最常見的原因。

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

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

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

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

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

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

您還需要：

如果需要利用重要的快速可伸縮性優勢，請確保您的應用程序邏輯是無狀態的。

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

理解實現斷路器模式的邏輯后果。

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

考慮鏈式交互中的網絡延遲。

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

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

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

八、微服務如何融入到 SOA 環境和集成挑戰中

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

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

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

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

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

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

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

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

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

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

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

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

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

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

深入集成使老化的系統能夠公開其數據和功能，以便使用一個接口來發現這些數據和功能;

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

服務組件將接口進一步組合到更寶貴的業務資產中;

9.1 深入集成

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

9.2 服務公開

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

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

9.3 服務組件

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

十、結束語

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