微服務、SOA和API對比與分析

本文講的是

微服務、SOA和API對比與分析

【編者的話】對比微服務架構和面向服務的架構（SOA）是一個敏感的話題，常常引起激烈的争論。本文将介紹這些争論的起源，并分析如何以最佳方式解決它們。然後進一步檢視這些概念如何與 API 管理概念結合使用，實作更靈活、更分散化、更具彈性的企業架構。

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，簡化了公開、使用、管理，在某些情況下，還可以從業務功能中牟利。新應用程式架構（包括微服務架構）使得開發人員能夠更密切地關注業務邏輯，不斷将基礎架構細節推送到他們所在的環境。這些開發方式的組合有助于以更靈活的風格建構解決方案，有助于應用程式獲得全新的彈性可伸縮性和容錯水準。

本文轉自：http://my.oschina.net/xianggao/blog/638562，作者：陶邦仁。

原文釋出時間為：2016-07-11

本文作者：陶邦仁

本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。

原文标題：微服務、SOA和API對比與分析