大型銀行組裝式應用在數字生態基座落地實踐

　　 一、引言

　　組裝式應用程式是Gartner在《2022年重要戰略技術趨勢》中提出的十二項技術之一，主要是透過引入模組化的PBC使技術和業務團隊可以更敏捷、更有效地重用程式碼。那麼PBC是什麼？

　　業務能力包(PBC)是一種軟體定義的最小化的業務功能，專注於解決特定的業務問題。業務使用者在功能上可識別這些功能，旨在用於應用程式產品套件和自定義組裝應用程式體驗的構建基塊。PBC是資料架構和一組服務、API和事件通道的有界集合，可以被視為微服務的聚合,在功能上是完整、自治的體系，具有四大特性。

　　模組化：分成一組有凝聚力的元件。

　　自主性：自給自足，並具有最小的依賴性，以確保組成的靈活性。

　　編排式：透過 API、事件介面或其他技術手段，打包組合到流程流程或複雜事務中。

　　可發現：語義清晰和經濟的設計，使業務和技術設計者、開發者和活躍的應用程式都能訪問。　　

　　其中在編排式上，圍繞PBC和它的編排能力，帶來的問題就是我們本次特別引出的組裝式。從圖中可以看出原來有三個不同顏色的PBC，我們透過一定的方式對這三個PBC進行組裝從而形成一個新的應用，從而對外提供能力。

　　Gartner表示：“在動盪的時代，可組合的業務原則幫助企業機構駕馭對業務韌性和增長至關重要的加速變化。可組合的應用架構增強了業務適應性，而採用可組合方法的企業機構在新功能的實現速度上將比競爭對手快80%。”

　　在這個組裝過程中，必然有很多問題需要我們去探索和實踐：

　　如何組裝？

　　組裝的標準是什麼？

　　組裝時是否會存在一些安全風險？

　　……

　　那麼我行當時在建設的時候，為什麼會對標組裝式應用程式，是如何引進這個概念並且落地實施的？圍繞這個問題，首先介紹我行當時在建設時面臨的問題。

　　我行近幾年在大力建設金融生態場景，對外提供了很多SaaS應用，這一部分除了我行自建之外，我們也會與一些合作方進行合作。隨著無界融合、優勢互補、開放共贏的金融生態圈的不斷髮展，我行在面對客戶快速推出生態產品、提供一站式解決方案方面存在一定不足，以支撐應用組裝式開發方面有待提升，總結起來主要有以下四個方面的能力欠缺，分為技術和管理兩個部分：

　　技術上：

　　1）生態融合

　　缺乏統一的產品目錄和產品能力，沒有形成市場化的建設；

　　生態缺乏通用的基礎服務，如使用者、許可權、流程、資料訪問能力和使用者互動介面。

　　2）場景複用

　　非金融功能重複建設，獨立研發，缺乏場景級能力輸出；

　　金融功能存在各場景重複封裝。

　　管理上：

　　3）標準技術建設方案

　　生態建設統一標準有待完善，功能耦合度高，無法實現能力複用，導致重複造輪子，應用搭建效率低；

　　新場景建設需求日益頻繁，缺乏基於既有場景快速組裝能力的支撐。

　　4）統一管理運營

　　缺乏功能場景、共享服務標準、資料標準的統一管理標準；

　　缺乏生態場景級的可複用基礎框架、構件需求管理。

　　當時我們面對SaaS產品的建設中主要存在剛才提到的這些問題，未來我們如果還要更快速地發展，更快速地推出產品，我們必須針對問題提出一些解決方案。因此我們圍繞這些問題對標業界，發現組裝式開發在技術和業務方面都有一定的優勢，能夠快速組裝現有的業務能力，推出一個新的應用產品，最終我們選擇了組裝式應用程式開發落地。

　　 二、生態聯結器建設

　　接下來介紹我們的生態聯結器建設，這是我們當時在落地的時候形成的總體架構圖：　　

　　1、建設通用基礎服務

