攜程後臺低程式碼平臺的探究與實踐

　　 概述

　　PGClowcode平臺是攜程市場內容PGC團隊搭建的主要用於後臺頁面開發的低程式碼平臺，第一版於23年3月上線，截至10月平臺已經擁有100+使用者，在平臺上開發了130+個應用和180+個頁面。本文將主要介紹團隊採用低程式碼平臺的背景、方案調研、落地過程中遇到的問題以及解決方案，同時也大致介紹了該低程式碼平臺提供的能力。

　　 一、研究背景

　　1.1 為什麼需要低程式碼平臺

　　軟體產品通常由客戶端（App、小程式、網頁）和運營後臺組成，其整個生命週期需要不斷地更新迭代，而在實際的迭代開發中經常會出現以下問題：

　　後臺需求優先順序低，排期經常被延期，通常使用配置中心等簡易資料操作平臺替代，不僅對運營人員不友好，而且產生了極大的生產風險

　　迭代需求涉及的前後端開發工作量不均衡，經常面臨後臺需求較多，但前端資源不足，服務端資源即便有空閒也沒法幫忙支援後臺的需求

　　不同業務間後臺技術和元件大同小異，各業務反覆造輪子，浪費時間和資源

　　開發人員開發工具類站點時，頁面部分的工作需要付出較大的代價

　　針對這些問題我們也嘗試了很多的解決方案，如要求開發人員全棧、剝離公共元件等，但結果都不太理想，經過充分的瞭解和分析，搭建低程式碼或零程式碼平臺能在很大程度上解決這些問題。

　　1.2 需要什麼樣的低程式碼平臺

　　低程式碼平臺分為很多種，我們究竟需要哪種呢？經過將以上問題拆分細化和充分調研後，我們的低程式碼平臺應該滿足以下要求：

　　頁面搭建方面：

　　介面友好、視覺化，可以讓研發和相關人員能透過拖拽的簡單方式快速搭建UI

　　頁面邏輯僅需寫少量簡單的程式碼或無需程式碼

　　支援滿足日常需求的元件庫

　　部署運維方面：

　　具有開發、部署、運維等完整的持續交付功能，最好能一鍵或自動化完成

　　安全合規方面：

　　支援許可權管理機制，保證系統安全

　　具備完善的釋出審批機制，能嚴格保證開發質量和生產安全

　　相容性方面：

　　能嵌入已有後臺頁面，已有後臺儘量少改動的嵌入其開發的頁面

　　可擴充套件性方面：

　　支援使用者自助化元件開發，並且能在平臺上推廣

　　 二、現狀分析

　　2.1 行業現狀

　　目前國內外低程式碼或零程式碼產品不下百種，既有商業平臺，也有開源專案，它們在企業內部用於各種運營後臺、資料皮膚、辦公系統等內部系統的開發，在B端提供商品管理、廣告投放、商鋪搭建等企業服務，在C端廣泛用於活動頁面、促銷頻道、廣告頻道等型別產品的搭建，不僅為企業節省了大量的開發成本、產生巨大的商業價值，同時也為使用者提供了豐富多彩的軟體產品。

　　雖然低程式碼種類繁多，但是每類低程式碼專案往往具有特定的業務屬性，在不同的行業，不同的公司可能需要定製不同的元件，不同的流程，因此市場上很少有能適用於所有場景的平臺，也很少有企業願意去做通用平臺。下面分析了目前比較流行的產品：

　　2.2 產品分析

　　阿里低程式碼引擎

　　LowCodeEngine（阿里低程式碼引擎）是國內最知名的低程式碼類產品之一，其完整的實現了《低程式碼引擎搭建協議規範》和《低程式碼引擎物料協議規範》，它透過完整的協議棧約定了各種物料的開發、使用、擴充套件、流通，並且提煉了企業級低程式碼平臺的特性，遵循面向擴充套件設計的理念，奉行最小核心、最強生態的設計原則而設計的核心引擎。

　　目前其生態已經相當完備，並且提供了非常詳細的文件和使用案例，也有大量的demo開源，其使用起來相對比較便捷。但它並沒有提供完整的平臺程式碼，使用者需要在其核心的基礎上搭建面向使用者的平臺和服務系統，具有相當的開發成本。

　　騰訊低程式碼平臺

