0 系列目錄

1 簡介

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

2 一種過於簡單的觀點

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

考慮以下簡單定義：

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

• SOA將應用程式的功能公開為更容易訪問的服務介面，使得在下一代應用程式中使用它們的資料和邏輯變得更容易。

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

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

3 SOA 舉措的分裂

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

3.1 整合引導的技術元素

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

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

3.2 業務引導的功能元素

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

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

3.3 混合這些觀點的挑戰

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

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

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

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

4 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 的 “服務公開” 方面的一次進化。它使用更簡單的協議，更加精於公開本身，包括開發人員門戶、策略控制和自我管理。

5 微服務：一種替代性架構

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

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

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

6 微服務的優勢

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. 理解如何處理沒有中央操作資料儲存的事件源應用程式。

  您還需要：

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

  2. 如果將您自己與下游元件分離，則需要熟悉非同步通訊的細微的潛在副作用。

  3. 理解實現斷路器模式的邏輯後果。

  4. 認識到 HTTP/JSON 通訊相比於程序中通訊的錯誤處理限制。

  5. 考慮鏈式互動中的網路延遲。

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

8 微服務如何融入到 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 的整合階段的基礎工作。

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

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

深入整合使老化的系統能夠公開其資料和功能，以便使用一個介面來發現這些資料和功能；

服務公開標準化並簡化這些介面向更廣泛的受眾公開的方式；

服務元件將介面進一步組合到更寶貴的業務資產中；

這 3 種元素仍會存在於未來的架構中，但它們一定會分散在整個格局中，如圖 8所示。

9.1 深入整合

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

9.2 服務公開

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

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

9.3 服務元件

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

10 結束語

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