作者丨榮多君

1、前言

互聯(lián)網(wǎng)時代演進(jìn)到現(xiàn)在，在 5G 和 IOT 的影響下，整個人類社會實現(xiàn)全產(chǎn)業(yè)數(shù)字互聯(lián)的愿景變得逐漸清晰，某個行業(yè)通過行業(yè)標(biāo)準(zhǔn)的制定，采用同一套標(biāo)準(zhǔn)，甚至同一套軟件，通過行業(yè)領(lǐng)域能力的復(fù)用，來快速構(gòu)建產(chǎn)業(yè)平臺，并通過需求的更新與場景的優(yōu)化，來不斷積累行業(yè)的量變，最終形成質(zhì)變。而 B 端，正是實現(xiàn)產(chǎn)業(yè)數(shù)字互聯(lián)的重要組成部分，因此，以 AT 為代表的大廠都開始把目光指向了 B 端。

與傳統(tǒng)的 B 端軟件交付廠商不同，各互聯(lián)網(wǎng)大廠憑借雄厚的產(chǎn)品與技術(shù)實力，大都已完成 C 端的業(yè)務(wù)與技術(shù)基礎(chǔ)設(shè)施建設(shè)，因為技術(shù)具有通用性，因此，暨希望通過現(xiàn)有產(chǎn)品和技術(shù)進(jìn)行小規(guī)模的改造，來滿足 B 端（Saas 化或私有云）交付和部署，便成為各個廠商的普遍思路。

但要真正走向 B 端，做好賦能和服務(wù)，還會面臨許多困難。

2、To B 的難點

簡而言之，就是要解決“集成與被集成”的問題。

2.1. 集成與被集成

對 to B 領(lǐng)域的認(rèn)識很容易陷入到無邊界的陷阱中，從技術(shù)和產(chǎn)品的角度去評估會認(rèn)為都可以做，實際上進(jìn)入更廣泛的領(lǐng)域之后，會發(fā)現(xiàn)各行各業(yè)大多都有自己獨特的知識體系和產(chǎn)品，一套體驗、一套流程、一套配置很難包打天下。這時，廠商就會考慮更新戰(zhàn)略，重塑業(yè)務(wù)邊界，通過引入 SI 與 ISV 來構(gòu)建產(chǎn)品生態(tài)。

引入 SI 與 ISV，除了是一種思想戰(zhàn)略的轉(zhuǎn)變，同時也是技術(shù)的變革，是從提供一個從頭到尾的完整解決方案，變?yōu)閯e人解決方案的一部分，成為 inside，實際上要求是更高了，包含了從產(chǎn)品的被集成，到技術(shù)的被集成，到生態(tài)的被集成。

2.2. 被集成的難點

本文主要談技術(shù)方面。

以近些年，互聯(lián)網(wǎng)企業(yè)在 To B 領(lǐng)域的實施情況來看，很多成功都是依靠投入很多精兵強(qiáng)將才做成的，說明互聯(lián)網(wǎng)企業(yè)，其技術(shù)面對復(fù)雜場景，離標(biāo)準(zhǔn)化輸出、快速復(fù)用、方便二開還有一定的距離。To B 解決方案無論是在公有云還是專有云上，和自有技術(shù)產(chǎn)品實施相比，存在很多差異和問題：

• ISV、SI 和客戶自己的實現(xiàn)難以保證效果；
• 標(biāo)準(zhǔn)產(chǎn)品與定制開發(fā)要筑起柵欄，實施二開不能泄露核心代碼；
• 開發(fā)完成的前后端組件，需要結(jié)構(gòu)化沉淀成為可復(fù)用的二方庫；
• 前后端組件往往無法直接復(fù)用，特別是業(yè)務(wù)級別組件；
• 產(chǎn)品化的程度、產(chǎn)品說明文檔的完善和易用；
• 開發(fā)一個產(chǎn)品的方法論、流程和平臺；

To B 的產(chǎn)品能否成功，取決于生態(tài)，生態(tài)取決于能否吸引到 ISV 和 SI，而吸引到 ISV 和 SI 的關(guān)鍵環(huán)節(jié)，在于平臺能否滿足 ISV 和 SI 的需求。

落到更細(xì)節(jié)的技術(shù)方面，SI 與 ISV 需要什么？

靈活定制：前后端都提供靈活的二開機(jī)制，前端提供搭積木的自由組裝的能力；后端提供靈活的功能擴(kuò)展能力，能夠?qū)⒍ㄖ拼a與核心代碼完全分離；同時支持流程定制、元數(shù)據(jù)擴(kuò)展、服務(wù)編排。

快速交付：盡快產(chǎn)出原型（方便復(fù)用）、盡快交付產(chǎn)品（積木式、配置化地組合業(yè)務(wù)，基于基線能力快速地擴(kuò)展和定制能力）。