　　騰訊的低程式碼產品包括搭建生成移動端H5頁面的tmagic-editor開源專案和搭建管理端頁面的無極低程式碼商業平臺，其中tmagic-editor提供了完整的平臺程式碼，使用者可以在開源社群將整個專案pull到本地部署使用，它具備自定義元件、外掛、編輯器等擴充套件能力，內建了豐富的元件，提供了友好的視覺化介面，透過拖拽+配置的方式開發頁面。

　　但其限定於移動端H5頁面的搭建，無法適用pc端頁面開發的需求，大大限制了使用範圍。無極低程式碼平臺是商業化的面向企業付費使用的產品，具備管理端強大的開發能力，甚至結合了AI能力，能供面向企業豐富的解決方案，但它目前並沒有開源。

　　開源低程式碼平臺

　　在github上搜尋lowcode關鍵詞可以看到非常多的專案，他們所使用的技術、專案的形態、star數量、活躍的層度、使用場景各不相同，有些提供了完整的視覺化介面，有些則需要透過配置檔案或呼叫介面的方式生成頁面或專案，總之需要花費較多的時間對比分析才能找到符合自身需求的專案。

　　總結

　　綜上所述，我們最終決定選擇一款開源程度比較高的專案（appsmith）作為藍本，然後經過改造、開發搭建了PGClowcode平臺。

　　 三、平臺功能介紹

　　PGClowcode平臺功能主要包含頁面搭建、元件開發平臺兩大部分。　　

　　頁面搭建包含開發、預覽、測試、釋出、回滾、備份、恢復等常用功能。在這些功能的基礎上，增加了"視覺化拖拽"、"多使用者協同開發"、"匯入匯出"、"多資料來源"、"通知"等功能，形成了一個相當完善的開發體系。搭建的產物可以透過將平臺上的應用或頁面嵌入到已有的後臺，或者反過來將已有的後臺頁面嵌入到平臺，實現組合使用。

　　元件開發平臺是對頁面搭建能力的擴充套件，支援透過CLI構建本地專案，自定義開發新的元件以滿足更復雜的業務需求。（此功能正在開發中，將在不久之後開放）

　　由於篇幅有限，下面將介紹幾個主要功能。

　　3.1 使用者和許可權管理

　　平臺擁有自己的使用者管理體系，為了與攜程的賬號體系打通，接入了OIDC域賬號認證，使用者無需額外註冊賬號，只需要使用攜程域賬號登入即可。

　　使用者的許可權做了充分的拆分，平臺的所有功能對每個使用者開放，只是對於使用者私有的資料做了許可權控制，許可權定義的最小單位是工作空間（workspace），使用者可以擁有多個workspace，每個workspace 定義了管理員（admin）、開發者（developer）、使用者（viewer）、測試者（tester）、稽核者（reviewer）五個許可權組。其中每個許可權組對workspace下面的資源擁有不同的管理許可權，這些資源包括資料來源、應用、頁面等，admin可以對workspace內的使用者分配不同的許可權組，從而對應用的開發、釋出等流程上進行管理。具體各許可權組的許可權分配參考下表：　　

　　3.2 視覺化應用開發

　　傳統後臺開發與採用低程式碼平臺進行後臺開發的流程區別如下圖所示：　　

　　傳統後臺開發過程中需要開發者自身搭建開發環境，引入前端元件庫如Ant Design，相同的功能需要自己提取元件，開發效率低效。

　　PGClowcode低程式碼平臺提供了視覺化拖拽的皮膚，支援頁面複雜佈局。元件欄支援40+種通用元件，並可以組合使用。

　　在頁面繪製方面，透過將其拖入畫板，調整位置佈局，簡單幾步完成介面的設計，做到了所見即所得。相同功能可以在畫布中複製貼上，應用本身也支援匯入匯出功能，方便專案複製。開發變得靈活高效，避免了一些基本構建所產生的bug，達到了降本增效的效果。

　　在元件的屬性值設定方面，可以透過視覺化的輸入或者透過自定義JS程式碼的方式進行復雜的邏輯繫結，並且也支援編寫js程式碼完成複雜的互動邏輯。平臺內建了多種js庫，可以將資料繫結到元件上，在開發狀態下能立即看到資料渲染的效果，使得在預覽狀態下可以邊開發邊自測。　　

　　3.3 流程管理

　　應用從開發態->測試態->釋出態的流轉十分便利。平臺設計了不同角色，將測試、稽核的流程精簡化，各角色登入後可以看到應用的不同狀態，應用在開發和審批後自動流轉至下一狀態，只需要簡單幾個流程即可完成。