　　我們需要做一些生態融合，解決組裝的能力問題，其實就是要建設好通用的基礎能力。實現通用使用者、許可權、角色、機構、流程管理等基礎服務，提供資料共享訪問，打通生態產品場景融合。

　　在基礎能力方面，使用者中心、許可權管理和流程管理是比較基礎的，以及使用者選單、角色、機構等，基本上我們的每個SaaS應用建設時都會涉及，包括與行外合作方提供的SaaS應用進行融合的時候，都必須包含流程管理等基礎能力，這一方面是作為融合能力重點建設。

　　2、建設業務共享服務標準化輸出能力

　　在融合的過程中，我們需要提煉一些共性的業務共享服務(PBC)，類似於前幾年提的中臺，比如資金監管、專案中心、流程中心，並且圍繞這些能力支援PBC建設的配置化，比如樣式的自動適配、資料標準，以及快速組裝，我們也會專門制定一套資料共享的訪問，從而解決各個上市產品之間資料共享，以及資料共享中存在的安全問題和標準問題，實現資料標準化轉換和打通，實現產品場景的快速組裝能力和標準化能力。

　　3、提供研發支援基礎框架

　　在融合的基礎之上，從架構的分層來看，最底下就是提供基礎的技術能力支撐平臺，建立產品組裝平臺快速構築產品，以及一些技術標準框架，類似於我們業界熟知的Spring Boot，我們可能也會在上面做一定的封裝，形成適合我們應用的框架內容。

　　有了這些PBC的業務能力之後，我們會面向不同生態場景，比如當前國家在推廣鄉村振興，那麼在這一方面我們也會推出一些對應的SaaS產品供鄉村使用。

　　在生態場景的概念之上，我們額外提出了一個生態解決方案。從客戶角度來說，比如鄉村振興的生態場景，除了管理村裡的一些事務之外，可能也需要黨員管理，從技術層面我們關注的是場景和應用，但對於客戶而言，他關注的是功能和能力。未來我們會更進一步，面向不同的群體提供一些生態解決方案，比如智慧教育、智慧政務、新管家等。

　　藉助於組裝式應用程式開發理念，我們層層往上，透過不同的PBC形成一個新的生態場景，再透過不同的生態場景形成一個新的生態解決方案，從而打造生態場景融合能力+業務共享服務輸出+技術標準能力支撐，並配套完整的生態管理體系，實現生態場景快速建設，提供端到端統一服務的目標，這是我們的生態聯結器上的總體建設。

　　 三、業務服務包(PBC)落 地

　　從業務能力上來說，核心在於PBC的建設，所以著重再跟大家分享一下我們PBC落地的架構層面和設計層面上的規劃，從外部市場也就是客戶的視角梳理一些場景。

　　我行做得比較多的是一些金融的場景，對於我們來說，我們的概念中更多區分的也是金融和非金融，但其它一些企業在落地的時候，可能會有其它劃分型別。　　

　　我行提供的金融服務是比較豐富的，代收、支付、賬戶管理、資金監管，都是銀行傳統的優勢方面內容，然後我們重新整合形成共享服務包，為後面的產品快速上線提供支撐。

　　生態場景的不斷豐富，也帶來了一些新的非金融服務能力，我們將其劃分為通用領域和專用領域。

　　通用領域即基本上每個領域都能用到的，比如流程中心、積分管理。從客戶服務的角度分析，基本上都會設定積分，所以我們將積分管理設定為通用領域。

　　專用領域則是面向於特定的某一類場景或解決方案，將共性的內容抽取出來。

　　在具體實施的時候，我們也是對標組裝式應用開發和PBC的概念，支援“模組化、自主性、可發現、可配置”，其實關鍵點在於支援資料標準轉換和對外統一標準的服務輸出，包括統一資料欄位、統一介面標準、統一UI風格轉化。

　　尤其是UI風格方面，我們所說的統一UI風格，指的是統一UI風格的設計理念。面向不同的客戶提供的SaaS產品，客戶在UI風格上可能會有不同的需求，比如黨建方面則是紅色的顏色會偏多一些。同一個共享服務包，需要支援面向不同的客戶群體和SaaS產品能透過統一的UI風格進行適配。在最底層我們的技術細節實現的時候，也會支撐統一的資料欄位、資料標準的轉化。如果共享服務包在組裝的時候缺少了一套統一的標準，那麼組裝的時候必然會存在一些問題。