提高生產(chǎn)率：提供功能完整的應(yīng)用開發(fā)平臺，并提供主流 IDE、Maven 插件來提升開發(fā)效率效率，基于 CICD 平臺來實現(xiàn)打包部署自動化。To B 端常見的表單和列表的 CRUD，能夠直接根據(jù)視圖生成邏輯并映射到數(shù)據(jù)對象和物理表。

WORA：Write Once，Run Anywhere，前端一套代碼能夠在 PC、Mobile、小程序運行（Electron、flutter、taro1.3 等框架提供了技術(shù)上的可行性）。

Hotpatch：以往比較成熟的方案是移動端基于 jspatch、multiDex 等方案實現(xiàn) hotpatch，但由于 ios 管控及小程序生態(tài)的崛起，目前小程序化成為 hotpatch 的主流選擇。

運行時態(tài)可配置：提供線上前后端的配置平臺，實時生效。

使用門檻低：提供所見即所得的開發(fā) IDE，并且支持各種主流語言。

學(xué)習(xí)成本低：可視化開發(fā)平臺；完備的文檔、Demo、視頻；使用引導(dǎo)和幫助；playground、官網(wǎng)或開發(fā)者社區(qū)。

可以看到，To B 的軟件開發(fā)考慮的維度要多于自有產(chǎn)品技術(shù)實施，它所面對的不僅僅是有和無的問題，關(guān)鍵在于平臺的整合建設(shè)，這么說，未來 To B 戰(zhàn)場的，誰最先整合出領(lǐng)域技術(shù)平臺，誰就能握有生態(tài)，誰就能成為事實上的標(biāo)準(zhǔn)和規(guī)范。

2.3 解決難點要考慮的方面

要設(shè)計一個解決 ISV 和 SI 的痛點、滿足業(yè)務(wù)開發(fā)和擴(kuò)展的需要，具備靈活的二開能力，并且方便使用的 To B 應(yīng)用開發(fā)平臺，需要考慮很多方面：

首先，從分層的角度來看，管理一個 To B 的產(chǎn)品或解決方案，要有一個可視化的研發(fā)過程管理平臺

向 ISV 及 SI 提供統(tǒng)一的研發(fā)過程管理平臺、注入統(tǒng)一的開發(fā)流程和理念是非常有必要的，這不僅可以降低合作伙伴接入生態(tài)的難度，也可以增強(qiáng) ISV 和 SI 進(jìn)行項目開發(fā)的規(guī)范性；同時基于平臺對項目過程數(shù)據(jù)進(jìn)行結(jié)構(gòu)化地存儲，以利于后續(xù)利用大數(shù)據(jù)進(jìn)行效率、利潤、成本的核算。這個研發(fā)過程管理平臺包括項目管理功能，同時對接前端和后端平臺進(jìn)行開發(fā)，并且提供質(zhì)量管理和人員管理的工具，最后可以方便對解決方案和項目進(jìn)行集成和發(fā)布。

其次，平臺整體架構(gòu)應(yīng)該如何分層，各層的數(shù)據(jù)模型應(yīng)該如何定義，數(shù)據(jù)模型之間如何進(jìn)行映射和轉(zhuǎn)化。比如前端與業(yè)務(wù)后端的銜接，定義一套標(biāo)準(zhǔn)的 View Object 對象（包括擴(kuò)展標(biāo)簽），由 API GW 進(jìn)行解耦，通過視圖 id 或 name 進(jìn)行數(shù)據(jù)操作。再次，ISV 與 SI 的客戶定制代碼與核心產(chǎn)品代碼如何完全隔離，這里涉及到兩個二方面：

• 首先說前端，前端架構(gòu)由傳統(tǒng)的 Page Route，改為 Component Route，Page 變?yōu)榧兇獾娜萜?，這樣帶來的巨大好處是，UI 組件與 Page 解耦，使得 UI 組件成為類似于微服務(wù)一樣的獨立實體，這樣，UI 組件就可以脫離 Page 實現(xiàn)任意的組合，這就是“積木式”，同時，UI 組件，可以提供 Setter 擴(kuò)展方式來增強(qiáng)組件功能、展示、甚至綁定不同的后端 API，實現(xiàn)二開；
• 再來說后端，將基礎(chǔ)能力和業(yè)務(wù)定制能力分層，兩者提供不同的注解（@Domain 代表領(lǐng)域基本業(yè)務(wù)，@Business 代表領(lǐng)域定制業(yè)務(wù)），行業(yè)定制基于基礎(chǔ)能力所暴露的 SPI 進(jìn)行定制開發(fā)，在不修改基礎(chǔ)能力代碼的前提下，實現(xiàn)功能的定制，基礎(chǔ)能力和業(yè)務(wù)定制能力都支持通過 SPI 來定義服務(wù)的擴(kuò)展點；數(shù)據(jù)層面，通過定義數(shù)據(jù)視圖，對不同元數(shù)據(jù)進(jìn)行聚類、組合，以實現(xiàn)運算的目的，同時能夠以不同的形式對后端數(shù)據(jù)進(jìn)行展現(xiàn)。

