作者：京東科技 常姜洲
一、背景
近期參加公司組織的極客中餐廳訓練營，我們所在的小組接到的課題是微服務的低代碼平臺架構設計，目標是：結合京東業務研發實際情況，針對后端研發人員，設計一個微服務低代碼平臺，助力更高效低交付業務需求，現已結業，將我在本次專案中沉淀設計出的設計檔案整理成文，期待與大家有進一步的碰撞溝通
二、低代碼平臺整體技術架構設計
1、低代碼開發三階段
平臺為開發者的三個階段提供的核心功能：
-
開發階段：服務編排能力，提供可組合的方式系結事件源和事件消費者（函式、API、資料源管理等基礎能力）
-
部署階段：生成、托管、獲取、構建和打包代碼，
-
運維階段：為 Serverless 應用提供部署和服務支持，提供友好的日志系統，能夠幫助平臺工具使用者快速定位問題，提供對各種使用中間件狀態監控，避免工具平臺成為一個黑盒子
整個3階段如下圖所示：
2、低代碼平臺功能架構設計
角色與主功能說明：
本低代碼開發平臺的服務物件為開發者，旨在使用低代碼開發平臺，進行快速的微服務應用開發與部署，相對于傳統的開發與部署方式減少研發時間，降低成本
Low Code 開發面板：
提供整個低代碼應用開發生命周期的全功能的運營后臺面板，可以在此面板完成開發階段的各項配置、流程編排、腳本撰寫與除錯、部署等功能，
Low Code 控制面板：
提供各種服務治理，告警配置管理，配置管理等服務控制功能模塊
基礎功能說明：
? 提供觸發器、腳本函式、可視化函式的、連接器的開發與管理
? 提供多環境組態檔隔離
? 提供應用維度、函式維度監控相關配置
? 提供應用工程所有源檔案、各環境配置資料的的版本管理
部署功能說明：
提供在線構建應用工程，在線除錯函式、觸發器、連接器等功能，除錯完畢后可一鍵進行發布
特色功能：
為進一步提升業務域功能復用度，進一步減少重復功能開發的成本，同樣提供基于模板，函式擴展點等功能的快速復用湖開發
依賴：
? 方便與JSF體系內的服務更好的融合，接入JSF注冊中心API,進行JSF注冊服務的資訊獲取
? 與統一配置平臺打通進行在線配置變更的存盤與變更，平臺基礎配置的存盤與變更
? 存盤層，元資料使用關系型資料庫存盤，流程檔案、資源檔案使用物件存盤，源代碼等檔案使用git管理或者物件存盤
? 監控功能依賴貢獻現有的監控平臺 UMP 、SGM的 的OPEN API 實作
? 日志平臺，公司的日志平臺暫無OPEN API 可以共建、或者私有化部署一套實作
3、低代碼應用開發流程
應用生命周期4階段
開發與測驗、構建保存、發布、運行
-
用戶在編輯器中完成觸發器、連接器、函式等主要低代碼構件，可能復用已有模板和業務域能力進一步為開發提速
-
開發完成后可以根據屬性配置、語言環境構建打包函式鏡像，同時生成版本號，
-
發布版本，完成部署，
-
應用實體在運行時提供服務
廣義流程編排
? 可視化創建連接器
? 可視化創建觸發器
? 支持可視化創建函式流程，BPMN, 流程節點可以是函式物體或者連接器物體，流程關系支持運算式編輯
? 支持腳本撰寫創建函式，支持多語言：Groovy,Java
? 支持多環境配置資訊配置
? 支持配置通用函式、觸發器、連接器等監控，健康度指標收集配置
4、低代碼平臺技術架構
-
藍色部分是我們平臺重點建設的應用
-
流量入口主要分為京東內外部兩種流量入口
-
對于HTTP介面上層可以對接成熟的網關轉換為對低代碼應用的JSF呼叫即可，此部分本身已經實作 0代碼，無需重復建設
-
對于JSF介面可以使用低代碼應用的JSF介面觸發器呼叫
-
監控與告警主要還是以復用公司內部組件為主，基于OPEN API 封裝
-
下層主要依賴其他業務部門提供的JSF介面、各大中間件、存盤層以及外部的一些HTTP介面、特殊協議的介面，訊息等
5、低代碼平臺應用部署架構
-
每個低代碼平臺的應用都有一個代理服務（LC proxy）負責和平臺通信，指令下發，資料上報等
-
低代碼應用不改變現有應用的通信方式和現有的JSF介面、資料庫、快取等中間件使用原有方式通信
-
控制中心：負責給 proxy 發控制指令，配置指令、服務治理指令等
-
資料收集中心：負責收集低代碼運行時配置的健康度指標源資料、流量等其他運行資料收集
6、低代碼平臺各角色系統作業機制
7、低代碼平臺單機應用架構
單機運行環境簡介
單機應用架構
-
低代碼平臺單機應用為1個JVM 行程，和監控agent 、日志 agent 等agent行程一同部署在容器、或者KVM、物理機等OS 環境中
-
平臺應用本身核心
-
low code proxy ,提供平臺api介面，接受平臺的指令，如：發布指令，接受到發布指令后去相關的存盤服務拉取元配置資訊和函式腳本、觸發器、連接器配置、組態檔等低代碼應用的源檔案
-
執行引擎，負責對低代碼應用連接器的加載、函式加載、觸發器配加載，加載完成后對外提供服務，等待各種觸發器的流量觸發、
-
低代碼應用核心構件
-
觸發器為應用的流量入口：如介面、MQ消費者，定時任務回呼等等，平臺支持自定義觸發器開發
-
函式為業務邏輯的編排，可以是特定語言的函式腳本，可以是bpmn組合的流程檔案，
-
連接器負責和下游RPC介面，存盤資料源、中間件平臺的訊息通信
-
多環境配置資訊提供不同環境的引數配置
-
以上幾個核心構件的有機組合共同在應用層基礎能力至之上提供了
-
低代碼應用作為一個運行單元被發布到平臺應用中
三、低代碼平臺詳細設計
由于是小組共創設計，我在詳細設計中主要負責了連接器與觸發器的設計部分，其他如函式、配置部分的設計與此詳細設計這里不再贅述，大概思路如下
函式：支持各種語言的運算式函式、支持BPMN可視化流程編排
多環境配置：需要支持測驗、生產、預發等環境組態檔
日志： 支持平臺開發者自定義日志是否列印，列印格式，是否有掩碼等
1、連接器的設計
連接器定義
-
在一個低代碼應用中連接器主要負責和其他業務方提供的RPC服務、中間件、存盤等物體進行通信的組件
-
可以在腳本函式中直接呼叫連接器，也可以在流程函式中直接呼叫連接器
-
連接器支持其他未知新協議的制定
連接器的0代碼開發與部署流程
2、自定義連接器
1、為了適應內外部不同的連接器訴求，平臺提供自定義觸發器的能力
2、預留使用連接器使用的配置資訊，為引入的通信中間件預留未來使用該觸發器的使用方需要0代碼配置的配置資訊，如資料庫的地址，賬號密碼等資訊
3、連接器需要實作平臺提供的API,這樣以便函式或者觸發器可以直接呼叫該連接器
4、除錯無誤后保存觸發器，提交平臺審核，審核通過后平臺可上架該觸發器
3、自定義觸發器
1、為了適應內外部不同的觸發器訴求，平臺提供自定義觸發器的能力
2、預留使用觸發器使用的配置資訊，為引入的通信中間件預留未來使用該觸發器的使用方需要0代碼配置的配置資訊，如JSF的介面地址，別名等
3、使用純代碼寫出該觸發器的源代碼，并預留呼叫低代碼函式的入口，以便將來使用該觸發器的使用者可以0代碼配置觸發器所呼叫的函式
4、除錯無誤后保存觸發器，提交平臺審核，審核通過后平臺可上架該觸發器
四、低代碼應用源檔案
a、元資訊，0代碼，包含低代碼應用的0代碼開發部分的觸發器元資訊、連接器元資訊
1、觸發器配置資訊：
? 通信中間件所需要的各個引數，介面名等等
? 呼叫函式的函式名稱
? 是否列印日志，日志是否脫敏
2、連接器配置資訊
? 通信中間件所需要的各個引數，密碼，用戶名等等
? 是否列印日志，日志是否脫敏
b、源檔案，0代碼，包含：流程檔案、腳本檔案
? 可視化流程編排產生的源檔案，如bpmn流程檔案
? 腳本編碼產生的腳本檔案，如自定義java函式
c、多環境配置，0代碼，包含各個環境的組態檔
? 開發環境、生成環境的各個配置資訊等，配置資訊可以在觸發器、函式、連接器中使用引入使用
d、日志組件配置
? 日志列印輸出格式
? 日志輸出路徑
? 全域脫敏欄位，脫敏正則
e、監控組件配置
? 監控埋點列印路徑
? 監控埋點列印格式
d、低代碼平臺應用底座：
執行引擎、LC Proxy、中間件依賴的jar、應用框架springboot的jar等，這部分跟隨不同的構建部署方式為可選項
五、低代碼應用的構建部署方式
1、源檔案熱部署
這種方式應對于低代碼平臺的租戶使用低代碼平臺所有集群的共享資源，選取一部分可用資源以后在控制面板進行選擇發布，可以使用指定ip的模式應對相關權限問題，也可以不指定ip使用平臺自定義分配，
? 受平臺資源調度管控，參考上周控制面板的功能
? 日志與監控埋點由 LC Proxy 采集到平臺提供的日志平臺和監控平臺
2、構建jar包、war包
這種方式應對于有自己的主機用戶，拿到成品后即可部署無狀態應用，打的包中不包含LC Proxy部分，執行引擎在應用啟動的時候自動加載包中特定路徑的流程檔案、腳本檔案等，
? 日志列印到特定目錄，供用戶自己的日志采集器采集
? 埋點檔案按照特定格式列印到特定目錄，供自己的日志采集器采集
3、構建鏡像
這種方式應對于有自己的容器用戶，拿到成品后即可部署無狀態應用，打的包中不包含LC Proxy部分，執行引擎在應用啟動的時候自動加載包中特定路徑的流程檔案、腳本檔案等，
? 日志列印到特定目錄，供用戶自己的日志采集器采集
? 埋點檔案按照特定格式列印到特定目錄，供自己的日志采集器采集
4、低代碼平臺和部署平臺的關系
? 內部
? 內部部署的低代碼平臺為了方便各業務方靈活使用，平臺提供兩種能力
? 1、共享資源模式：平臺租戶共享平臺資源池，適用于消耗資源不大并發量不高的應用， 使用低代碼平臺本身提供的日志平臺、監控平臺結合做到各個維度的立體監控
? 2、自定義資源模式：平臺對接體系內的JDOS平臺，可以將低代碼應用與JDOS應用進行關聯，使用在JDOS平臺申請的應用進行部署，這種方式提供單獨的鏡像檔案進行部署，可結合體系內的日志中間件、監控平臺， 與低代碼平臺本身提供的日志平臺、監控平臺結合做到各個維度的立體監控
? 外部
? 外部需求為成品包的時候，只需要構建出 如上所述的 jar、war供其下載即可
? 外部需求為低代碼平臺私有化部署的時候，需要將方案設計中的幾大應用為用戶做私有化部署
六、一些問題的思考與識訓
1、擴展性不僅僅是在某一項功能上的擴展，站在全域視角看在架構設計中所有產品功能理論上都要盡可能考慮模塊化，可插拔，進而搭積木成平臺化，真正做到全場景和全鏈路可擴展
2、團隊小伙伴對HTTP 觸發器的設計輸出，讓我聯想到 JSF注冊中心等通用類注冊中心都要解決的高可用問題，舉一反三，同場景的同類解決方案的核心問題是相通的
3、對于未來業務發展生命周期沒那么長，資料要求沒有強隔離訴求的場景，能否基于資料模型做一層資料層的0代碼開發？
4、流程驅動的低代碼可以和資料驅動的低代碼很好地結合起來
5、低代碼平臺產出物的多樣化，為之后交付專案的產出物打開了思路，很多時候要站在客戶角度考慮，客戶的應用場景是什么，需要什么，那么我們就提供什么，張宇軒單元可跑，也可圈定某一部分功能集合，打包輸出
低代碼平臺適合的場景的一些思考
1、可以應用在上層營銷系統的開發中
2、可以用在流程較為通用的場景如：訊息轉化、資料統計、介面轉發
3、可以應用在已有成熟的業務線進行外圍的業務開發，如支付、結算等穩定系統上層要做一些簡單業務編排的場景用
4、 面對同樣一個業務需求是使用低代碼開發還是使用純代碼開發，沒有明確的可量化的分水嶺，但是建議嘗試，從中獲到提效之后下一次面臨需求的時候就會有較為明確的答案
案例1：我們曾在一個上層營銷活動系統重嘗試基于運算式引擎做了一個半配置化的活動配置系統（那個時候還沒聽過低代碼這個詞），現在想來算是比較原始的支持低代碼系統，上新一個活動原本需要3個人日的開發量，基于對以往流程的復用，使用腳本語言，使用運算式進行編排和發布，0.5人日就搞定了，且系統無需重新發布，不得不說在合適的場景，低代碼還是非常有空的，
案例2：大促的時的業務資料大屏的制作相信很多人都經歷過，我們最近兩次大促采取的方案都是使用星鏈對已有的資料介面和新的資料指標進行簡單編排加工，提供JSF服務，再結合我們內部的網關系統將介面協議轉化為HTTP, 直接在展示平臺（如莫奈大屏）上直接使用，大促過后資源也可隨之釋放，非常方便與高效，同時也降低了研發成本
七、結語
參加訓練營后還是有一些感觸想分享給大家
1、感謝馬老師的指導和各位評委老師的指點，感恩大家的信任，感謝同組的大佬們，從大家身上學習到不同的思路，每個人來此不同團隊，通過和大家的討論，發掘了很多新的看待產品與架構的視角
2、流程驅動的低代碼平臺可以和資料驅動的低代碼以及部分0代碼開發組件可以很好地有機整合成統一的低代碼平臺，進一步提升研發效率
3、整體感覺訓練營節奏緊湊，干貨滿滿，架構設計方面對平臺擴展性的思考充分得到訓練
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/550716.html
標籤：架構設計
上一篇：【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作
下一篇：返回列表