　　我們對於PBC落地的技術要求和管理要求如下：

　　1、技術要求

　　配置能力暴露：暴露選單、頁面UI配置介面，在產品複用業務時初始化設定選單、實現UI配置等配置功能的設定和初始化。

　　應用介面暴露：根據DDD思路對共享服務抽取介面，形成場景化的業務能力組合，並在組裝平臺進行發現。

　　對外輸出：支援轉換為開發態的業務元件，提供行外獨立部署。

　　2、管理要求

　　開展牽頭應用承建機制：由領域負責應用承接進行建設，按照單獨建設群組方式進行共享。

　　場景建設：在智慧教育、鄉村振興、政務等重點戰略重點突破，形成相關領域的業務能力包。

　　 四、組裝式應用開發

　　圍繞業務服務包的建設，我們當時也對標了組裝式應用開發的理念。

　　1、金融生態應用組裝平臺　　

　　我們規劃建設了一個金融生態應用組裝平臺，平臺主要分為三個部分：

　　首先是後設資料目錄，比如資料編排、資料標準和資料的動態整合，未來可能還有知識圖譜等概念做一些基礎的支撐；

　　後設資料目錄再上一層是應用模板，面向不同的場景，我們需要制定出不同的應用模板；

　　最上層是視覺化建設，針對不同模板下的業務服務包(PBC)進行組裝，同時也有支撐PBC建設的技術元件，透過平臺自由組裝。

　　透過這三層實現增量功能，包括增量產品、存量產品的快速生產，對於新產品可以透過組裝快速生成整個應用，存量則更多考慮如何相容和升級。

　　2、DDD設計思路

　　在實際落地開發的時候，對於PBC如何劃分，內部提供了什麼能力等問題，需要一套方法論支撐。業界上近幾年微服務比較熱門，DDD的思路也是用得比較多的，我們行內有一套業務建模的方法與DDD是相通的，透過建模梳理出了PBC的一些能力。第二步就是生成PBC，因為組裝是一個積木的概念，所以需要先生成積木，再組裝積木，最後生成一個完整的工程。

　　在業務建模方面，我們採用DDD設計思路，在架構層面引入六邊形架構。因為我們在建設的時候，傳統的應用會有一些分層的概念，但是程式碼可能會串層，發生邏輯的上移或下移，我們透過六邊形架構詮釋應用內部和外部差別，內外部透過介面卡互動進行隔離，內部聚焦領域服務，從而實現穩態領域層和適配層解耦。　　

　　從上圖可以看出，我們在原始的六邊形架構上做了一些延伸，也就是6個標紅的部分。我們在落地這套領域驅動設計的架構時，領域層聚焦於領域模型物件、領域服務、應用服務的設計和組合。相當於在業務建模的時候，會識別出來有哪些領域物件，圍繞著這些物件會有哪些服務和應用，這是最核心的內容。

　　物件工廠、領域事件和倉儲，我們的理解一定程度上是屬於技術實現，在技術實現上，透過物件導向的設計以及設計模式的引入，在物件建立、物件互動上達到靈活解耦。

　　物件工廠用於建立物件；

　　領域事件用於物件之間的資訊互動和解耦；

　　倉儲用於資料交換，比如我們在落地時，需要引入一些存量應用，一個實體可能對應到多張表，多張表則需要做一些拆分和整合，因此在倉儲上會做一些額外的工作內容。

　　針對這套DDD標準架構的落地，我們會有一個標準工程結構，明確工程結構設計，設計者可以和程式碼閱讀者交流領域和架構的設計意圖。圍繞這套工程建設，我們也有一套配套的工具支撐，總結標準應用結構生成、依賴檢查工具、標準資產元件/工具推薦等，一系列工具資產保證架構落地。

