作者 | 佩里阿薩米、克里希納拉杰

譯者 | 崔瑩峰

策劃 | 云昭

從單一的單體應(yīng)用到迄今為止的微服務(wù)架構(gòu)，架構(gòu)風(fēng)格已經(jīng)走過了漫長的道路。每種風(fēng)格都有獨(dú)特的優(yōu)勢和復(fù)雜性。當(dāng)下，基于微服務(wù)的架構(gòu)適逢其時(shí)，它提供了靈活性、敏捷性，并由此給企業(yè)帶來了更提前的上市時(shí)間。然而，微服務(wù)體系結(jié)構(gòu)依舊存在嚴(yán)重的問題：在每個(gè)領(lǐng)域的即時(shí)功能的添加或排除方面缺乏可組合性。也就是說，所有這些架構(gòu)風(fēng)格都沒有提供可組合的能力。

對可組合架構(gòu)的需求更多是由業(yè)務(wù)和市場驅(qū)動(dòng)的，而不是由技術(shù)驅(qū)動(dòng)的。在目前的情況下，顛覆性創(chuàng)新既能發(fā)生在大范圍內(nèi)，也能發(fā)生在小范圍內(nèi)。本文討論了可組合應(yīng)用架構(gòu)的概念及其架構(gòu)模式。另外，為了充分闡述該架構(gòu)，本文引入了一個(gè)真實(shí)的行業(yè)應(yīng)用作為示例。

選擇架構(gòu)的前提已發(fā)生變化

時(shí)下，一個(gè)企業(yè)選擇何種技術(shù)或軟件的假設(shè)與前提發(fā)生了變化。雖然原則、政策和指導(dǎo)方針還是一樣的，但在大多數(shù)情況下，下列因素對產(chǎn)品、技術(shù)和開發(fā)的選擇也有了直接影響：

• 企業(yè)中現(xiàn)有的技術(shù)
• 所選用的技術(shù)選型在市場上的可用性
• 保證在基礎(chǔ)設(shè)施、知識產(chǎn)權(quán)和人力資源方面的已有投資
• 選擇的產(chǎn)品/技術(shù)如何應(yīng)對現(xiàn)有的IT環(huán)境

當(dāng)然，還有其他易見的收益，如TCO、ROI、上市時(shí)間等。

圍繞可變性：可組合架構(gòu)的魅力所在

眾所周知，每個(gè)架構(gòu)都是由"領(lǐng)域"和"映射到領(lǐng)域的功能"組成。每個(gè)功能又由一個(gè)或多個(gè)解決方案組件實(shí)現(xiàn)。

可組合架構(gòu)并不會偏離上述領(lǐng)域拆分原則；它只是不同于實(shí)現(xiàn)所需業(yè)務(wù)領(lǐng)域功能的組件的組合。

整個(gè)架構(gòu)圍繞可變性原則展開。這意味著可變性可能會發(fā)生在技術(shù)層，也可能會發(fā)生在功能中。

以風(fēng)險(xiǎn)管理框架為例，我們將其視為一個(gè)領(lǐng)域。這個(gè)領(lǐng)域需要和客戶打交道，并處理客戶各種緯度方面的數(shù)據(jù)，例如：

了解客戶畫像

財(cái)務(wù)適配分析

欺詐分析

關(guān)系分析

以上的每一個(gè)分析步驟需要全部完成，才能篩選有資格的客戶進(jìn)入金融機(jī)構(gòu)。實(shí)際上領(lǐng)域映射的"功能"則會根據(jù)技術(shù)和功能組件而有所不同，而這些組件像樂高一樣堆疊在每個(gè)領(lǐng)域上，如下面的示意圖所示：