然后，業(yè)務(wù)流程如何編排，這里業(yè)界有不同的做法，本文中推薦在前端基于組件實現(xiàn)可視化的業(yè)務(wù)流，在微服務(wù)的架構(gòu)下，前端組件一般 1v1 對應(yīng)后端接口，通過用可視化（組件之間的關(guān)系連線）方式定義前端組件之間的調(diào)用關(guān)系，間接建立后端功能流程的調(diào)用鏈。

再后，基于 API 網(wǎng)關(guān)實現(xiàn)前后端的分離，實現(xiàn)接口級別的熔斷、權(quán)限、安全、降級等策略；同時提供日志管理和異常監(jiān)控（包括穩(wěn)定性監(jiān)控和業(yè)務(wù)異常監(jiān)控）。

最后，基于 CICD 平臺，能夠基于 yaml 將前后端應(yīng)用單個或整體快速拉起，以實現(xiàn)解決方案級別的快速部署和升級。同時自動將產(chǎn)品的功能模塊沉淀回中臺，并將項目過程數(shù)據(jù)作結(jié)構(gòu)化存儲，作為二次開發(fā)的基礎(chǔ)能力。

3、應(yīng)用開發(fā)平臺的架構(gòu)設(shè)計

根據(jù) 2.3 的考慮，一個完整的 To B 應(yīng)用開發(fā)平臺架構(gòu)總體可以劃分為 5 個部分，分別是項目管理層、前端拼裝層、后端能力層、底層框架和 Runtime Infrastructure。

項目管理層主要是提供一個研發(fā)過程管理平臺，方便 ISV 和 SI 可視化管理項目和需求，對接 Runtime Infrastructure，并提供前后端開發(fā)工具。

前端拼裝層分為二部分，基礎(chǔ)部分與 APIGW 對接，基于 VO 建模，可視化配置和綁定業(yè)務(wù)能力接口；拼裝部分基于可視化編輯器提供前端組件的積木式組裝。

后端能力層分為二部分，基礎(chǔ)能力封裝業(yè)務(wù)核心代碼，用于快速構(gòu)建基線能力；定制能力主要基于 SDK 進(jìn)行定制開發(fā)，基于 SPI 擴(kuò)展點，利用多態(tài)特性實現(xiàn)定制。

開發(fā)框架主要是提供 SDK（封裝注解及定義）方便定制開發(fā)、vs studio plugin 和 maven 插件用于打包發(fā)布。

Runtime Infrastructure 包括 CICD、日志、運行監(jiān)控、自動化測試等能力。

一、研發(fā)過程管理平臺的架構(gòu)設(shè)計方案

除了編碼采用線下開發(fā)（提供必要的 plugin、sdk，如果部署方式走 serverless，可以考慮集成 monaco 進(jìn)行定制，實現(xiàn)線上 coding->compile->test->deploy 一體化），其它包括項目管理、需求管理、版本管理、工程管理均可在該平臺上集成并進(jìn)行日常管理。同時，研發(fā)過程管理平臺還可通過對接前端開發(fā)平臺、后端開發(fā)平臺、CICD 平臺、質(zhì)量管理平臺、帳戶體系形成一個完整的應(yīng)用開發(fā) studio。

二、前端業(yè)務(wù)組件拼裝的架構(gòu)設(shè)計方案

裝修編輯器：提供支持相對布局絕對布局的編輯器，提供包括頁面布局調(diào)整、樣式調(diào)整、組件拖拽展示、預(yù)覽、屬性設(shè)置在內(nèi)的所見即所得的功能體驗。

復(fù)用沉淀機(jī)制：前端拼裝的基本粒度是業(yè)務(wù)組件，能完成具體業(yè)務(wù)動作的，與后端能?連接的（可選）業(yè)務(wù)組件，? ?交互 / 基礎(chǔ)組件。舉例來說，商品列表、購物車、買家訂單列表都是前端拼裝中的組件，? Button 、Input 、Toast 等屬于基礎(chǔ)組件（Base Component），不是前端拼裝會操作的組件級別。版本發(fā)布時，新開發(fā)或修改的組件經(jīng)過 webpack 打包成 npm 包，上傳 npm 倉庫，用于下次開發(fā)復(fù)用。

