本文中，我們將介紹並解釋五個主要的模型。我們主要區分直接集成、中間件導向集成以及兩個一般的架構概念。直接集成（例如點對點集成）中的標準化很少，但中間件導向的拓撲（例如中心輻射型拓撲以及企業服務總線）追求儘可能標準化集成，並將來自單個應用的集成工作集中到一箇中央消息平臺。另外兩個架構概念——服務導向架構和微服務——引入了對封裝單個服務和分佈式系統中的服務的架構模式，從而提高了靈活性和可重用性。
本文鏈接：https://www.cnblogs.com/hhelibeb/p/17845805.html
內容來自《SAP Interface Management Guide》，斜體字是我補充的個人理解。
點對點拓撲
兩個應用系統之間的直接連接以實現應用的集成。爲此，定義了一個公共接口，以便兩個系統可以完全彼此通信。然後在兩個參與系統中實現這個接口。因此，集成是沒有中央平臺的，而是從點到點（point to point）。這個過程也稱爲peer to peer。
圖1，點對點拓撲
點對點集成架構具備以下特徵：
- 每個參與的應用系統都可以作爲服務器和客戶端。
- 參與的應用系統之間的通信是直接進行的。
- 參與的應用系統保持其獨立性和自主性。
這種集成拓撲形式在許多公司中仍然常見，是因爲其有明顯的優點。由於系統之間直接相互通信，點對點集成適合於有大量數據需求的情況，它沒有中間的軟件層減慢傳輸。
點對點架構的另一個優點是其比較便宜的實施。不會產生額外的許可費用，通常也不需要硬件擴展。與其他拓撲不同，不需要中央系統來管理和控制集成。因此，基礎設施並未因額外的系統而變得更復雜，也需求少的配置工作。所有的轉換工作都在接口內的轉換模塊或適配器中。如果可能，目標是避免對應用本身進行更改，而是將這些更改外包給上游適配器。
這種方法有助於開發團隊在不先查看其他應用的依賴關係的情況下，很好地控制兩個參與應用的集成方式。
然而，如圖1所示，這種拓撲結構的示意佈局意味着，隨着集成程度的增加和相關接口數量的增加，複雜性會迅速增加。
隨着應用系統數量的增加，集成景觀的擴展性相當差。對於n個應用系統，最多需要n/2×（n-1）個（雙向）連接。如果要集成新的系統，在最壞的情況下，必須定義和實現n-1個新的接口。具體來說，對於6個系統，總共需要15個接口，對於7個系統，必須實現21個接口，因此，在引入這第7個系統時，增加了6個額外的接口。當你需要集成的應用數量超過一定數量時，前面描述的成本優勢可能會被抵消，因爲實施的成本會呈指數增長。
同樣，每個接口實現（或許一個轉換模塊的實現）都代表其自身的單獨開發。由於缺乏標準程序，每兩個應用之間的連接都需要編程一個單獨的解決方案。當對參與的應用進行更改時，這些解決方案也必須單獨記錄並單獨維護。
在這個上下文中，通常存在高度的功能冗餘，因爲相似或甚至相同的業務邏輯是由多個應用系統提供的。在缺乏中央平臺的情況下，監控這些接口的問題也構成了相當大的挑戰。其中一個困難將是在持續的生產運行中主動發現錯誤。在這種情況下，每個參與的系統都必須啓動相應的錯誤處理過程，以相應地通知IT或專業部門。
結論：應用程序領域通常是以進化的方式出現的。往往是按需添加增強，卻沒有考慮重構。因此，接口往往不靈活，只能花費巨大的努力適應其他系統。如果未來需要對 IT 基礎設施進行重構或擴展，這種限制將增加集成工作量。
中心輻射型拓撲
中心輻射型拓撲（Hub-and-spoke topologies）基於消息導向的中間件。上一節中介紹的點對點拓撲相比，中心輻射型架構中，有個叫做集線器的中央系統，是所有集成的應用系統（輻射）之間的通信被路由的地方。
這種架構允許基於消息頭部或消息體中定義的元素的信息進行內容基礎的路由。通過集中處理消息，處理規則可以應用於消息的內容，並可以針對消息的各個接收者。這種拓撲的示意結構如圖2所示。
中心輻射型集成架構可以通過以下特徵進行描述：
- 通過中央消息代理（Message Broker）將發送者和接收者解耦。
- 應用系統之間交換的消息基於規範的數據模型。
- 參與的應用系統保持其獨立性和自主性。
- 通常，中心輻射型架構用於異步數據交換。
圖2 中心輻射型拓撲結構示意圖
中心輻射型架構的中心特點是通過中心消息導向的中間件 —— 集線器，也稱爲消息代理，將發送者和接收者在消息中解耦。這種中間件代表着驗證和評估所有傳入消息並將其傳遞給適當接收者的中心實體。除了數據層面的檢查外，其任務還包括檢查消息的語義，以及接收者是否存在或活躍，以及指定的消息是否包含正確的信息。成功驗證後，集線器根據隨消息發送的地址信息將消息轉發給適當的接收者。因此，基於定義的路由邏輯，消息可以被髮送到一個或多個接收者。
除了純粹的消息路由外，消息代理還應該補償各種應用程序使用的協議和數據格式的差異。例如，假設系統A通過HTTP協議發送一條消息，該消息必須以單獨的格式在安全文件傳輸協議（SFTP）服務器上提供給接收系統B。爲了滿足這個要求，源系統和目標系統之間的應用系統（輻射）的接口中的消息使用消息轉換器進行翻譯。這些消息轉換器執行相應的轉換，包括協議和數據結構的轉換。從技術上來說，這些協議和接口適配器是應用特定的，但從架構上來看，它們更可能被分配給集線器而不是單個應用程序。
然而，應用系統之間的轉換帶來了另一個問題。假設每個參與的應用系統都期望一個不同的數據格式。因此，消息代理必須能夠將n種源格式轉換爲m種目標格式。可以使用這種集成架構在技術層面將系統連接數減少到最多n個，但在消息轉換級別上並非如此。因此，你仍然需要使用消息轉換器來處理所有可能的n個集成應用系統的消息組合。
爲了避免這種額外的工作，可以使用一個全局元模型。這個模型，也被稱爲規範數據模型，描述了一個數據結構，其中所有連接的應用系統的消息都可以通過它描述。通過使用這個模型，系統之間需要的轉換組件的數量從最多的n / 2 × (n - 1)，減少到最多的n。對於每個跨應用通信，消息首先被翻譯成全局格式併發送到集線器，從那裏消息被轉發給接收者並再次翻譯回來。注意，所有消息都轉換使得轉換數量得到了簡化，但與此同時，最壞情況下需要兩倍的計算工作 —— 導致整個架構的響應時間增加。
通過中心輻射型拓撲，集成新應用的過程明顯簡化，因爲集成邏輯和應用邏輯是解耦的。在集成新應用時，你只需要實現一個消息轉換器，將應用的消息轉換爲全局元格式。同樣，修改現有的路由邏輯或定製應用特定消息也更容易。在消息代理中，你只需要爲新消息類型和新系統作爲相關現有系統的接收者，集中地添加適當的接收者。與點對點拓撲相比，有最多n / 2 × (n - 1)個雙向接口，集線器和輻射架構只需要⩽ n個接口。在這種情況下，如果要集成四個或更多的應用，一箇中心化的集成架構就是有意義的。
然而，集中式的消息處理也可能導致單點故障。因此，如果在這個中心節點出現問題，所有集成的應用系統也會受到影響。此外，雖然整個架構中可能的接口數量減少了，但集線器成爲整個系統性能瓶頸的風險增大了。隨着新集成應用系統的增加或消息數據傳輸的增加，增加的消息負載可能會成爲問題。
結論：根據經驗，很難以有意義和可持續的方式實現規範數據模型。構建一個考慮多種協議和每個參與應用系統及其流程的特點的數據結構，不僅耗時，而且資源密集。在極端情況下，數據結構的標準化甚至可能導致系統在可能的使用上受到限制。有時，由於數據模型的不靈活，你無法有效地映射所有業務，因爲定義數據模型的原始基礎系統已經改變了（從業務系統變成了集成平臺）。
可以通過分佈式或聯邦集線器或適當的硬件/軟件側故障轉移機制來對抗這些問題，但是在關鍵和複雜的IT環境中，這種架構模型仍然不夠可擴展和高效。
儘管存在這些各種各樣的缺點，但在SAP世界中也可以找到規範數據模型的實現方法。例如，較新的產品如SAP主數據集成或SAP One Domain Model基於一個集中的數據結構的想法，該結構被分發到周圍的系統中。由於這些產品相當新，它們的實踐效果還有待觀察。
企業服務總線
從字面上看，企業服務總線（ESB）通過數據總線向企業提供服務。在覈心，其主要任務是將客戶端應用程序與服務提供者應用程序解耦。企業服務總線的工作方式如圖3所示。
圖3 企業服務總線的功能
企業服務總線將功能封裝在一個捆綁的服務中，該服務提供給客戶端應用程序，而不是直接與各個服務提供者通信。服務提供者的所需協議或數據格式對客戶端保持隱藏。企業服務總線相應地確保了轉換。因此，企業服務總線提供了公司範圍的服務，這些服務與服務提供者應用程序中的實際實現解耦。其主要目標是使這些服務儘可能靈活和可重用，以便類似的應用程序可以基於現有的轉換或路由規則集（稱爲服務存儲庫）。
企業服務總線拓撲依賴於一箇中央消息總線作爲系統間消息分發的主幹。然而，與中心輻射型方法相比，這種方法允許在多個系統中分發集成活動。集成總線是系統間通信的鏈接。
進程和服務不一定在一箇中心的企業服務總線服務器上運行，而可以分佈在幾個系統上 —— 這是企業服務總線架構在可擴展性和可靠性方面的一個主要優點。圖4顯示了集成總線拓撲的示意結構。
圖4 集成總線拓撲的結構示意圖
所有的應用程序都直接連接到企業服務總線系統。應用程序之間不直接通信。轉換和路由規則存儲在一箇中心服務倉庫中，當從已連接的應用程序系統接收到通信請求時，它們的分配給各個服務觸發相關的後續進程。爲此，倉庫中檢查相關的業務進程，相應的通信命令分發給所有參與的應用程序系統。在最簡單的情況下，進程直接將消息傳遞給目標系統。
企業服務總線集成架構有以下特性：
- 發送者和接收者的解耦
- 轉換模塊的中心倉庫
- 建立業務進程/規則的模型，消息傳輸基於此進行
- 適用於n個發送者和接收者之間的異步和同步通信
- 實現高度分佈式和鬆散耦合的服務導向架構
所有來自各大製造商的經典企業服務總線產品都提供類似的功能範圍。圖5顯示了企業服務總線產品通常提供的組件的基本結構設計。在本節中，我們將簡要地介紹這些單個組件，特別是對於系統管理。
圖5 經典企業服務總線平臺的組件（來源：基於 Liebhart, 2007，和 Winkeler 等人，2000）
系統管理組件支持企業服務總線系統的管理。這些組件監視平臺可以在早期階段識別性能瓶頸和潛在改進點。系統管理包括以下三個組件：
- 負載均衡用於基於消息交換量的系統負載分配。在消息量大的情況下，負載均衡允許分配額外的運行時節點。
- 安全問題不僅涉及專用用戶管理的選項，包括授權管理和訪問控制，還包括加密和解密的機制。
- 監控和日誌記錄使得在運行時及其後能夠監視消息交換。消息日誌記錄允許在數據庫中永久或臨時存儲消息。除了對消息交換的純粹監控和跟蹤外，監控也涉及到應用本身狀態的控制，例如，關於資源利用的情況。
集成管理的組件支持在數據層面的集成，並規定通信的方式。集成管理具有以下五個組件：
- 適配器確保實際應用程序和企業服務總線產品之間的連接。預製的標準適配器減少了建立兩個應用程序之間通信所需的努力。
- 消息路由到一個或多個目標應用程序，基於定義的規則。
- 消息轉換指的是提供數據的轉換，以便目標系統可以解釋。
- 消息調度描述瞭如何在系統之間傳輸單個消息。我們可以區分同步和異步消息模式，例如請求/回覆，發佈/訂閱和消息隊列。
- 事務處理監控單個調用的時間，它們的順序，以及它們的正確性或完整性。
除了應用服務外，流程管理的組件構成了動態企業服務總線平臺的核心構建模塊之一。此區域包含允許建模業務流程的組件，並定義哪些應用程序參與交易以及要執行哪些子流程步驟的規則：
- 流程建模關注業務流程的建模和技術自動化（可執行性）。它也被稱爲工作流。
- 業務規則允許基於中央決策表的定義，根據這些決策表在消息交付運行時遍歷流程及其子路徑。
與中心輻射型拓撲一樣，企業服務總線允許通過將集成邏輯與應用邏輯解耦來在IT環境中無縫集成應用程序。這種獨立性使得連接額外的應用程序變得簡單和靈活。然而，企業服務總線的使用比中心輻射型拓撲更適合於跨公司或國家邊界的高度分佈式應用。聯邦企業服務總線架構由公司的各個組織單位的分佈式集成平臺組成，它們在消息總線系統中彙集在一起，如圖6所示。
圖6 聯邦企業服務總線的結構
在這個例子中，公司由三個全球分佈的組織單位組成。單位A在AMER區域（北美和南美）運營，單位B在EMEA區域（歐洲/中東/非洲）運營，單位C在APAC區域（亞洲和太平洋）運營。儘管每個組織單位本身現在都有一個自治管理的企業服務總線來獨立行動，但所有組織單位仍然可以訪問共享資源並重用數據流和轉換。根據擴展級別，企業服務總線因此構成了跨越業務夥伴、業務單位和部門的通信網絡的核心。
這種企業服務總線架構的優點主要是保留了各個連接的組織單位的自主性。目標是讓所有參與的業務單位和部門保留對自己的本地IT資源的控制。這個目標不僅適用於本地企業服務總線的維護和配置，也適用於新應用的集成。然而，在集成內容的可重用性方面也存在潛力。在本地組織單位中使用的適配器或轉換也可以助力於在另一個組織單位中集成新的應用。
儘管企業服務總線提供了許多自由，但這種類型的架構也帶來了高度的複雜性。建立一個高度分佈式的企業服務總線不僅產生高初步的基礎設施成本，而且在維護多個企業服務總線實例時也有更高的管理開銷。單個企業服務總線實例的本地控制也導致全局景觀控制的最小化。只能在有限的程度上進行集中管理。
結論：企業服務總線主要設計用於高度分佈式系統的集成。由於其在企業結構方面的可伸縮性以及對所有企業應用的全面集成（無論技術平臺和物理位置如何），它提供了一個靈活且全面的集成架構。企業服務總線允許不同的集成方法：從在本地公司內部實現企業服務總線，到帶有分佈式企業服務總線的聯邦架構，每個公司還額外運營自己的本地平臺。典型的企業服務總線產品的例子有SAP PI/PO，TIBCO和IBM WebSphere。
面向服務的架構
面向服務的架構（SOA）是一個用於分佈式系統的靈活且可適應的架構模式。在其核心，面向服務的架構是一個追求將IT組件（如數據庫、服務器和網站）封裝爲可以集成到不同業務流程中的服務的範例。這種架構的主要任務是將多個單獨的技術任務編排和組合成一個可以作爲IT服務提供給其他組織單位或合作伙伴的高級服務。面向服務的架構意味着你可以隱藏單一應用的複雜性在一個標準化的接口後面，從而爲集成提供一個服務的結構化形式。
面向服務的架構的主要目標包括降低軟件開發和集成成本，以及通過在業務流程中重用現有服務來創造更大的靈活性。
市場研究機構Gartner在1996年首次使用了面向服務的架構這個詞，因此被認爲是這種架構模式的發明者。到目前爲止，還沒有一個被普遍接受的定義，但是來自組織信息標準推進組織（OASIS）的以下定義在文獻中經常被引用：面向服務的架構是一個用於組織和利用可能受到不同所有權域控制的分佈式能力的範例（Service oriented architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains）。
面向服務的架構有幾個重要的特徵和屬性，我們將在這一節中討論。沒有統一的面向服務的架構定義，從一般角度描述的最重要的特徵包括以下幾點：
- 可重用性：可重用性的基本思想是在不改變接口或核心應用的情況下多次使用組件和服務。
- 鬆散耦合：你應該能將松耦合的服務組合形成一個流程。這種能力可以通過對其他組件和服務的低依賴性來確保。目標是使得能夠對服務進行功能改變而不影響所提供的性能。
- 自主性/自給自足：如果一個服務獨立於其他服務和功能，它就被認爲是自給自足的。這種自主性要求邏輯、資源等獨立管理。
- 抽象和封裝：抽象與服務的鬆散耦合和重用密切相關，它是關於從具體的功能和實現中抽象出服務的外部。
- 可發現性：類似於目錄服務或黃頁，服務應該是可以找到的。服務必須由消費者和提供者進行尋址。通常，這個特性通過服務註冊表來保證。在服務註冊表中，服務通過接口和實現進行描述。
- 進程導向和編排：編排用於將單個服務集成到不同的業務流程中。面向服務的架構追求的目標是用一個或多個服務提供業務流程。因此，進程導向是面向服務架構的一個基本特性。
實施面向服務的架構基於三種不同的角色 - 服務消費者、服務提供者和服務註冊表。讓我們簡單看一下這些角色：
- 服務消費者：在面向服務的架構中，服務消費者角色在服務註冊表中尋找特定的服務，並獲得關於哪個服務提供者提供這項服務的引用。隨後，服務消費者和服務提供者進行綁定，然後可以調用服務。
- 服務提供者：服務提供者提供一個或多個可以被不同消費者使用的服務。爲了確保服務可以被相應的服務消費者找到，服務提供者在服務註冊表中集中發佈他們的服務。
- 服務註冊表：服務註冊表發佈服務提供者宣佈的服務。此外，服務註冊表通過將他們引向相應的服務提供者來回答服務消費者關於服務的查詢。
這些角色之間的交互可以通過圖7中顯示的三角形來表示。
圖7 面向服務架構中的角色
如圖7所示，交互的步驟爲：
- 服務由服務提供者在中央服務註冊表中發佈。
- 服務消費者在服務註冊表中搜索一個能滿足功能的合適服務。通過服務註冊表，獲得對服務提供者實體的相應引用。
- 服務消費者首先與服務提供者進行綁定，然後可以調用服務。
在面向服務架構中，可以使用各種協議進行通信，如遠程函數調用（RFC）或基於HTTP的服務，如Web服務。會在後文詳細介紹這些協議。根據經驗，面向服務架構中單個服務的集成是通過企業服務總線實現的，它在角色之間充當中間件（上節）。爲了實現面向服務的架構，推薦引入面向服務的架構治理。在面向服務的架構治理中，制定規則，相應地進行監控，並在中央提供。通常，面向服務的架構治理是由一個單獨的團隊建立的。
通過實施面向服務的架構，你可以通過複用服務實現長期的成本降低，因爲核心功能只需要創建一次。通過鬆散耦合和封裝核心服務，你可以在不改變服務的情況下進行系統更改。此外，由於所有參與者都在同一流程中工作並使用同一種語言，因此促進了協作。在技術上，面向服務的架構提供了平臺獨立性，從而提供了更多的靈活性。
然而，由於服務的解耦，面向服務的架構在實施中需要更多的努力，並且比經典的實現更爲複雜。在適應現有服務的版本和兼容性上也增加了複雜性。
此外，在大多數情況下，服務都基於XML標記語言，由於數據量大，傳輸、轉換和處理需要大量的計算能力和時間。所有這些點最初都會在公司的分析、實施和運營中造成較高的成本。
結論：面向服務的架構面向公司的業務流程，並促進接口的重複利用。不幸的是，現實表明，純面向服務架構的初期費用對許多公司來說往往過高，而且它的好處可能只能在很長一段時間後才能顯示出來。許多大型面向服務架構的倡議由於政治和組織問題，除了純技術挑戰外，已經失敗了。例如，責任可能不夠明確，或者歷史上已經生長出了單體的結構。儘管存在這些潛在的問題，面向服務的架構目前依然是選項之一，包括在微服務的背景下。
微服務
在這個部分，我們將介紹微服務（microservice）的概念。像面向服務的架構（SOA）一樣，微服務是計算機科學中的一個架構模式，並遵循模塊化軟件的方法。微服務使用獨立的程序作爲模塊，這些模塊又作爲獨立的進程運行。因此，程序或服務在很大程度上是解耦的，在最好的情況下，只執行一個小任務。總的來說，微服務是小的、獨立的服務，它們協作提供企業應用的業務功能。
微服務架構的主要目標是可擴展性以及減少開發時間，儘快將創新和新功能引入市場。
微服務基於UNIX哲學的基本思想。在他2018年由d.punkt Verlag出版的書《微服務：靈活軟件架構的基礎》中，微服務專家Eberhard Wolff用以下三個方面描述了這種方法：
- 一個程序應該只做一件事，並且應該做好。
- 程序應該能夠一起工作。
- 程序應該使用通用接口。
和麪向服務的架構一樣，微服務這個術語並沒有被普遍接受的定義。在文獻中，微服務通常用以下屬性來描述：
- 技術獨立性：在由多個獨立服務組成的系統中，可以使用不同的技術。可以爲每個任務使用適當的技術和工具。沒有關於特定語言或平臺的限制。
- 獨立性和部署：微服務一定彼此獨立，並且在技術上彼此隔離。此外，當進行更改時，服務可以獨立於其他服務投入生產，但這需要服務本身具有高度的穩定性。
- 可擴展性：在單一系統中，只能對整個系統進行擴展。相比之下，對於微服務架構，每個服務或任務的性能都可以進行擴展。這種能力的優點之一是你將節省運營成本，因爲每個服務使用的資源只會根據需求進行擴展。
- 模塊結構：微服務架構是一種模塊化軟件的方法。其思想是服務的功能可以用於不同的任務。因此，每個服務都被設計用於一系列功能來解決問題。如果對服務的需求增加，需求可以被細分爲更小的服務。
- 可替換性：可替換性意味着小的、獨立的服務可以用較小的努力進行替換。這個特性確保一個微服務只在需要時提供，並且技術是最新的。這樣，可以避免爲舊系統的持續運營產生不必要的成本。
- 組織：一個微服務只由一個團隊開發。然而，一個團隊可以負責多個服務。這樣，可以確保通過適當的組織保護系統架構。
總結來說，可以獨立地開發、部署、操作和擴展微服務架構中的服務。然而，微服務架構的所有特性的關鍵在於各個服務之間通過明確定義的應用程序接口（APIs）進行通信。
爲了再次可視化微服務的架構，圖8展示了單體架構模式（Monolith）和微服務架構模式的比較。在單體架構中，所有的進程和業務邏輯都在一個服務中執行。相比之下，在微服務架構中，應用的核心功能被分割爲多個服務，並獨立執行。這種方法最好用在線商店的例子來描述，商店可能提供各種服務（例如，產品搜索，產品推薦，購物車等）。在線商店中的所有這些核心功能都可以是專門的微服務。每個微服務都可以用不同的技術和任何編程語言來開發。更重要的是服務之間的集成和通信。圖9展示了一個示例架構，以顯示用於實現在線商店的典型微服務架構。
圖8 將單體劃分爲微服務架構
圖9 構建微服務應用的示例架構
注意到各個服務是如何通過API網關解決方案提供的，並且在外部合併，作爲各種客戶端的中心入口點。客戶端和API網關之間的通信通常基於HTTP和RESTful服務。各個微服務之間的通信是異步的和基於事件的。各個服務獨立地進行通信和協作。此外，通常使用事件驅動的總線和消息代理。
微服務和麪向服務的架構都基於服務，並根據這些服務構建應用。這兩種方法都展示了相似的範例和特性，如鬆散耦合和定義的獨立性。然而，在它們的實現和集成中存在微妙的差異，例如，如圖10所示。
圖10 兩種架構模式之間的差異
在面向服務的架構中，服務通過集成解決方案進行編排，因此被映射爲一個整體的業務流程。相比之下，在微服務架構中，每個獨立的微服務負責與其他服務進行通信。因此，在微服務架構中，也減少了對單一企業服務總線的依賴，並且在變更或調整時可以享受更大的靈活性。
然而，這兩種架構模式之間的最大區別在於企業架構層次的結構。雖然面向服務的架構關注並整合整個企業架構或公司的IT架構，但微服務架構更多地關注公司中的單一應用或單一產品。因此，服務的結構在面向服務的架構和微服務之間通常也是不同的。在面向服務的架構中，服務描述了整個應用的功能，而單一微服務描述了應用的單一功能。因此，例如，這兩種架構方法的部署單位和粒度也是不同的。總的來說，表1展示了最重要的區別。
| 方面 | 微服務 | 面向服務的架構 |
|---|---|---|
| 粒度 | 執行任務的小服務 | 經常覆蓋整個系統的大服務 |
| 數據存儲 | 每個服務可以有自己的數據存儲 | 數據存儲由幾個服務使用 |
| 焦點 | 參考單一應用 | 公司範圍內和焦點集成 |
| 集成 | 通過API層進行通信 | 通過企業服務總線進行通信 |
| 表1 微服務架構與面向服務架構的比較 |
微服務架構有可能導致服務間的拓撲關係變得複雜，需要對這種複雜性進行適當的管理。可以使用服務網格、API網關、分佈式追蹤等方式管理服務間的通信、監控和故障排除。
微服務目前是最現代的架構模式之一，擁有極高的流行度。例如Netflix和Google等數字化公司已根據微服務架構實現了它們的IT景觀。微服務的一個主要優點是，由於其強大的模塊化，服務可以輕鬆替換。因此，可以快速獨立地實施並投入生產對服務的更改或新的功能需求。你可以大幅縮短新功能的上市時間。這種架構的另一個決定性優點是服務的粒度縮放。微服務可以根據需要進行水平擴展，並配備額外的資源。這樣，你可以隨時調整基礎設施需求，測量成本，並確保始終可用。除了技術優勢外，微服務還可以擴展敏捷開發過程，並分佈獨立開發團隊的工作。
然而，應在實施過程中考慮微服務架構帶來的一些挑戰。分佈式架構在服務間的通信中產生了複雜性，這可能意味着高網絡延遲。由於大量的獨立服務，端到端測試、日誌記錄和版本控制變得更加複雜。爲了應對這種複雜性，通常需要部署額外的解決方案，例如集中式日誌記錄。經驗表明，公司通常因爲組織和文化變革而失敗。每個團隊都有自己的開發流程和責任，這通常與公司的核心業務流程解決方案相矛盾。（團隊的利益和公司的利益可能不完全相同）
結論：使用微服務架構前必須經過深思熟慮。對於每個場景，都需要重新評估哪些原因支持引入微服務架構，哪些原因反對它，以及你希望獲得哪些利益。通過SAP Business Technology Platform (SAP BTP) 及其相關服務，SAP提供了許多選項，以便按照這些原則來開發應用程序。