　　1）開發人員（開發態）：根據需求搭建、開發頁面，然後釋出到測試環境；　　

　　2）測試人員（測試態）：在頁面測試，保證其能滿足需求，且不存在質量問題後點選Publish提交發布申請；　　

　　3）稽核人員（釋出態）：在“待我稽核”列表中找到稽核申請。審批透過，應用自動完成釋出。　　

　　3.4 備份與還原

　　開發平臺支援了應用資料的備份和歷史版本資料的還原。在開發狀態下平臺採用了自動儲存的設計方案，由於多人同時開發時容易出現相互覆蓋或操作衝突的情況，為了減少這種問題導致的返工成本，我們設計了備份和還原的功能。

　　和正常普通的應用一樣，使用者可以將每個穩定版本的開發態備份到系統，在之後的操作中需要回到某個穩定版本則直接選中目標版本還原即可。

　　下圖展示了備份還原的操作介面。　　

　　 四、架構和技術

　　PGClowcode平臺採用了前後端分離架構。前端使用了react技術棧，並且整合了攜程的多種公共框架和元件，依託於攜程的CI/CD平臺，實現了持續開發和交付的能力。服務端採用spring webflux框架，整合了cat、clog（攜程日誌系統）、mongo、credis（攜程redis client）、qconfig(攜程配置中心中介軟體，下文簡稱QC)、qmq（攜程MQ中介軟體）等技術框架，完全融入了攜程的服務技術棧，可以透過gitlab自動化編譯打包，在captain（攜程釋出平臺）上釋出。

　　4.1 架構　　

　　如上圖所示，PGClowcode平臺的整體架構分為應用層、基礎設施、服務層、資料層。

　　應用層是終端的兩套平臺系統，主要包括面向使用者的低程式碼開發平臺和麵向開發人員的元件開發平臺。

　　基礎設施主要包含前端的基礎框架、資料流控制以及抽象出來的前端可視的元件、頁面和編輯器等概念。基礎框架主要依託於React App和canvas技術透過axios庫和服務端進行資料互動，透過Redux及相關外掛來控制整個平臺的資料流，最終展示成使用者可見的元件、頁面、編輯器等UI模組。

　　服務層主要由web層、service層和資料訪問層組成，主要提供許可權驗證、流程管控、外掛管理、訊息通知、資料訪問等服務。服務採用了微服務架構的設計，按照不同的領域和功能拆分成領域服務、通知服務和外掛服務。

　　領域服務又根據不同的model細分為不同的模組，各自完成獨立單一的功能；通知服務主要用於email、trippal、sms等訊息通知；外掛服務主要提供外掛的載入、初始化、呼叫、解除安裝等相關功能的服務。資料訪問在核心服務的下層，實現了針對多種資料來源的訪問和資料處理、校驗的功能。

　　資料層主要用於儲存後設資料、應用資料、外掛資料等，應用的備份資料儲存於QC，並且透過QC實現跨環境釋出。

　　下面兩節主要對平臺“元件的視覺化拖拽實現”和“應用的開發-部署實現”兩項比較核心的技術詳細闡述。

　　4.2 元件的視覺化拖拽實現

　　視覺化拖拽元件是低程式碼平臺的基本功能，在本平臺中，使用者可以在左側元件庫裡選擇任意元件拖拽到中間的編輯區域，並更改其大小。

　　在實現上述的拖拽功能時，我們會面臨幾個問題：

　　1）拖拽元件的過程中，元件的位置會實時變更，大量巢狀在一起的dom元素同時變更位置，會頻繁觸發瀏覽器的重繪製，導致效能的消耗。

　　2）人為的拖拽排布，很難保證元件之間的對齊和排版，頁面最終效果難以達到程式碼實現頁面的規整程度。

　　對於上述的問題1，平臺的解決方案是依託canvas技術，在元件變更位置或者大小時，隱藏實際渲染在頁面上的元件，並在編輯區域最上層渲染一層canvas，在原元件位置畫出一個同等大小的色塊來代替原元件，並用以示意使用者，利用canvas畫布的特性來處理元件位置及大小的變更，在使用者結束拖拽動作後，根據色塊在canvas中的最終位置及大小，重繪製一次元件，並隱藏canvas，展示出元件的最終效果。

　　在上述描述中可以看到，利用canvas可以極大程度的削減瀏覽器重繪製的次數，達到減少效能消耗的目的；選擇色塊來作為繪製物件而非原元件，既降低了技術實現的難度，又進一步降低了canvas繪製圖形的效能消耗。