讓我們以圖中的“KYC”為例，深入了解細(xì)節(jié)。下圖是一個(gè)包含四個(gè)樂高塊的KYC域，然而它從多個(gè)維度管理相同的功能“KYC”，每個(gè)維度都有自己的實(shí)現(xiàn)成本、操作成本、優(yōu)點(diǎn)和缺點(diǎn)。而且每一個(gè)緯度都適合不同的客戶群。例如，“X”代和“Y”代的客戶更喜歡視頻KYC或第三方，而老年人則更喜歡老式的手工分析方式，因?yàn)樗麄兊墓P跡可能不適合OCR。這就是可組合架構(gòu)帶來的可變性。

正如 Gartner 所指出的那樣：

到 2024 年，新 SaaS 和自定義應(yīng)用程序的設(shè)計(jì)口號將是“可組合的 API 優(yōu)先或僅 API”，將傳統(tǒng)的 SaaS 和自定義應(yīng)用程序視為“遺留系統(tǒng)。"

架構(gòu)風(fēng)格的演變

從單一的綠屏應(yīng)用程序到迄今為止的可組合架構(gòu)，架構(gòu)風(fēng)格已經(jīng)走過了漫長的道路。每種風(fēng)格都有額外的優(yōu)勢和復(fù)雜性。當(dāng)下，基于微服務(wù)的架構(gòu)適逢其時(shí)，它提供了靈活性、敏捷性和更提前的上市時(shí)間。然而，微服務(wù)體系結(jié)構(gòu)風(fēng)格卻在每個(gè)領(lǐng)域的即時(shí)功能的添加或排除方面缺乏可組合性。

所有這些架構(gòu)風(fēng)格都沒有提供可組合的能力，但是，微服務(wù)架構(gòu)以漸進(jìn)的方式提供了靈活性，從而提供了最大的靈活性和敏捷性。

對可組合架構(gòu)的需求更多是由業(yè)務(wù)和市場驅(qū)動(dòng)的，而不是由技術(shù)驅(qū)動(dòng)的。在目前的情況下，顛覆性創(chuàng)新既能發(fā)生在大范圍內(nèi)，也能發(fā)生在小范圍內(nèi)。例如，基于AI、基于ICR的KYC是KYC領(lǐng)域的創(chuàng)新，而像元宇宙這樣的東西是大規(guī)模的顛覆性創(chuàng)新，可能并不適合可組合架構(gòu)。

可組合架構(gòu)的關(guān)鍵原則

可組合架構(gòu)是一種完整的、全新的技術(shù)創(chuàng)新，它也是在流行的微服務(wù)架構(gòu)之上的一種增量式創(chuàng)新。如上一節(jié)所述，可組合架構(gòu)能夠在不影響架構(gòu)的模塊化或服務(wù)編排的情況下為特定領(lǐng)域添加或排除臨時(shí)功能。

需要遵循的兩個(gè)基本原則:

• API優(yōu)先：API成為提供和使用業(yè)務(wù)功能的基本理念
• 即時(shí)編排綁定：編排過程在運(yùn)行時(shí)被發(fā)現(xiàn)，就像服務(wù)被發(fā)現(xiàn)一樣。編排需要存儲在一個(gè)持久性或內(nèi)存數(shù)據(jù)庫中(圖形數(shù)據(jù)庫是一個(gè)很好的選擇，因?yàn)樗梢悦枋鲂蛄幸约疤娲窂?。

可組合服務(wù)邏輯解決方案視圖

以前面描述的幾個(gè)領(lǐng)域和功能領(lǐng)域?yàn)槔?，下面展示了涉及可組合服務(wù)的解決方案的邏輯視圖(與技術(shù)棧無關(guān))：

使用組合服務(wù)構(gòu)建的更大的解決方案包含以下核心框架功能：

除了單個(gè)或多個(gè)領(lǐng)域內(nèi)的可組合性之外，上述實(shí)現(xiàn)可組合性的方法也可以應(yīng)用于編制/編排層。

可組合服務(wù)解決方案實(shí)現(xiàn)視圖

可組合服務(wù)的解決方案實(shí)現(xiàn)可以有多種選擇，如下圖中所示的示例利用圖形數(shù)據(jù)庫實(shí)現(xiàn)了可組合服務(wù)。

