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