作者 | 佩里阿薩米、克里希納拉杰
譯者 | 崔瑩峰
策劃 | 云昭
從單一的單體應用到迄今為止的微服務架構，架構風格已經走過了漫長的道路。每種風格都有獨特的優勢和復雜性。當下，基于微服務的架構適逢其時，它提供了靈活性、敏捷性，并由此給企業帶來了更提前的上市時間。然而，微服務體系結構依舊存在嚴重的問題：在每個領域的即時功能的添加或排除方面缺乏可組合性。也就是說，所有這些架構風格都沒有提供可組合的能力。
對可組合架構的需求更多是由業務和市場驅動的，而不是由技術驅動的。在目前的情況下，顛覆性創新既能發生在大范圍內，也能發生在小范圍內。本文討論了可組合應用架構的概念及其架構模式。另外，為了充分闡述該架構，本文引入了一個真實的行業應用作為示例。
選擇架構的前提已發生變化
時下，一個企業選擇何種技術或軟件的假設與前提發生了變化。雖然原則、政策和指導方針還是一樣的，但在大多數情況下，下列因素對產品、技術和開發的選擇也有了直接影響：
- 企業中現有的技術
- 所選用的技術選型在市場上的可用性
- 保證在基礎設施、知識產權和人力資源方面的已有投資
- 選擇的產品/技術如何應對現有的IT環境
當然，還有其他易見的收益，如TCO、ROI、上市時間等。
圍繞可變性：可組合架構的魅力所在
眾所周知，每個架構都是由"領域"和"映射到領域的功能"組成。每個功能又由一個或多個解決方案組件實現。
可組合架構并不會偏離上述領域拆分原則；它只是不同于實現所需業務領域功能的組件的組合。
整個架構圍繞可變性原則展開。這意味著可變性可能會發生在技術層，也可能會發生在功能中。
以風險管理框架為例，我們將其視為一個領域。這個領域需要和客戶打交道，并處理客戶各種緯度方面的數據，例如：
了解客戶畫像
財務適配分析
欺詐分析
關系分析
以上的每一個分析步驟需要全部完成，才能篩選有資格的客戶進入金融機構。實際上領域映射的"功能"則會根據技術和功能組件而有所不同，而這些組件像樂高一樣堆疊在每個領域上，如下面的示意圖所示：
讓我們以圖中的“KYC”為例，深入了解細節。下圖是一個包含四個樂高塊的KYC域，然而它從多個維度管理相同的功能“KYC”，每個維度都有自己的實現成本、操作成本、優點和缺點。而且每一個緯度都適合不同的客戶群。例如，“X”代和“Y”代的客戶更喜歡視頻KYC或第三方，而老年人則更喜歡老式的手工分析方式，因為他們的筆跡可能不適合OCR。這就是可組合架構帶來的可變性。
正如 Gartner 所指出的那樣：
到 2024 年，新 SaaS 和自定義應用程序的設計口號將是“可組合的 API 優先或僅 API”，將傳統的 SaaS 和自定義應用程序視為“遺留系統。"
架構風格的演變
從單一的綠屏應用程序到迄今為止的可組合架構，架構風格已經走過了漫長的道路。每種風格都有額外的優勢和復雜性。當下，基于微服務的架構適逢其時，它提供了靈活性、敏捷性和更提前的上市時間。然而，微服務體系結構風格卻在每個領域的即時功能的添加或排除方面缺乏可組合性。
所有這些架構風格都沒有提供可組合的能力，但是，微服務架構以漸進的方式提供了靈活性，從而提供了最大的靈活性和敏捷性。
對可組合架構的需求更多是由業務和市場驅動的，而不是由技術驅動的。在目前的情況下，顛覆性創新既能發生在大范圍內，也能發生在小范圍內。例如，基于AI、基于ICR的KYC是KYC領域的創新，而像元宇宙這樣的東西是大規模的顛覆性創新，可能并不適合可組合架構。
可組合架構的關鍵原則
可組合架構是一種完整的、全新的技術創新，它也是在流行的微服務架構之上的一種增量式創新。如上一節所述，可組合架構能夠在不影響架構的模塊化或服務編排的情況下為特定領域添加或排除臨時功能。
需要遵循的兩個基本原則:
- API優先：API成為提供和使用業務功能的基本理念
- 即時編排綁定：編排過程在運行時被發現，就像服務被發現一樣。編排需要存儲在一個持久性或內存數據庫中(圖形數據庫是一個很好的選擇，因為它可以描述序列以及替代路徑)。
可組合服務邏輯解決方案視圖
以前面描述的幾個領域和功能領域為例，下面展示了涉及可組合服務的解決方案的邏輯視圖(與技術棧無關)：
使用組合服務構建的更大的解決方案包含以下核心框架功能：
除了單個或多個領域內的可組合性之外，上述實現可組合性的方法也可以應用于編制/編排層。
可組合服務解決方案實現視圖
可組合服務的解決方案實現可以有多種選擇，如下圖中所示的示例利用圖形數據庫實現了可組合服務。
圖數據庫對于不同對象/實體之間的連接建模非常有用。在這種情況下，對象/實體就是通過不同機制(API、事件驅動等)連接起來的微服務本身。在有許多復雜相互關系的服務/API(每個關系由不同的屬性驅動)需要連接在一起的情況下，這種方法可能很有用。
另一種方法是利用規則引擎或AI-ML模型來驅動可組合性。
可組合架構模式
以下部分解釋了一種代表性的架構模式以及如何實現可組合架構。以下是架構模式的關鍵組件：
微應用—— 數字場景中的典型事件生成器
事件主干—— 事件主干處理整個事件檢測、傳播和處理
通道服務—— BFF 服務，實現特定于通道的實現
SOR - 記錄系統
事件處理—— 將技術事件轉換為業務事件的事件處理引擎
事件主題—— 為不同目的傳播的不同主題
事件存儲—— 時間序列數據庫，幫助實現交易補償
事件操作關聯 - 將事件映射到要執行的操作的名稱值存儲，以便后續無論是調用特定 API 還是要啟動流程編排
API 網關
領域服務—— 封裝業務功能的所有領域服務
API 注冊表 ——API 發現注冊表
流程編排組件
流程編排注冊表—— 該注冊表有助于根據"事件動作關聯"組件提供的業務事件發現需要觸發的流程。
流程編排綁定器—— 該組件在運行時綁定 API ，以便為流程編排提供靈活性。對流程的編排的任何更改都映射到該組件，以便實現必要的組合性。這會生成BPMN 的執行腳本，這些腳本將被傳播到流程編排執行器 。
流程編排執行器—— 該組件監聽流程編排執行的狀態并管理流程的狀態。它是流程的運行時組件，類似于流程引擎，但輕量級且適用。
流程編排補償—— 這是業務流程回滾所需要的框架，用于處理由于多種原因導致的流程失敗。
通知—— 通知組件將編排狀態傳遞給事件主題，以便所有的訂閱者可以使用相同的內容。
結論
本文的目的是介紹可組合架構的核心原則及設計方法，并重點介紹了一個行業場景，并闡明了如何使用圖形數據庫實現可組合服務。
原文鏈接：
https://dzone.com/articles/composable-architecture?fromrel=true
譯者介紹
崔瑩峰，51CTO社區編輯，一名70后程序員，擁有10多年工作經驗，長期從事 Java 開發，架構設計，容器化等相關工作。精通Java，熟練使用Maven、Jenkins等Devops相關工具鏈，擅長容器化方案規劃、設計和落地。