圖數(shù)據(jù)庫對于不同對象/實(shí)體之間的連接建模非常有用。在這種情況下，對象/實(shí)體就是通過不同機(jī)制(API、事件驅(qū)動(dòng)等)連接起來的微服務(wù)本身。在有許多復(fù)雜相互關(guān)系的服務(wù)/API(每個(gè)關(guān)系由不同的屬性驅(qū)動(dòng))需要連接在一起的情況下，這種方法可能很有用。

另一種方法是利用規(guī)則引擎或AI-ML模型來驅(qū)動(dòng)可組合性。

可組合架構(gòu)模式

以下部分解釋了一種代表性的架構(gòu)模式以及如何實(shí)現(xiàn)可組合架構(gòu)。以下是架構(gòu)模式的關(guān)鍵組件：

微應(yīng)用—— 數(shù)字場景中的典型事件生成器

事件主干—— 事件主干處理整個(gè)事件檢測、傳播和處理

通道服務(wù)—— BFF 服務(wù)，實(shí)現(xiàn)特定于通道的實(shí)現(xiàn)

SOR - 記錄系統(tǒng)

事件處理—— 將技術(shù)事件轉(zhuǎn)換為業(yè)務(wù)事件的事件處理引擎

事件主題—— 為不同目的傳播的不同主題

事件存儲—— 時(shí)間序列數(shù)據(jù)庫，幫助實(shí)現(xiàn)交易補(bǔ)償

事件操作關(guān)聯(lián) - 將事件映射到要執(zhí)行的操作的名稱值存儲，以便后續(xù)無論是調(diào)用特定 API 還是要啟動(dòng)流程編排

API 網(wǎng)關(guān)

領(lǐng)域服務(wù)—— 封裝業(yè)務(wù)功能的所有領(lǐng)域服務(wù)

API 注冊表 ——API 發(fā)現(xiàn)注冊表

流程編排組件

流程編排注冊表—— 該注冊表有助于根據(jù)"事件動(dòng)作關(guān)聯(lián)"組件提供的業(yè)務(wù)事件發(fā)現(xiàn)需要觸發(fā)的流程。

流程編排綁定器—— 該組件在運(yùn)行時(shí)綁定 API ，以便為流程編排提供靈活性。對流程的編排的任何更改都映射到該組件，以便實(shí)現(xiàn)必要的組合性。這會生成BPMN 的執(zhí)行腳本，這些腳本將被傳播到流程編排執(zhí)行器 。

流程編排執(zhí)行器—— 該組件監(jiān)聽流程編排執(zhí)行的狀態(tài)并管理流程的狀態(tài)。它是流程的運(yùn)行時(shí)組件，類似于流程引擎，但輕量級且適用。

流程編排補(bǔ)償—— 這是業(yè)務(wù)流程回滾所需要的框架，用于處理由于多種原因?qū)е碌牧鞒淌　?/p>

通知—— 通知組件將編排狀態(tài)傳遞給事件主題，以便所有的訂閱者可以使用相同的內(nèi)容。

結(jié)論

本文的目的是介紹可組合架構(gòu)的核心原則及設(shè)計(jì)方法，并重點(diǎn)介紹了一個(gè)行業(yè)場景，并闡明了如何使用圖形數(shù)據(jù)庫實(shí)現(xiàn)可組合服務(wù)。

原文鏈接：

https://dzone.com/articles/composable-architecture?fromrel=true

譯者介紹

崔瑩峰，51CTO社區(qū)編輯，一名70后程序員，擁有10多年工作經(jīng)驗(yàn)，長期從事 Java 開發(fā)，架構(gòu)設(shè)計(jì)，容器化等相關(guān)工作。精通Java，熟練使用Maven、Jenkins等Devops相關(guān)工具鏈，擅長容器化方案規(guī)劃、設(shè)計(jì)和落地。