業(yè)務(wù)流編輯器：用于描述前端組件之間關(guān)聯(lián)關(guān)系的編輯器（所謂關(guān)聯(lián)關(guān)系，目前可以淺顯地表現(xiàn)為組件跳轉(zhuǎn)顯示關(guān)系，實際上由于每個業(yè)務(wù)組件都與后端 API 關(guān)聯(lián)，也代表了后端的調(diào)用流程），提供 4 種基礎(chǔ)概念元件，分別為 Process、Branch、Begin、End，每個概念元件均可以綁定特定業(yè)務(wù)組件，在編輯器上將概念元件連線，然后通過組件內(nèi)部實現(xiàn)的“出入口”機(jī)制，實現(xiàn)組件與組件之間的跳轉(zhuǎn)關(guān)系。

頁面管理：頁面在業(yè)務(wù)組件化的前端系統(tǒng)中，作為業(yè)務(wù)組件的容器，承載布局信息。

后端服務(wù)綁定：每個組件都能有選擇地綁定 1 到多個后端 API，當(dāng)點擊該組件中某個控件的響應(yīng)操作時，會觸發(fā)對后端 API 的調(diào)用。這樣的好處是，解決方案部署的同時復(fù)用了前后端的功能和體驗，可以快速生成原型或交付件。

同時，為了提升開發(fā)體驗和效率，需要配套提供開發(fā) SDK、集成開發(fā)環(huán)境的插件（vsc plugin 等）、以及包括配置、告警、監(jiān)控、A/B Test 等在內(nèi)的公共基礎(chǔ)能力。

三、后端開放性架構(gòu)設(shè)計方案

由后端服務(wù)提供服務(wù) SDK，前端組件通過該 SDK 對后端網(wǎng)關(guān)暴露的 API 進(jìn)行綁定，事實上建立了業(yè)務(wù)組件與后端服務(wù)的關(guān)聯(lián)關(guān)系，這種綁定方式是去代碼化的，并且基于精巧設(shè)計的、對象化的、功能兼容的接口（例如 graphql）可以實現(xiàn)動態(tài)切換（免代碼修改）。

Domain Service（領(lǐng)域服務(wù)）通過對領(lǐng)域功能和流程進(jìn)行抽象，提供基線（標(biāo)準(zhǔn)）功能，并對領(lǐng)域數(shù)據(jù)封裝原子級別的操作入口。

Business Service（業(yè)務(wù)服務(wù) / 定制服務(wù)）基于 Domain Service 提供的擴(kuò)展點（SPI）實現(xiàn)功能和流程的定制。

Domain 和 Business 可以實現(xiàn)完全的代碼隔離，這對于生態(tài)的知識產(chǎn)權(quán)保護(hù)非常關(guān)鍵。

DB 和數(shù)據(jù)訪問層主要作用是對 Domain 標(biāo)準(zhǔn)定義進(jìn)行領(lǐng)域數(shù)據(jù)建模，同時針對業(yè)務(wù)提供數(shù)據(jù)建模的擴(kuò)展能力，并且服務(wù)于 B 端，還需要充分考慮租戶間數(shù)據(jù)隔離和數(shù)據(jù)跨應(yīng)用聯(lián)通的方案。

3.1 前端的開放性設(shè)計

前端的開放性設(shè)計涉及到 4 個維度：業(yè)務(wù)組件、沉淀與復(fù)用、業(yè)務(wù)流、組件的擴(kuò)展。

3.1.1 組件業(yè)務(wù)化及跨平臺化

這里的業(yè)務(wù)組件，如前面所述，是能夠觸發(fā)或完成一個業(yè)務(wù)動作、與后端能力連接的業(yè)務(wù)組件，??交互 / 基礎(chǔ)組件。這樣，一個業(yè)務(wù)組件實際上封裝了端到端的邏輯（前端的操作、體驗，后端的功能、數(shù)據(jù)）。使用一個業(yè)務(wù)組件，實際上也使用了與其綁定的后端能力和數(shù)據(jù)

另外，由于 To B 市場在端側(cè)的多樣性，從成本的現(xiàn)實考慮，前端組件跨平臺的需求也非常常見，近幾年，由于 Electron、微信小程序、RNWeex 等技術(shù)的成熟，類 html css js 已經(jīng)成為事實上跨多端的首選技術(shù)。

PC 端與 Mobile 端由于體驗的差異，組件往往不能共享，但通過一定的表現(xiàn)式語法抽象（suning DSL），通過提供 DSL parse sdk 對抽象語法解析，提供更高層次響應(yīng)式的解釋和適配（如，在 PC 端可以解釋渲染為 List，在 Mobile 端可以解釋渲染為 ListView），可以在一定條件下實現(xiàn) Write Once Run Anywhere。

3.1.2 沉淀與復(fù)用

前端工程在開發(fā)之初，定義 PRD（這種 PRD 是一種電子化的，可結(jié)構(gòu)化定義并存儲的 PRD），并在平臺上創(chuàng)建解決方案。