　　對於問題2，平臺的解決方案是陣點系統，當使用者拖拽元件到編輯區域觸發渲染canvas的同時，頁面上會繪製一層陣點並均勻的平鋪在canvas上，當使用者在canvas上拖拽色塊變更其位置或者大小時，在色塊的周邊會繪製出同等大小的虛線邊框，邊框會根據色塊當前的位置及大小動態的定位到合適的臨近陣點上。陣點系統中，橫向及縱向兩個相鄰陣點的間隔即為元件長寬的最小單位，元件的四角位置只能定位在陣點上。由此可見，在拖拽過程中，元件的位置及大小都在一定的限制之內，這可以保證最終繪製出來的頁面的規整性。

　　以下為一次完整的元件拖拽流程示意圖：　　

　　1）頁面無拖拽操作，主編輯區域僅展示元件的靜態狀態，此時為展示態。

　　2）當使用者開始拖拽元件以期改變其位置及大小的動態狀態，為操作態。操作態又可以細化為拖拽開始、拖拽中、拖拽結束，三個狀態。

　　當使用者開始拖拽元件時，頁面會從展示態變更為操作態。拖拽開始時，編輯區域內繪製canvas並鋪設陣點，原元件變為不可見，在canvas內原元件的相同位置繪製同等大小的色塊以及虛線邊框；在拖拽過程中，色塊會隨著滑鼠移動變更位置或者大小，其外部虛線邊框也會隨色塊移動或變更大小，並實時定位在色塊當前位置的最相鄰陣點上；拖拽結束時，根據當前邊框的最終大小及位置，重新繪製原元件，並隱藏canvas、陣點系統、色塊以及虛線邊框；頁面由操作態變更為展示態，展示出元件的最新狀態。

　　4.3 應用的開發-部署實現

　　應用的開發和部署的技術實現主要分為應用的資料結構、資料流轉和多種角色協同三個部分，最後針對應用的資料備份與還原也做了簡單的介紹。

　　4.3.1 資料結構

　　當前大多數主流的低程式碼平臺最終的產物可能是程式碼，但PGClowcode平臺最終的產物是資料，包括應用資訊、頁面資訊、元件、元件之間的關係、action、資料來源等都是以資料的形式儲存在db上，由於頁面的佈局、元件巢狀、函式的繫結等各種實體間關係非常複雜，使用傳統的關係型資料庫無法保證資料結構穩定，因此採用了mongodb作為資料庫。應用相關的collection主要包括了plugin、workspace、datasource、application、page、action、actioncollection，它們透過下圖的關係構成了整個應用體系。　　

　　plugin主要用於定義平臺支援外掛的後設資料資訊，包括型別、外掛包路徑、引數、狀態等屬性。

　　workspace是應用開發的工作空間，它定義了空間內的使用者組成、使用者許可權、資料來源以及支援的外掛集合。

　　application定義了應用的名稱、主題、icon、狀態等基本資訊，另外為了查詢便捷，也冗餘了部分頁面的資訊。

　　page定義了頁面的名稱、佈局、元件、元件的關係、元件與函式的繫結關係等。

　　datasource定義了外部資料訪問的基礎資訊，如restapi、es、mongodb等外部資料訪問的必要屬性，為了避免重複配置，它的作用範圍是workspace級別。

　　action定義了外部資料訪問的具體配置資料，它必須依託於datasource，如restapi介面呼叫，datasource配置了服務的域名和是否需要實時鑑權，而action則配置路徑、引數、執行方式，與datasouce不同的是它的作用範圍是頁面。

　　actionCollection是action或js函式的集合。

　　4.3.2 資料流轉

　　應用資料主要是在不同的儲存介質和不同的環境間流轉，平臺目前設計了三套環境FAT、UAT、PRO，平臺透過QC的跨環境機制實現資料流轉。　

　　如上圖所示，開發者在FAT上開發應用，應用資料以草稿態儲存於DB，開發完成後將草稿態資料匯出到QC的FAT環境，服務監聽到QC的資料變更將草稿態copy到釋出態，測試則可以在測試頁面上看到開發提交的應用，測試完成後提交UAT釋出申請，服務將釋出態的資料匯出到QC的UAT環境，此時稽核者將收到待稽核通知。

