微服務(wù)、SOA 和 API三大架構(gòu)優(yōu)勢對比

一、簡介

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

二、一種過于簡單的觀點

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

考慮以下簡單定義：

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

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

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

這些 SOA 和微服務(wù)的定義過于簡單。事實上，它們之間的關(guān)系要復(fù)雜得多。

三、SOA 舉措的分裂

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

3.1 集成引導(dǎo)的技術(shù)元素

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

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

3.2 業(yè)務(wù)引導(dǎo)的功能元素

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

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

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

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

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

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

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

四、API 與 SOA 公開的服務(wù)的對比

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

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

4.1 可重用的 SOA

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

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

4.2 API 管理的黎明

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

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

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

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

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

五、微服務(wù)：一種替代性架構(gòu)

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

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

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

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

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

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

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

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

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

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

七、選擇微服務(wù)時要考慮的關(guān)鍵因素

在決定是否將應(yīng)用程序編寫為微服務(wù)時，必須理解以下因素，以確保您的組織準(zhǔn)備好處理它們：

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

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

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

不同的設(shè)計范例。微服務(wù)應(yīng)用程序架構(gòu)需要不同的設(shè)計方法。要從微服務(wù)方法獲得最佳結(jié)果，您可能需要：

您還需要：

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

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

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

認(rèn)識到 HTTP/JSON 通信相比于進(jìn)程中通信的錯誤處理限制。

考慮鏈?zhǔn)浇换ブ械木W(wǎng)絡(luò)延遲。

接受最終的一致性模型，而不是您所習(xí)慣的事務(wù)性交互。

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

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

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

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

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

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

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

微服務(wù)架構(gòu)是該公司的許多格局的邏輯選擇，如圖 6所示。

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

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

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

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

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

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

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

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

從架構(gòu)的角度講，SOA 有 3 個關(guān)鍵元素：

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

服務(wù)公開標(biāo)準(zhǔn)化并簡化這些接口向更廣泛的受眾公開的方式;

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

9.1 深入集成

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

9.2 服務(wù)公開

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

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

9.3 服務(wù)組件

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

十、結(jié)束語

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