結合京東業務研發實際情況，針對後端研發人員，設計一個微服務低代碼平臺，助力更高效低交付業務需求。現已結業，將我在本次項目中沉澱設計出的設計文檔整理成文，期待與大家有進一步的碰撞溝通 ...
作者：京東科技 常薑洲
一、背景
近期參加公司組織的極客中餐廳訓練營，我們所在的小組接到的課題是微服務的低代碼平臺架構設計。目標是：結合京東業務研發實際情況，針對後端研發人員，設計一個微服務低代碼平臺，助力更高效低交付業務需求。現已結業，將我在本次項目中沉澱設計出的設計文檔整理成文，期待與大家有進一步的碰撞溝通
二、低代碼平臺整體技術架構設計
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、整體感覺訓練營節奏緊湊，乾貨滿滿，架構設計方面對平臺擴展性的思考充分得到訓練