　　進入平臺將待發布申請稽核透過後，UAT環境的服務監聽到QC資料變更將資料匯入到DB，並且將應用資料狀態置為釋出態，然後可以在UAT的測試頁面看到釋出態的應用，當UAT測試完成後申請釋出到生產（PRO），UAT服務將釋出態應用資料匯出到QC PRO環境，當稽核者透過申請後則QC PRO的應用檔案被髮布，PRO服務監聽到資料變更就將應用資料匯入到DB，並置為釋出態，此時應用的開發-部署流程結束，使用者可以在生產環境的使用者平臺正常使用了。

　　4.3.3 多角色協同

　　對於應用的開發、測試、交付平臺設計了多個角色，在整個需求開發的過程中每個角色能各司其責，保證應用能持續、穩定、高效迭代交付，如下圖所示。　　

　　平臺透過定義多個許可權組來區分每個角色，當workspace被建立時這些許可權組就會被建立出來，每個許可權組定義了各自的許可權，在每個受許可權管理的資源中都有policies欄位，它儲存了能被操作的型別和許可權組id的集合，當使用者查詢和操作時都會經過許可權校驗。　

　　有了角色的定義，應用開發人員的協同就變得簡單多了，如當應用釋出測試時可以自動通知測試人員介入，提交發布生產申請時可以自動通知稽核人員參與稽核。

　　4.3.4 備份與還原

　　為了方便開發過程中多人同時開發，平臺設計了備份還原功能，當使用者點選備份時，服務將當前草稿態資料匯出到QC，點選還原則將QC的資料匯入到服務，覆蓋當前DB中草稿態資料，得益於QC的版本管理功能，每次備份的資料都將儲存起來，因此使用者可以還原到歷史的任意版本。　　

　　如上圖所示，T1時刻新增一個備份v1，T2時刻QC中存在v1版本的備份資料，如果T2時刻再增加一個備份v2，到T3時刻QC存在v1和v2兩個版本，如果在T3時刻將DB中的版本還原成v1，則DB中的資料會被還原成v1，與此同時會上傳一個v3版本到QC，實際上v3和v1資料是一樣的，相當於將當前資料的基準切換到了最新版本，之後的操作都是在這個版本的基礎上做的，如果再需要還原到這個基準就可以快速完成。

　　 五、規劃與展望

　　目前PGC低程式碼平臺已經具備了非常完整的功能，基本上完成了預期的目標，也產生較大的價值，但我們對於它的期望絕非只限於此，並且組建了穩定的支援團隊，制定了明確規劃，在之後的迭代開發中會不斷地完善已有的功能和流程，而且會根據實際的需求和業內平臺的調研繼續增加更強大、便捷的功能。

　　5.1 搭建元件擴充套件平臺

　　平臺原有的元件是比較基本的元件庫，未來會難以滿足日漸複雜的業務需求，因此自定義元件的需求就會逐漸凸顯出來，本平臺基於Appsmith框架是支援自定義元件的，但是原有的自定義功能有如下幾個問題：

　　1）原有的自定義元件功能，需要依託於完整的平臺專案，在其widget資料夾下開發新元件，專案程式碼體量大，啟動慢，且以開發元件為目的頻繁更改提交平臺專案並不利於平臺專案的釋出及管理。

　　2）原有的自定義元件功能並不適合多部門自定義元件的場景，沒有相關的許可權管理系統，所有自定義元件都會展示在頁面上，隨著時間的推移會造成元件庫的臃腫以及增加編輯頁面時查詢使用元件的費力度。

　　為了解決以上問題，我們會從主專案中抽離出相關程式碼，搭建一套獨立的元件開發專案，以達到和平臺主專案分離、程式碼純淨、專案快速啟動的目的。同時也會構建一套自定義元件的許可權管理系統以便更好的管理各部門開發的自定義元件。

　　5.2 建立模板庫

　　Ctrl+C和Ctrl+V可能是開發人員使用頻率最高的按鍵組合，致使一些鍵盤不是“面目全非”就是“半身不遂”，試想一下，如果我們拿出來一鍵生成部署頁面的功能，是否能讓“久經磨難”的鍵盤依然“歷久彌新”呢？沒錯，這是我們接下來的目標。

　　低程式碼平臺的模板是指根據長期積累的經驗，總結一些具有共性的通用方案，並且提煉成所有使用者都能直接使用的頁面或應用，收錄到模板庫中，當平臺上的其他使用者需要使用類似應用或頁面時，只需要找到合適的模板，一鍵即可生成頁面或應用，甚至能拿來即可用，無需做任何修改。後期可以允許建立團隊自己的模板庫，各成員可以搭建自己的模板專門供團隊使用。