復(fù)用：新迭代或新應(yīng)用開發(fā)時，根據(jù)業(yè)務(wù)需求，可以到業(yè)務(wù)組件倉庫中尋找（類似于 AppStore），如果是已有且可復(fù)用能力，則由平臺直接添加 NPM 依賴到對應(yīng)開發(fā)工程中，對于不具備的能力，標(biāo)識為 todo。

沉淀：當(dāng)業(yè)務(wù)組件開發(fā)完成，通過在 CICD 平臺配置腳本，同時沉淀業(yè)務(wù)組件的 NPM 包，并更新 PRD，為下次復(fù)用準(zhǔn)備。

這種沉淀和復(fù)用機(jī)制，以業(yè)務(wù)功能維度進(jìn)行，實現(xiàn)了代碼的完全隔離，并依賴平臺，可實現(xiàn)完全的自動化。

3.1.3 業(yè)務(wù)流

單獨對組件粒度進(jìn)行復(fù)用依然會帶來不必要的重復(fù)工作量，同時組件間也需要?種機(jī)制進(jìn)行串聯(lián)。頁面組是?種?式，將?個高度相關(guān)的頁面做成?個頁面組，彼此通過相對 url 串聯(lián)。但某些交叉頁面（例如商家后臺首頁）可能會是多個業(yè)務(wù)行為的入口，包含多個業(yè)務(wù)組件，如果有關(guān)系的頁面都做成頁面組，那?個頁面組可能會包含很多個業(yè)務(wù)?為；如果將這種交叉頁面從頁面組中拿掉，?會導(dǎo)致頁面組本身不完整；后臺系統(tǒng)較少交叉頁面，而前臺系統(tǒng)會有很多。所以通過定義業(yè)務(wù)流（操作流），并定義等價組件（Equivalent Component），來解決上面的問題，使分解?個站點成為多個業(yè)務(wù)行為并再組合成為可能。

3.1.4 組件的擴(kuò)展

首先，通常的業(yè)務(wù)組件，其邊界是模糊的，并且與應(yīng)用頁面的緊密耦合，導(dǎo)致其無法被內(nèi)聚實現(xiàn)，并進(jìn)行復(fù)用。其原因主要有兩點：

1、應(yīng)?內(nèi)邏輯由 url 串聯(lián)，url 屬于應(yīng)?全局的信息，但會出現(xiàn)在業(yè)務(wù)組件內(nèi)部；

2、使?全局狀態(tài)管理，組件間共享狀態(tài)，但往往未經(jīng)過良好 設(shè)計，導(dǎo)致組件間有隱式的互相依賴；

因此，需要將顯式的 url 從組件內(nèi)移除，引入出口概念，組件自定義出口（行為和參數(shù)），將出口行為和出口目標(biāo)分離，并提供業(yè)務(wù)組件級別的狀態(tài)管理，狀態(tài)可在業(yè)務(wù)組件內(nèi)的繼承組件間共享，但不可以在業(yè)務(wù)組件間共享。

其次，由于組件具有業(yè)務(wù)屬性，而業(yè)務(wù)之間往往存在一種固有的流程機(jī)制（如加車 ->下單 ->支付），通常的方案，是建立一組 Page 的集合（Page Group），彼此通過相對 url 建立關(guān)聯(lián)。但某些 Page 包含多個業(yè)務(wù)行為的入口（如首頁樓層），如果有關(guān)系的 Page 都做成 Page Group，那一個 Page Group 可能會包含很多個業(yè)務(wù)行為，無法復(fù)用；如果將這種場景排除掉，又會導(dǎo)致方案本身的不完整。因此，基于頁面來復(fù)用這種業(yè)務(wù)關(guān)聯(lián)是不合適的（如前所說，Page 只是一種容器）如果建立一種串聯(lián)機(jī)制，可以動態(tài)地定義業(yè)務(wù)組件之間的關(guān)系，便可以脫離 Page 的限制，實現(xiàn)真正的解耦。

因此，可以引入業(yè)務(wù)流（操作流）的概念，動態(tài)地定義組件之間的關(guān)聯(lián)關(guān)系，使復(fù)雜業(yè)務(wù)關(guān)系的復(fù)用和重組成為可能。

業(yè)務(wù)流（操作流）是一組具有關(guān)聯(lián)關(guān)系的業(yè)務(wù)組件的集合，通過數(shù)據(jù)結(jié)構(gòu)定義組件之間的關(guān)聯(lián)關(guān)系，通過這種方式將業(yè)務(wù)流觸發(fā)條件和行為封裝在操作流內(nèi)部，不再受 UI 變化的影響，也就規(guī)避了以往頁面變化時，url 和調(diào)用方式需要重新實現(xiàn)的問題。

實現(xiàn)組件間跳轉(zhuǎn)的邏輯：

