作者簡介

ck，攜程后端開發(fā)專家，關(guān)注技術(shù)架構(gòu)、高并發(fā)、性能調(diào)優(yōu)等領(lǐng)域；

Geralt，攜程前端開發(fā)專家，關(guān)注前端框架及性能優(yōu)化；

Kaoru，攜程資深前端開發(fā)工程師，關(guān)注前端性能及開發(fā)工具；

概述

PGClowcode平臺是攜程市場內(nèi)容PGC團隊搭建的主要用于后臺頁面開發(fā)的低代碼平臺，第一版于23年3月上線，截至10月平臺已經(jīng)擁有100+用戶，在平臺上開發(fā)了130+個應(yīng)用和180+個頁面。本文將主要介紹團隊采用低代碼平臺的背景、方案調(diào)研、落地過程中遇到的問題以及解決方案，同時也大致介紹了該低代碼平臺提供的能力。

一、研究背景

1.1 為什么需要低代碼平臺

軟件產(chǎn)品通常由客戶端（App、小程序、網(wǎng)頁）和運營后臺組成，其整個生命周期需要不斷地更新迭代，而在實際的迭代開發(fā)中經(jīng)常會出現(xiàn)以下問題：

• 后臺需求優(yōu)先級低，排期經(jīng)常被延期，通常使用配置中心等簡易數(shù)據(jù)操作平臺替代，不僅對運營人員不友好，而且產(chǎn)生了極大的生產(chǎn)風(fēng)險
• 迭代需求涉及的前后端開發(fā)工作量不均衡，經(jīng)常面臨后臺需求較多，但前端資源不足，服務(wù)端資源即便有空閑也沒法幫忙支持后臺的需求
• 不同業(yè)務(wù)間后臺技術(shù)和組件大同小異，各業(yè)務(wù)反復(fù)造輪子，浪費時間和資源
• 開發(fā)人員開發(fā)工具類站點時，頁面部分的工作需要付出較大的代價
•  

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

1.2 需要什么樣的低代碼平臺

低代碼平臺分為很多種，我們究竟需要哪種呢？經(jīng)過將以上問題拆分細化和充分調(diào)研后，我們的低代碼平臺應(yīng)該滿足以下要求：

頁面搭建方面：

• 界面友好、可視化，可以讓研發(fā)和相關(guān)人員能通過拖拽的簡單方式快速搭建UI
• 頁面邏輯僅需寫少量簡單的代碼或無需代碼
• 支持滿足日常需求的組件庫
•  

部署運維方面：

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

安全合規(guī)方面：

• 支持權(quán)限管理機制，保證系統(tǒng)安全
• 具備完善的發(fā)布審批機制，能嚴格保證開發(fā)質(zhì)量和生產(chǎn)安全
•  

兼容性方面：

能嵌入已有后臺頁面，已有后臺盡量少改動的嵌入其開發(fā)的頁面

可擴展性方面：

支持用戶自助化組件開發(fā)，并且能在平臺上推廣

二、現(xiàn)狀分析

2.1 行業(yè)現(xiàn)狀

目前國內(nèi)外低代碼或零代碼產(chǎn)品不下百種，既有商業(yè)平臺，也有開源項目，它們在企業(yè)內(nèi)部用于各種運營后臺、數(shù)據(jù)面板、辦公系統(tǒng)等內(nèi)部系統(tǒng)的開發(fā)，在B端提供商品管理、廣告投放、商鋪搭建等企業(yè)服務(wù)，在C端廣泛用于活動頁面、促銷頻道、廣告頻道等類型產(chǎn)品的搭建，不僅為企業(yè)節(jié)省了大量的開發(fā)成本、產(chǎn)生巨大的商業(yè)價值，同時也為用戶提供了豐富多彩的軟件產(chǎn)品。

雖然低代碼種類繁多，但是每類低代碼項目往往具有特定的業(yè)務(wù)屬性，在不同的行業(yè)，不同的公司可能需要定制不同的組件，不同的流程，因此市場上很少有能適用于所有場景的平臺，也很少有企業(yè)愿意去做通用平臺。下面分析了目前比較流行的產(chǎn)品：

2.2 產(chǎn)品分析

阿里低代碼引擎