　　接下來我們透過一個例子介紹DDD的設計思路落地。其實DDD最核心的是一些聚合根和實體物件的抽取。我們行內有一套就是業務建模方法與DDD理論一脈相承，DDD裡的事件風暴我們行內稱為業務用例，就是透過一段話與業務人員討論業務場景和業務能力。主要流程如下：

　　首先找一些名詞，給這些名詞加上屬性，透過名詞之間的關係形成一個實體領域模型，我們稱為業務物件；

　　其次將實體物件進行聚合形成一個聚合根；

　　最後圍繞這些實體模型找一些相關的動作，如支付、提交，從而形成領域服務、交易服務等能力。　　

　　以某代理保險銷售應用為例：抽取保險協議的實體和值物件，做抽象類的聚合和設計。實體分為財險保單和壽險保單兩大類，值物件指的是保單上的各種屬性，包括產品資訊、公司資訊、保單期限、費率資訊等。未來我們在值物件設計上可能會做一些技術手段，透過定製手段自動化地動態展示前臺頁面等，形成了整個聚合根和實體的值物件，從事件風暴來講，也就是梳理出用例，再進行組裝式的開發。

　　3、低程式碼能力

　　組裝式開發離不開近幾年一直在談的低程式碼能力，我們也是透過低程式碼能力進行落地實踐。

　　採用低程式碼能力，生成程式碼符合標準工程程式碼結構，應用可自定義連線不同資料實體，基於實體自動生成對應的領域服務等相關PBC積木塊內容，同是針對多實體聚合可複用DDD設計的聚合根物件預先在資料庫建立虛擬實體從而自動生成。自動生成有以下幾點需要注意：

　　我們傳統針對表，實體可能是get、set方法，在DDD領域裡其實是貧血模型，未來我們設計一種充血模型，也就是實體還是會帶一些方法，我們現在已經能夠比較好地支援針對於實體的增刪改查的能力，圍繞實體生成物件服務。

　　我們在選中實體生成程式碼時，可以進行一定的定製，在增刪改查的基礎上，我們平臺會更多提供擴充套件能力的支援，比如聚合，平臺透過類似於DSL等一些指令碼的能力對其進行定製，讀取我們定製的一些內容，自動生成這一部分程式碼。　　

　　除了物件服務之外，圍繞實體也可能會有一些簡單的領域服務，也就是圖中標的業務服務，另外，我們行內在單元測試方面也是落地比較深的，因此所有程式碼我們都必須有對應的單元測試覆蓋。我們目前生成的單元測試符合行業要求，生成單元測試之後也是按照標準程式碼結構生成程式碼，圖中示例是以某應用中產品資訊實體為例。

　　針對實體物件生成的能力，比如增刪改查，我們抽取了多個應用進行分析，以某應用為例，應用中涉及80多張表（佔比30%）可以一次性透過低程式碼平臺直接生成，加速研發效率，剩下的可能需要額外進行組裝和定製再生成。

　　至此我們已經透過建模建出實體物件，也透過低程式碼方式自動生成了圍繞這些實體物件的一些基礎能力，這一部分能力就是我們之前提到的積木。

　　4、組裝

　　有了積木塊建設之後，我們接下來要進行的是積木塊的組裝，這一部分也是透過組裝式應用開發平臺完成。

　　1）整體設計　　

　　基於組裝式應用開發平臺，遵循“積木式”開發思想，按分層結構去做，透過日益豐富的技術積木塊和業務積木塊的靈活組裝，助力應用快速搭建應用基礎框架。

　　自動生成程式碼符合標準化目錄指引和包命名規則，從架構設計到程式碼生成是標準的一一對應關係，統一專案研發，引導開發人員踐行DDD模式。

　　根據清晰的工程目錄覆蓋物件設計的不同能力，形成穩態和敏態的有效區分，隔離圍繞物件自身的建設和對業務場景的建設，進一步展現圍繞物件開展系統建設的邏輯檢視。

　　2）業務元件編排

　　整體設計完之後，透過業務元件編排進行積木組裝，這一方面與低程式碼能力也是息息相關的。業務元件編排基於低程式碼能力生成的物件服務和業務服務進行自由組裝，可實現物件服務組裝生成新業務服務，也可支援業務服務組裝生成交易服務。　　