1、Component 描述出口方法和數(shù)據(jù)對象

2、在業(yè)務(wù)流（Business Unit）中獲取 SourceComponent 組件的出口 output 定義，執(zhí)行 output 方法，命中 TargetComponent。

3、獲取 TargetComponent 所在的 Page，匹配 output 或 URL，設(shè)定跳轉(zhuǎn)方式，并執(zhí)行跳轉(zhuǎn)。

最后，來講一下組件本身的擴(kuò)展。

UI 的實時響應(yīng)式擴(kuò)展：依賴于 ReactVueAngular 等響應(yīng)式前端框架，利用組件的單向 / 雙向數(shù)據(jù)綁定能力，當(dāng)組件的屬性發(fā)生變化時，VDOM 會對變更部分進(jìn)行實時的局部渲染。利用這個特性，我們可以設(shè)計一種組件的 Setter 機(jī)制，這是一種屬性的注入器，利用 js 實現(xiàn)，當(dāng)變更組件的某個屬性，比如背景色、分欄、圖片等，可以實時地對反饋到組件的展現(xiàn)部分。對于功能部分的擴(kuò)展：可以對組件現(xiàn)有能力進(jìn)行兼容或非兼容性升級，重新發(fā)布到線上，并通過組件更新機(jī)制來實現(xiàn)功能擴(kuò)展。

3.2 后端的開放性設(shè)計

前端組件應(yīng)對了業(yè)務(wù)場景化需求，但這個復(fù)用顆粒度對于業(yè)務(wù)邏輯和數(shù)據(jù)而言仍然比較粗，因為即使是不同的場景，內(nèi)部的邏輯和數(shù)據(jù)結(jié)構(gòu)依然可以復(fù)用。而且，后端大都采用了微服務(wù)架構(gòu)，各系統(tǒng)提供了原子接口，不同的原子接口匯聚成一個個標(biāo)準(zhǔn)業(yè)務(wù)流程，但在 To B 的生態(tài)中，定制與擴(kuò)展的場景很常見，比如：

基線提供的業(yè)務(wù)流程，在交付給 A 和 B 的過程中，都有存在定制變更的可能性，當(dāng)然，對于這種場景，可以通過在基線中做個功能全集，然后定義不同的業(yè)務(wù)參數(shù)或配置來開關(guān)，但還有些場景是開關(guān)和配置無法滿足的，比如互斥和擴(kuò)展的場景：

這個時候，要么拉分支自己改，但這樣做后續(xù)代碼分支多了很難合并收斂，增加運維成本；如果讓 ISV 和 SI 維護(hù)分支，又冒著核心代碼公開的風(fēng)險。

因此，如果能設(shè)計一種靈活二開的后端開發(fā)框架，由 ISV 和 SI 根據(jù)業(yè)務(wù)定制需求進(jìn)行擴(kuò)展，便有了必要性。

3.2.1 架構(gòu)和流程

將后端服務(wù)劃分為：網(wǎng)關(guān)、業(yè)務(wù)定制層和基礎(chǔ)能力層。其中網(wǎng)關(guān)主要作用是對外暴露 API，Business 和 Domain 的服務(wù)都負(fù)責(zé)各自領(lǐng)域的業(yè)務(wù)建模，包括自己的元數(shù)據(jù)建模和視圖建模，Business 和 Domain 都對外提供服務(wù)，不同的是，Domain 提供提 SPI，是可復(fù)用、可擴(kuò)展的點。而 Business 可以提供 SPI，也可以提供 API，視具備策略而定。

上圖是一個二開的示意流程，在每個變更點，添加待實現(xiàn)的 SPI，并在平臺結(jié)構(gòu)化落庫。在網(wǎng)關(guān)上添加（新增）或修改（現(xiàn)有）API，指向該 SPI，此時，前端可以在平臺上查詢到該新增的 API。通過元數(shù)據(jù)建模和視圖建模，并結(jié)構(gòu)化存儲到平臺上，前端可通過平臺查詢到視圖信息，根據(jù)視圖的 schema 可以進(jìn)行前端開發(fā)。后端則實現(xiàn)該 SPI，并通過 CICD 發(fā)布沉淀到平臺中，用于交付及后續(xù)復(fù)用。

3.2.2 SPI

SPI 是后端框架實現(xiàn)開發(fā)性設(shè)計的關(guān)鍵元素，它由服務(wù)的提供者來定義，確定命名空間、方法名、出入?yún)?，平臺上的 SPI 可以簡單對應(yīng)到 java 世界中一個單方法的 interface。

Business 和 Domain 對外暴露 SPI（Business 可以暴露 API），通過對 SPI 定義、迭代、調(diào)度、復(fù)用和沉淀實現(xiàn)能力的開放。

注解：