LowCodeEngine（阿里低代碼引擎）是國內(nèi)最知名的低代碼類產(chǎn)品之一，其完整的實現(xiàn)了《低代碼引擎搭建協(xié)議規(guī)范》和《低代碼引擎物料協(xié)議規(guī)范》，它通過完整的協(xié)議棧約定了各種物料的開發(fā)、使用、擴展、流通，并且提煉了企業(yè)級低代碼平臺的特性，遵循面向擴展設(shè)計的理念，奉行最小內(nèi)核、最強生態(tài)的設(shè)計原則而設(shè)計的內(nèi)核引擎。

目前其生態(tài)已經(jīng)相當(dāng)完備，并且提供了非常詳細的文檔和使用案例，也有大量的demo開源，其使用起來相對比較便捷。但它并沒有提供完整的平臺代碼，使用者需要在其內(nèi)核的基礎(chǔ)上搭建面向用戶的平臺和服務(wù)系統(tǒng)，具有相當(dāng)?shù)拈_發(fā)成本。

騰訊低代碼平臺

騰訊的低代碼產(chǎn)品包括搭建生成移動端H5頁面的tmagic-editor開源項目和搭建管理端頁面的無極低代碼商業(yè)平臺，其中tmagic-editor提供了完整的平臺代碼，使用者可以在開源社區(qū)將整個項目pull到本地部署使用，它具備自定義組件、插件、編輯器等擴展能力，內(nèi)置了豐富的組件，提供了友好的可視化界面，通過拖拽+配置的方式開發(fā)頁面。

但其限定于移動端H5頁面的搭建，無法適用pc端頁面開發(fā)的需求，大大限制了使用范圍。無極低代碼平臺是商業(yè)化的面向企業(yè)付費使用的產(chǎn)品，具備管理端強大的開發(fā)能力，甚至結(jié)合了AI能力，能供面向企業(yè)豐富的解決方案，但它目前并沒有開源。

開源低代碼平臺

在github上搜索lowcode關(guān)鍵詞可以看到非常多的項目，他們所使用的技術(shù)、項目的形態(tài)、star數(shù)量、活躍的層度、使用場景各不相同，有些提供了完整的可視化界面，有些則需要通過配置文件或調(diào)用接口的方式生成頁面或項目，總之需要花費較多的時間對比分析才能找到符合自身需求的項目。

總結(jié)

綜上所述，我們最終決定選擇一款開源程度比較高的項目（appsmith）作為藍本，然后經(jīng)過改造、開發(fā)搭建了PGClowcode平臺。 

三、平臺功能介紹

PGClowcode平臺功能主要包含頁面搭建、組件開發(fā)平臺兩大部分。

頁面搭建包含開發(fā)、預(yù)覽、測試、發(fā)布、回滾、備份、恢復(fù)等常用功能。在這些功能的基礎(chǔ)上，增加了"可視化拖拽"、"多用戶協(xié)同開發(fā)"、"導(dǎo)入導(dǎo)出"、"多數(shù)據(jù)源"、"通知"等功能，形成了一個相當(dāng)完善的開發(fā)體系。搭建的產(chǎn)物可以通過將平臺上的應(yīng)用或頁面嵌入到已有的后臺，或者反過來將已有的后臺頁面嵌入到平臺，實現(xiàn)組合使用。

組件開發(fā)平臺是對頁面搭建能力的擴展，支持通過CLI構(gòu)建本地項目，自定義開發(fā)新的組件以滿足更復(fù)雜的業(yè)務(wù)需求。（此功能正在開發(fā)中，將在不久之后開放）

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

3.1 用戶和權(quán)限管理

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

用戶的權(quán)限做了充分的拆分，平臺的所有功能對每個用戶開放，只是對于用戶私有的數(shù)據(jù)做了權(quán)限控制，權(quán)限定義的最小單位是工作空間（workspace），用戶可以擁有多個workspace，每個workspace 定義了管理員（admin）、開發(fā)者（developer）、使用者（viewer）、測試者（tester）、審核者（reviewer）五個權(quán)限組。其中每個權(quán)限組對workspace下面的資源擁有不同的管理權(quán)限，這些資源包括數(shù)據(jù)源、應(yīng)用、頁面等，admin可以對workspace內(nèi)的用戶分配不同的權(quán)限組，從而對應(yīng)用的開發(fā)、發(fā)布等流程上進行管理。具體各權(quán)限組的權(quán)限分配參考下表：

3.2 可視化應(yīng)用開發(fā)

傳統(tǒng)后臺開發(fā)與采用低代碼平臺進行后臺開發(fā)的流程區(qū)別如下圖所示：

