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