@BusinessSPI 業(yè)務(wù)應(yīng)用層 SPI 注解

@DomainSPI 領(lǐng)域中心層 SPI 注解

SPI 定義的步驟：

1、從平臺上創(chuàng)建的 git repo 上 clone 到可開發(fā)的 maven 工程

2、在工程目錄的對應(yīng)目錄中編寫 spi 定義，并加上 @SPI 注解

3、命名工程中提供的 maven 插件打包，插件會將 spi 信息抽取并提交到平臺。

4、平臺會生成實際可用的 jar 并發(fā)布到 maven 倉庫，返回操作成功與否等信息，開發(fā)者可以在編譯打印中查看。

SPI 定義的示例：

通過定義 SPI 對外暴露各類可定制點，利用 java 的多態(tài)性，針對不同的業(yè)務(wù)場景定制不同的 Impl。在實際的使用中，框架還需要支持 version、多租戶等層面的信息，用于確保路由的正確性。

目前的二開，主要是通過 SPI 的機(jī)制，在現(xiàn)有產(chǎn)品和解決方案的 Domain 能力基礎(chǔ)上進(jìn)行覆寫或擴(kuò)展，實際使用中，可能存在以下幾種情況：

1、給定的 SPI 抽象準(zhǔn)確，現(xiàn)有的實現(xiàn)代碼滿足要求，則直接使用現(xiàn)有鏡像。

2、給定的 SPI 抽象準(zhǔn)確，現(xiàn)有的實現(xiàn)無法滿足要求，則重寫一個新實現(xiàn)。

3、給定的 SPI 抽象不準(zhǔn)確，邏輯無法滿足要求，則定義一個新的 SPI 并實現(xiàn)。實際使用場景中，@注解還可以細(xì)分成多種：

1）命令式申明注解 @BusinessCMDSPI、@DomainCMDSPI

2）查詢式申明注解 @BusinessQuerySPI、@DomainQuerySPI

3.2.3 元數(shù)據(jù)

元數(shù)據(jù)提供 @Entity 注解來申明定義。

元數(shù)據(jù)不支持嵌套（主要是因為復(fù)雜，同時不是必要），一個 Entity 內(nèi)部的成員變量不能是 Entity。

元數(shù)據(jù)參數(shù)存儲上支持字段擴(kuò)展，采用屬性值表設(shè)計，原來應(yīng)用配置的數(shù)據(jù)源會退化為元數(shù)據(jù)后端的地址；元數(shù)據(jù)后端提供視圖映射功能，可以針對元數(shù)據(jù)直接做聚合查詢，并直接生成 SPI 及對應(yīng) SPI 的實現(xiàn)代碼。

Entity 定義后實際可能會映射到多張物理表，整體方案從技術(shù)上來說，主要難度在于事務(wù)處理上，目前來看短期內(nèi)沒法構(gòu)建一套可靠穩(wěn)定的方案，因此，操作內(nèi)部實現(xiàn)目前走 mapper 并直連數(shù)據(jù)源，但對外暴露統(tǒng)一的 load/save 方法。

定義及沉淀流程：

1、開發(fā)時，定義 Entity 并申明 @Entity 注解，通過 IDE 插件解析注解，將本地元數(shù)據(jù)定義 DSL Push 到平臺服務(wù)，平臺根據(jù)定義自動識別變更、合法性，生成物理庫表。

2、IDE 插件提供一套類似 lombok 的編譯器修改抽象語法樹的機(jī)制，給元數(shù)據(jù)提供 load/save 等方法。

3、增加元數(shù)據(jù) save 擴(kuò)展點方便 handle 業(yè)務(wù)代碼插入。

4、運行時，具體的 load 和 save 方法會調(diào)用元數(shù)據(jù)后端提供的 RPC 服務(wù)。

5、發(fā)布時，元數(shù)據(jù)地根據(jù) Application 類名，并變更自動生成的版本號。

3.2.4. 視圖

在 To B 的應(yīng)用中，表單和列表占據(jù)半壁江山，可以針對典型的中后臺應(yīng)用表單進(jìn)行抽象，輸出一份通用 scheme，基于該 scheme 進(jìn)行視圖建模。

業(yè)務(wù)上很多場景化查詢需求，如果這部分實現(xiàn)全部落到 Domain 層，對 Domain 層的穩(wěn)定性是個沖擊，視圖建模和視圖查詢主要應(yīng)對這些場景。

在后端平臺側(cè)提供視圖建模功能，可以自由搜索元數(shù)據(jù)，選擇需要的字段，組合成新的視圖，開發(fā)人員需要給出元數(shù)據(jù)字段到視圖字段的 mapping 關(guān)系，以及指定視圖的 id 作為唯一標(biāo)識，并進(jìn)行發(fā)布。