傳統(tǒng)后臺開發(fā)過程中需要開發(fā)者自身搭建開發(fā)環(huán)境，引入前端組件庫如Ant Design，相同的功能需要自己提取組件，開發(fā)效率低效。

PGClowcode低代碼平臺提供了可視化拖拽的面板，支持頁面復(fù)雜布局。組件欄支持40+種通用組件，并可以組合使用。

在頁面繪制方面，通過將其拖入畫板，調(diào)整位置布局，簡單幾步完成界面的設(shè)計，做到了所見即所得。相同功能可以在畫布中復(fù)制粘貼，應(yīng)用本身也支持導(dǎo)入導(dǎo)出功能，方便項目復(fù)制。開發(fā)變得靈活高效，避免了一些基本構(gòu)建所產(chǎn)生的bug，達到了降本增效的效果。

在組件的屬性值設(shè)定方面，可以通過可視化的輸入或者通過自定義JS代碼的方式進行復(fù)雜的邏輯綁定，并且也支持編寫js代碼完成復(fù)雜的交互邏輯。平臺內(nèi)置了多種js庫，可以將數(shù)據(jù)綁定到組件上，在開發(fā)狀態(tài)下能立即看到數(shù)據(jù)渲染的效果，使得在預(yù)覽狀態(tài)下可以邊開發(fā)邊自測。

3.3 流程管理

應(yīng)用從開發(fā)態(tài)->測試態(tài)->發(fā)布態(tài)的流轉(zhuǎn)十分便利。平臺設(shè)計了不同角色，將測試、審核的流程精簡化，各角色登錄后可以看到應(yīng)用的不同狀態(tài)，應(yīng)用在開發(fā)和審批后自動流轉(zhuǎn)至下一狀態(tài)，只需要簡單幾個流程即可完成。

1）開發(fā)人員（開發(fā)態(tài)）：根據(jù)需求搭建、開發(fā)頁面，然后發(fā)布到測試環(huán)境；

2）測試人員（測試態(tài)）：在頁面測試，保證其能滿足需求，且不存在質(zhì)量問題后點擊Publish提交發(fā)布申請；

3）審核人員（發(fā)布態(tài)）：在“待我審核”列表中找到審核申請。審批通過，應(yīng)用自動完成發(fā)布。

3.4 備份與還原

開發(fā)平臺支持了應(yīng)用數(shù)據(jù)的備份和歷史版本數(shù)據(jù)的還原。在開發(fā)狀態(tài)下平臺采用了自動保存的設(shè)計方案，由于多人同時開發(fā)時容易出現(xiàn)相互覆蓋或操作沖突的情況，為了減少這種問題導(dǎo)致的返工成本，我們設(shè)計了備份和還原的功能。

和正常普通的應(yīng)用一樣，用戶可以將每個穩(wěn)定版本的開發(fā)態(tài)備份到系統(tǒng)，在之后的操作中需要回到某個穩(wěn)定版本則直接選中目標(biāo)版本還原即可。

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

四、架構(gòu)和技術(shù)

PGClowcode平臺采用了前后端分離架構(gòu)。前端使用了react技術(shù)棧，并且集成了攜程的多種公共框架和組件，依托于攜程的CI/CD平臺，實現(xiàn)了持續(xù)開發(fā)和交付的能力。服務(wù)端采用spring webflux框架，集成了cat、clog（攜程日志系統(tǒng)）、mongo、credis（攜程redis client）、qconfig(攜程配置中心中間件，下文簡稱QC)、qmq（攜程MQ中間件）等技術(shù)框架，完全融入了攜程的服務(wù)技術(shù)棧，可以通過gitlab自動化編譯打包，在captain（攜程發(fā)布平臺）上發(fā)布。

4.1 架構(gòu)

如上圖所示，PGClowcode平臺的整體架構(gòu)分為應(yīng)用層、基礎(chǔ)設(shè)施、服務(wù)層、數(shù)據(jù)層。

應(yīng)用層是終端的兩套平臺系統(tǒng)，主要包括面向用戶的低代碼開發(fā)平臺和面向開發(fā)人員的組件開發(fā)平臺。

基礎(chǔ)設(shè)施主要包含前端的基礎(chǔ)框架、數(shù)據(jù)流控制以及抽象出來的前端可視的組件、頁面和編輯器等概念?；A(chǔ)框架主要依托于React App和canvas技術(shù)通過axios庫和服務(wù)端進行數(shù)據(jù)交互，通過Redux及相關(guān)插件來控制整個平臺的數(shù)據(jù)流，最終展示成用戶可見的組件、頁面、編輯器等UI模塊。

