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

#0 系列目錄#

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