發(fā)布后，平臺自動生成對應(yīng)的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現(xiàn)，package 成 jar，并 Push 到 maven，對應(yīng)視圖的查詢和簡單的 CRUD 結(jié)果集便可自動生成。

如果修改視圖，在平臺上修改視圖字段，平臺重新生成相關(guān)的查詢 SPI 和實現(xiàn)，并自動變更視圖 version。

在視圖關(guān)聯(lián)數(shù)據(jù)庫方面，如果采用的是物理庫表，則可能會出現(xiàn)一個視圖對應(yīng)關(guān)聯(lián)多個庫表聯(lián)合查詢的情況，這個邏輯比較復(fù)雜，考慮了 2 種方案：

1、落到 es 進(jìn)行查詢，走 mysql->canal->es 的方案

2、走邏輯大寬表方案

3.3 前后端的銜接設(shè)計

同步 VO 與根據(jù) VO 獲取數(shù)據(jù)進(jìn)行分離，由 API GW 進(jìn)行解耦，通過視圖 id 或 name 進(jìn)行數(shù)據(jù)操作。前端通過特定接口獲取到該應(yīng)用的所有 vo，并進(jìn)行列表展現(xiàn)。每個 vo 都有對應(yīng)的 version，用于同步 VO 的變更。

前端平臺提供 loader 或 parser 解析視圖 VO，反向渲染生成組件。

后端平臺通過搜索元數(shù)據(jù)，選擇需要的字段，組合成新的數(shù)據(jù)視圖 -DO，后端平臺自動生成對應(yīng)的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現(xiàn)，package 成 jar，并 Push 到 maven，開發(fā)本地應(yīng)用。（對于某些 VO 和 DO 直接一對一映射的場景，前端也可以考慮直接使用 DO）

根據(jù)上圖，開發(fā)平臺的基本流程和各層功能為：

1、基本流程：數(shù)據(jù)對象 DO->SPI->API->展現(xiàn)視圖 VO->組件 ->UI，前端業(yè)務(wù)組件直接與后端 SPI 及數(shù)據(jù)對象進(jìn)行映射。

2、前端拼裝：

1) 提供編輯器，支持絕對布局和相對布局，可以由 VO 直接生成業(yè)務(wù)組件；也可以采用類 Axure 手工拼裝成組件，并綁定后端 API。

2) 支持基于現(xiàn)有業(yè)務(wù)組件，通過業(yè)務(wù)流（操作流）和 Setter 機(jī)制來擴(kuò)展組件能力。

3、后端能力：在 Business 和 Domain 都支持通過 SPI 來定義服務(wù)的擴(kuò)展點，ISV 和 SI 可以在不修改原有邏輯的基礎(chǔ)上，通過替換 SPI 來實現(xiàn)功能的替換、升級和擴(kuò)展。

4、數(shù)據(jù)層面：通過將前端組件與后端 SPI 及數(shù)據(jù)對象進(jìn)行映射，若對元數(shù)據(jù)對象進(jìn)行新增或變更時：

1）可以直接動態(tài)變更 UI 的展現(xiàn)形式和內(nèi)容，無須修改前后端代碼

2）通過定義數(shù)據(jù)視圖，能夠根據(jù)業(yè)務(wù)訴求，對不同元數(shù)據(jù)進(jìn)行聚類、組合、以實現(xiàn)運算的目的，同時能夠以不同的組件形式對后端數(shù)據(jù)進(jìn)行展現(xiàn)

4、結(jié)語

從云計算的發(fā)展趨勢來看，從 Iaas 開始，未來必將在 Saas 結(jié)束（Paas 因為包括各種標(biāo)準(zhǔn)化組織和開源社區(qū)的存在，未來少有溢價的可能）。而 Saas 也是議價空間和增值空間最多的地方，未來哪家企業(yè)能夠首先完成對各個行業(yè)和領(lǐng)域的在核心生產(chǎn)流程和業(yè)務(wù)抽象，整合更多更優(yōu)秀的 ISV 和 SI 資源、甚至社區(qū)的力量，誰就能成為事實上的標(biāo)準(zhǔn)。

對于 To B 領(lǐng)域的玩家，應(yīng)該走開放生態(tài)的道路，做生態(tài)，就是做標(biāo)準(zhǔn)；做平臺，就是做信任；做開放，就是做共贏。

作者簡介

榮多君，蘇寧科技集團(tuán) O2O 平臺研發(fā)中心副總監(jiān)，多年 ICT 及互聯(lián)網(wǎng)工作經(jīng)驗，曾先后就職于華為、阿里巴巴，現(xiàn)在蘇寧從事 O2O 新零售業(yè)務(wù)及平臺的建設(shè)，擅長前后端主流技術(shù)、移動互聯(lián)網(wǎng)平臺建設(shè)及服務(wù)治理、云原生及中臺技術(shù)。