服務(wù)層主要由web層、service層和數(shù)據(jù)訪問層組成，主要提供權(quán)限驗證、流程管控、插件管理、消息通知、數(shù)據(jù)訪問等服務(wù)。服務(wù)采用了微服務(wù)架構(gòu)的設(shè)計，按照不同的領(lǐng)域和功能拆分成領(lǐng)域服務(wù)、通知服務(wù)和插件服務(wù)。

領(lǐng)域服務(wù)又根據(jù)不同的model細分為不同的模塊，各自完成獨立單一的功能；通知服務(wù)主要用于email、trippal、sms等消息通知；插件服務(wù)主要提供插件的加載、初始化、調(diào)用、卸載等相關(guān)功能的服務(wù)。數(shù)據(jù)訪問在核心服務(wù)的下層，實現(xiàn)了針對多種數(shù)據(jù)源的訪問和數(shù)據(jù)處理、校驗的功能。

數(shù)據(jù)層主要用于存儲元數(shù)據(jù)、應(yīng)用數(shù)據(jù)、插件數(shù)據(jù)等，應(yīng)用的備份數(shù)據(jù)存儲于QC，并且通過QC實現(xiàn)跨環(huán)境發(fā)布。

下面兩節(jié)主要對平臺“組件的可視化拖拽實現(xiàn)”和“應(yīng)用的開發(fā)-部署實現(xiàn)”兩項比較核心的技術(shù)詳細闡述。

4.2 組件的可視化拖拽實現(xiàn)

可視化拖拽組件是低代碼平臺的基本功能，在本平臺中，用戶可以在左側(cè)組件庫里選擇任意組件拖拽到中間的編輯區(qū)域，并更改其大小。

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

1）拖拽組件的過程中，組件的位置會實時變更，大量嵌套在一起的dom元素同時變更位置，會頻繁觸發(fā)瀏覽器的重繪制，導(dǎo)致性能的消耗。

2）人為的拖拽排布，很難保證組件之間的對齊和排版，頁面最終效果難以達到代碼實現(xiàn)頁面的規(guī)整程度。

對于上述的問題1，平臺的解決方案是依托canvas技術(shù)，在組件變更位置或者大小時，隱藏實際渲染在頁面上的組件，并在編輯區(qū)域最上層渲染一層canvas，在原組件位置畫出一個同等大小的色塊來代替原組件，并用以示意用戶，利用canvas畫布的特性來處理組件位置及大小的變更，在用戶結(jié)束拖拽動作后，根據(jù)色塊在canvas中的最終位置及大小，重繪制一次組件，并隱藏canvas，展示出組件的最終效果。

在上述描述中可以看到，利用canvas可以極大程度的削減瀏覽器重繪制的次數(shù)，達到減少性能消耗的目的；選擇色塊來作為繪制對象而非原組件，既降低了技術(shù)實現(xiàn)的難度，又進一步降低了canvas繪制圖形的性能消耗。

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

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

1）頁面無拖拽操作，主編輯區(qū)域僅展示組件的靜態(tài)狀態(tài)，此時為展示態(tài)。

2）當(dāng)用戶開始拖拽組件以期改變其位置及大小的動態(tài)狀態(tài)，為操作態(tài)。操作態(tài)又可以細化為拖拽開始、拖拽中、拖拽結(jié)束，三個狀態(tài)。

當(dāng)用戶開始拖拽組件時，頁面會從展示態(tài)變更為操作態(tài)。拖拽開始時，編輯區(qū)域內(nèi)繪制canvas并鋪設(shè)陣點，原組件變?yōu)椴豢梢?，在canvas內(nèi)原組件的相同位置繪制同等大小的色塊以及虛線邊框；在拖拽過程中，色塊會隨著鼠標(biāo)移動變更位置或者大小，其外部虛線邊框也會隨色塊移動或變更大小，并實時定位在色塊當(dāng)前位置的最相鄰陣點上；拖拽結(jié)束時，根據(jù)當(dāng)前邊框的最終大小及位置，重新繪制原組件，并隱藏canvas、陣點系統(tǒng)、色塊以及虛線邊框；頁面由操作態(tài)變更為展示態(tài)，展示出組件的最新狀態(tài)。

4.3 應(yīng)用的開發(fā)-部署實現(xiàn)