　　上圖的左側就是我們針對業務積木的組裝，業務積木塊有不同的分類，比如保險、教培等，同時許可權中心、流程中心、認證中心等基礎能力也包含在目錄裡，按一級、二級不同的目錄結構提供選擇。我們的技術人員要組裝成一個服務能力時，即可透過該平臺進行一些邏輯關係的組裝，比如可以在每條線上制定一些表示式條件，當某個值等於多少時則往哪個分支去做，從而透過組裝重新形成新的服務，完成對整個PBC內部的一些能力建設，形成一個新的PBC對外提供能力。

　　在目錄建設的時候，我們按照不同的PBC劃分模組化，生成的服務採用模組化開發思想進行組織，不同的服務聚合於不同的物理目錄下作為子工程存在，各服務子工程可獨立開發。不同的人或團隊能夠各自管理和維護各自的PBC能力，從IT架構指導組織架構調優，進一步提升開發解耦。

　　3）技術元件編排　　

　　技術元件編排透過對接已有技術能力，支援基礎能力以及技術元件的快速組裝。行內透過共建形成了一套標準的技術元件，可以將建設好的技術元件直接引入平臺，令大家自行選擇需要的元件和能力，從而為整個PBC的建設包括應用建設形成組裝。

　　5、生成應用工程

　　完成業務和技術的組裝之後，最後一步是生成整個應用工程。　　

　　1）首先是一站式生成應用基礎框架，統一一站式技術底座，大大提升應用工程搭建效率。我們引進了多套模板，如DDD、分層架構等，不斷豐富應用基礎框架，同時針對不同的節點梳理它們不同的能力，從而透過組裝平臺生成不同的節點的標準工程，如接入層節點則是路由、灰度、限流比較重要，批次的資料處理則進行檔案匯入匯出的一些技術構件。

　　2）一鍵快速運維能力接入，解決運維能力使用的最後一公里。平臺所提供10餘種生產運維元件包括應用監控、自隔離、人機密碼分離等基礎運維能力，自動整合應用的一些能力建設，避免重複造輪子。

　　3）對標雲原生能力，自動生成PaaS映象模板，解決了PaaS映象不同環境變數配置的問題，實現了PaaS映象模板制定從數天到分鐘級的跨越，大大提升上雲效率。

　　在Gartner提出的PBC如何組裝建設的基礎之上，我們對於PBC內部如何聚焦、組裝和建設做了更多更深層次的延伸，不只PBC間實現組裝，在PBC內建設時也支援組裝式開發。

　　 五、未來展望

　　1、標準能力

　　在實現行內PBC以及未來行外合作方PBC接入後，實現PBC之間的組裝需要制定一套標準的組裝規範，統一組裝能力，中國信通院也在今年7月份提出組裝式應用開發，並組織相關企業準備制定相應規範，我行也將擇機參與，以便融入行業生態，將著重從以下五方面推進：

　　通用能力：包括我們的通用工程、標準工程以及標準整合的一些能力，在落地時針對細分的不同型別制定不同的標準工程會更加精細化；

　　效能：生成的程式碼是否存在效能問題；

　　安全：程式碼生成是否安全；

　　適配：在標準工程生成時，比如Web節點上的XSS攻擊，能夠自動整合防XSS等的元件，進行頁面適配或組裝適配；

　　程式碼：程式碼的自研能力，以及低程式碼生成能力。

　　2、資料共享、資料標準、資料血緣

　　資料共享： PBC之間的一些銜接、互動；

　　資料標準：資料共享如何制定標準，我們是透過單獨的SDK包內部做一些資料共享的標準檢驗、安全管控等內容；

　　資料血緣：未來規劃要做資料血緣關係的分析，也就是將完成PBC組裝的資料共享和銜接之後的最終資料做一些大資料分析，在這個基礎上探索做資料血緣關係的分析，從而為後面SaaS產品的資料運營方面提供一些指導工作。