應(yīng)用的開發(fā)和部署的技術(shù)實現(xiàn)主要分為應(yīng)用的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流轉(zhuǎn)和多種角色協(xié)同三個部分，最后針對應(yīng)用的數(shù)據(jù)備份與還原也做了簡單的介紹。

4.3.1 數(shù)據(jù)結(jié)構(gòu)

當(dāng)前大多數(shù)主流的低代碼平臺最終的產(chǎn)物可能是代碼，但PGClowcode平臺最終的產(chǎn)物是數(shù)據(jù)，包括應(yīng)用信息、頁面信息、組件、組件之間的關(guān)系、action、數(shù)據(jù)源等都是以數(shù)據(jù)的形式存儲在db上，由于頁面的布局、組件嵌套、函數(shù)的綁定等各種實體間關(guān)系非常復(fù)雜，使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫無法保證數(shù)據(jù)結(jié)構(gòu)穩(wěn)定，因此采用了mongodb作為數(shù)據(jù)庫。應(yīng)用相關(guān)的collection主要包括了plugin、workspace、datasource、application、page、action、actioncollection，它們通過下圖的關(guān)系構(gòu)成了整個應(yīng)用體系。

plugin主要用于定義平臺支持插件的元數(shù)據(jù)信息，包括類型、插件包路徑、參數(shù)、狀態(tài)等屬性。

workspace是應(yīng)用開發(fā)的工作空間，它定義了空間內(nèi)的用戶組成、用戶權(quán)限、數(shù)據(jù)源以及支持的插件集合。

application定義了應(yīng)用的名稱、主題、icon、狀態(tài)等基本信息，另外為了查詢便捷，也冗余了部分頁面的信息。

page定義了頁面的名稱、布局、組件、組件的關(guān)系、組件與函數(shù)的綁定關(guān)系等。

datasource定義了外部數(shù)據(jù)訪問的基礎(chǔ)信息，如restapi、es、mongodb等外部數(shù)據(jù)訪問的必要屬性，為了避免重復(fù)配置，它的作用范圍是workspace級別。

action定義了外部數(shù)據(jù)訪問的具體配置數(shù)據(jù)，它必須依托于datasource，如restapi接口調(diào)用，datasource配置了服務(wù)的域名和是否需要實時鑒權(quán)，而action則配置路徑、參數(shù)、運行方式，與datasouce不同的是它的作用范圍是頁面。

actionCollection是action或js函數(shù)的集合。

4.3.2 數(shù)據(jù)流轉(zhuǎn)

應(yīng)用數(shù)據(jù)主要是在不同的存儲介質(zhì)和不同的環(huán)境間流轉(zhuǎn)，平臺目前設(shè)計了三套環(huán)境FAT、UAT、PRO，平臺通過QC的跨環(huán)境機制實現(xiàn)數(shù)據(jù)流轉(zhuǎn)。

如上圖所示，開發(fā)者在FAT上開發(fā)應(yīng)用，應(yīng)用數(shù)據(jù)以草稿態(tài)存儲于DB，開發(fā)完成后將草稿態(tài)數(shù)據(jù)導(dǎo)出到QC的FAT環(huán)境，服務(wù)監(jiān)聽到QC的數(shù)據(jù)變更將草稿態(tài)copy到發(fā)布態(tài)，測試則可以在測試頁面上看到開發(fā)提交的應(yīng)用，測試完成后提交UAT發(fā)布申請，服務(wù)將發(fā)布態(tài)的數(shù)據(jù)導(dǎo)出到QC的UAT環(huán)境，此時審核者將收到待審核通知。

進入平臺將待發(fā)布申請審核通過后，UAT環(huán)境的服務(wù)監(jiān)聽到QC數(shù)據(jù)變更將數(shù)據(jù)導(dǎo)入到DB，并且將應(yīng)用數(shù)據(jù)狀態(tài)置為發(fā)布態(tài)，然后可以在UAT的測試頁面看到發(fā)布態(tài)的應(yīng)用，當(dāng)UAT測試完成后申請發(fā)布到生產(chǎn)（PRO），UAT服務(wù)將發(fā)布態(tài)應(yīng)用數(shù)據(jù)導(dǎo)出到QC PRO環(huán)境，當(dāng)審核者通過申請后則QC PRO的應(yīng)用文件被發(fā)布，PRO服務(wù)監(jiān)聽到數(shù)據(jù)變更就將應(yīng)用數(shù)據(jù)導(dǎo)入到DB，并置為發(fā)布態(tài)，此時應(yīng)用的開發(fā)-部署流程結(jié)束，用戶可以在生產(chǎn)環(huán)境的用戶平臺正常使用了。

4.3.3 多角色協(xié)同

對于應(yīng)用的開發(fā)、測試、交付平臺設(shè)計了多個角色，在整個需求開發(fā)的過程中每個角色能各司其責(zé)，保證應(yīng)用能持續(xù)、穩(wěn)定、高效迭代交付，如下圖所示。

平臺通過定義多個權(quán)限組來區(qū)分每個角色，當(dāng)workspace被創(chuàng)建時這些權(quán)限組就會被創(chuàng)建出來，每個權(quán)限組定義了各自的權(quán)限，在每個受權(quán)限管理的資源中都有policies字段，它存儲了能被操作的類型和權(quán)限組id的集合，當(dāng)用戶查詢和操作時都會經(jīng)過權(quán)限校驗。

有了角色的定義，應(yīng)用開發(fā)人員的協(xié)同就變得簡單多了，如當(dāng)應(yīng)用發(fā)布測試時可以自動通知測試人員介入，提交發(fā)布生產(chǎn)申請時可以自動通知審核人員參與審核。

4.3.4 備份與還原

為了方便開發(fā)過程中多人同時開發(fā)，平臺設(shè)計了備份還原功能，當(dāng)用戶點擊備份時，服務(wù)將當(dāng)前草稿態(tài)數(shù)據(jù)導(dǎo)出到QC，點擊還原則將QC的數(shù)據(jù)導(dǎo)入到服務(wù)，覆蓋當(dāng)前DB中草稿態(tài)數(shù)據(jù)，得益于QC的版本管理功能，每次備份的數(shù)據(jù)都將存儲起來，因此用戶可以還原到歷史的任意版本。

如上圖所示，T1時刻新增一個備份v1，T2時刻QC中存在v1版本的備份數(shù)據(jù)，如果T2時刻再增加一個備份v2，到T3時刻QC存在v1和v2兩個版本，如果在T3時刻將DB中的版本還原成v1，則DB中的數(shù)據(jù)會被還原成v1，與此同時會上傳一個v3版本到QC，實際上v3和v1數(shù)據(jù)是一樣的，相當(dāng)于將當(dāng)前數(shù)據(jù)的基準(zhǔn)切換到了最新版本，之后的操作都是在這個版本的基礎(chǔ)上做的，如果再需要還原到這個基準(zhǔn)就可以快速完成。

五、規(guī)劃與展望

目前PGC低代碼平臺已經(jīng)具備了非常完整的功能，基本上完成了預(yù)期的目標(biāo)，也產(chǎn)生較大的價值，但我們對于它的期望絕非只限于此，并且組建了穩(wěn)定的支持團隊，制定了明確規(guī)劃，在之后的迭代開發(fā)中會不斷地完善已有的功能和流程，而且會根據(jù)實際的需求和業(yè)內(nèi)平臺的調(diào)研繼續(xù)增加更強大、便捷的功能。

5.1 搭建組件擴展平臺

平臺原有的組件是比較基本的組件庫，未來會難以滿足日漸復(fù)雜的業(yè)務(wù)需求，因此自定義組件的需求就會逐漸凸顯出來，本平臺基于Appsmith框架是支持自定義組件的，但是原有的自定義功能有如下幾個問題：

1）原有的自定義組件功能，需要依托于完整的平臺項目，在其widget文件夾下開發(fā)新組件，項目代碼體量大，啟動慢，且以開發(fā)組件為目的頻繁更改提交平臺項目并不利于平臺項目的發(fā)布及管理。

2）原有的自定義組件功能并不適合多部門自定義組件的場景，沒有相關(guān)的權(quán)限管理系統(tǒng)，所有自定義組件都會展示在頁面上，隨著時間的推移會造成組件庫的臃腫以及增加編輯頁面時查找使用組件的費力度。

為了解決以上問題，我們會從主項目中抽離出相關(guān)代碼，搭建一套獨立的組件開發(fā)項目，以達到和平臺主項目分離、代碼純凈、項目快速啟動的目的。同時也會構(gòu)建一套自定義組件的權(quán)限管理系統(tǒng)以便更好的管理各部門開發(fā)的自定義組件。

5.2 建立模板庫

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

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

繼續(xù)閱讀：

未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動力 | RPA新聞 | 推動中國RPA生態(tài)發(fā)展 | 流 > 干貨 | 攜程后臺低代碼平臺的探究與實踐