iPhone賣不動了！蘋果股價創年內最大日跌幅：市值一夜蒸發萬億元
8月5日消息，今天凌晨美股三大指數高開低走集體收跌，道指跌0.41%；納指跌0.36%；標普500指數跌0.52%。熱門科技股也都變化極大，其中蘋果報181.99美元，跌4.8%，創
作者簡介
ck，攜程后端開發專家，關注技術架構、高并發、性能調優等領域；
Geralt，攜程前端開發專家，關注前端框架及性能優化；
Kaoru，攜程資深前端開發工程師，關注前端性能及開發工具；
PGClowcode平臺是攜程市場內容PGC團隊搭建的主要用于后臺頁面開發的低代碼平臺，第一版于23年3月上線，截至10月平臺已經擁有100+用戶，在平臺上開發了130+個應用和180+個頁面。本文將主要介紹團隊采用低代碼平臺的背景、方案調研、落地過程中遇到的問題以及解決方案，同時也大致介紹了該低代碼平臺提供的能力。
軟件產品通常由客戶端（App、小程序、網頁）和運營后臺組成，其整個生命周期需要不斷地更新迭代，而在實際的迭代開發中經常會出現以下問題：
針對這些問題我們也嘗試了很多的解決方案，如要求開發人員全棧、剝離公共組件等，但結果都不太理想，經過充分的了解和分析，搭建低代碼或零代碼平臺能在很大程度上解決這些問題。
低代碼平臺分為很多種，我們究竟需要哪種呢？經過將以上問題拆分細化和充分調研后，我們的低代碼平臺應該滿足以下要求：
頁面搭建方面：
部署運維方面：
具有開發、部署、運維等完整的持續交付功能，最好能一鍵或自動化完成
安全合規方面：
兼容性方面：
能嵌入已有后臺頁面，已有后臺盡量少改動的嵌入其開發的頁面
可擴展性方面：
支持用戶自助化組件開發，并且能在平臺上推廣
目前國內外低代碼或零代碼產品不下百種，既有商業平臺，也有開源項目，它們在企業內部用于各種運營后臺、數據面板、辦公系統等內部系統的開發，在B端提供商品管理、廣告投放、商鋪搭建等企業服務，在C端廣泛用于活動頁面、促銷頻道、廣告頻道等類型產品的搭建，不僅為企業節省了大量的開發成本、產生巨大的商業價值，同時也為用戶提供了豐富多彩的軟件產品。
雖然低代碼種類繁多，但是每類低代碼項目往往具有特定的業務屬性，在不同的行業，不同的公司可能需要定制不同的組件，不同的流程，因此市場上很少有能適用于所有場景的平臺，也很少有企業愿意去做通用平臺。下面分析了目前比較流行的產品：
阿里低代碼引擎
LowCodeEngine（阿里低代碼引擎）是國內最知名的低代碼類產品之一，其完整的實現了《低代碼引擎搭建協議規范》和《低代碼引擎物料協議規范》，它通過完整的協議棧約定了各種物料的開發、使用、擴展、流通，并且提煉了企業級低代碼平臺的特性，遵循面向擴展設計的理念，奉行最小內核、最強生態的設計原則而設計的內核引擎。
目前其生態已經相當完備，并且提供了非常詳細的文檔和使用案例，也有大量的demo開源，其使用起來相對比較便捷。但它并沒有提供完整的平臺代碼，使用者需要在其內核的基礎上搭建面向用戶的平臺和服務系統，具有相當的開發成本。
騰訊低代碼平臺
騰訊的低代碼產品包括搭建生成移動端H5頁面的tmagic-editor開源項目和搭建管理端頁面的無極低代碼商業平臺，其中tmagic-editor提供了完整的平臺代碼，使用者可以在開源社區將整個項目pull到本地部署使用，它具備自定義組件、插件、編輯器等擴展能力，內置了豐富的組件，提供了友好的可視化界面，通過拖拽+配置的方式開發頁面。
但其限定于移動端H5頁面的搭建，無法適用pc端頁面開發的需求，大大限制了使用范圍。無極低代碼平臺是商業化的面向企業付費使用的產品，具備管理端強大的開發能力，甚至結合了AI能力，能供面向企業豐富的解決方案，但它目前并沒有開源。
開源低代碼平臺
在github上搜索lowcode關鍵詞可以看到非常多的項目，他們所使用的技術、項目的形態、star數量、活躍的層度、使用場景各不相同，有些提供了完整的可視化界面，有些則需要通過配置文件或調用接口的方式生成頁面或項目，總之需要花費較多的時間對比分析才能找到符合自身需求的項目。
總結
綜上所述，我們最終決定選擇一款開源程度比較高的項目（appsmith）作為藍本，然后經過改造、開發搭建了PGClowcode平臺。?
PGClowcode平臺功能主要包含頁面搭建、組件開發平臺兩大部分。
頁面搭建包含開發、預覽、測試、發布、回滾、備份、恢復等常用功能。在這些功能的基礎上，增加了"可視化拖拽"、"多用戶協同開發"、"導入導出"、"多數據源"、"通知"等功能，形成了一個相當完善的開發體系。搭建的產物可以通過將平臺上的應用或頁面嵌入到已有的后臺，或者反過來將已有的后臺頁面嵌入到平臺，實現組合使用。
組件開發平臺是對頁面搭建能力的擴展，支持通過CLI構建本地項目，自定義開發新的組件以滿足更復雜的業務需求。（此功能正在開發中，將在不久之后開放）
由于篇幅有限，下面將介紹幾個主要功能。
平臺擁有自己的用戶管理體系，為了與攜程的賬號體系打通，接入了OIDC域賬號認證，使用者無需額外注冊賬號，只需要使用攜程域賬號登錄即可。
用戶的權限做了充分的拆分，平臺的所有功能對每個用戶開放，只是對于用戶私有的數據做了權限控制，權限定義的最小單位是工作空間（workspace），用戶可以擁有多個workspace，每個workspace 定義了管理員（admin）、開發者（developer）、使用者（viewer）、測試者（tester）、審核者（reviewer）五個權限組。其中每個權限組對workspace下面的資源擁有不同的管理權限，這些資源包括數據源、應用、頁面等，admin可以對workspace內的用戶分配不同的權限組，從而對應用的開發、發布等流程上進行管理。具體各權限組的權限分配參考下表：
傳統后臺開發與采用低代碼平臺進行后臺開發的流程區別如下圖所示：
傳統后臺開發過程中需要開發者自身搭建開發環境，引入前端組件庫如Ant Design，相同的功能需要自己提取組件，開發效率低效。
PGClowcode低代碼平臺提供了可視化拖拽的面板，支持頁面復雜布局。組件欄支持40+種通用組件，并可以組合使用。
在頁面繪制方面，通過將其拖入畫板，調整位置布局，簡單幾步完成界面的設計，做到了所見即所得。相同功能可以在畫布中復制粘貼，應用本身也支持導入導出功能，方便項目復制。開發變得靈活高效，避免了一些基本構建所產生的bug，達到了降本增效的效果。
在組件的屬性值設定方面，可以通過可視化的輸入或者通過自定義JS代碼的方式進行復雜的邏輯綁定，并且也支持編寫js代碼完成復雜的交互邏輯。平臺內置了多種js庫，可以將數據綁定到組件上，在開發狀態下能立即看到數據渲染的效果，使得在預覽狀態下可以邊開發邊自測。
應用從開發態->測試態->發布態的流轉十分便利。平臺設計了不同角色，將測試、審核的流程精簡化，各角色登錄后可以看到應用的不同狀態，應用在開發和審批后自動流轉至下一狀態，只需要簡單幾個流程即可完成。
1）開發人員（開發態）：根據需求搭建、開發頁面，然后發布到測試環境；
2）測試人員（測試態）：在頁面測試，保證其能滿足需求，且不存在質量問題后點擊Publish提交發布申請；
3）審核人員（發布態）：在“待我審核”列表中找到審核申請。審批通過，應用自動完成發布。
開發平臺支持了應用數據的備份和歷史版本數據的還原。在開發狀態下平臺采用了自動保存的設計方案，由于多人同時開發時容易出現相互覆蓋或操作沖突的情況，為了減少這種問題導致的返工成本，我們設計了備份和還原的功能。
和正常普通的應用一樣，用戶可以將每個穩定版本的開發態備份到系統，在之后的操作中需要回到某個穩定版本則直接選中目標版本還原即可。
下圖展示了備份還原的操作界面。
PGClowcode平臺采用了前后端分離架構。前端使用了react技術棧，并且集成了攜程的多種公共框架和組件，依托于攜程的CI/CD平臺，實現了持續開發和交付的能力。服務端采用spring webflux框架，集成了cat、clog（攜程日志系統）、mongo、credis（攜程redis client）、qconfig(攜程配置中心中間件，下文簡稱QC)、qmq（攜程MQ中間件）等技術框架，完全融入了攜程的服務技術棧，可以通過gitlab自動化編譯打包，在captain（攜程發布平臺）上發布。
如上圖所示，PGClowcode平臺的整體架構分為應用層、基礎設施、服務層、數據層。
應用層是終端的兩套平臺系統，主要包括面向用戶的低代碼開發平臺和面向開發人員的組件開發平臺。
基礎設施主要包含前端的基礎框架、數據流控制以及抽象出來的前端可視的組件、頁面和編輯器等概念?；A框架主要依托于React App和canvas技術通過axios庫和服務端進行數據交互，通過Redux及相關插件來控制整個平臺的數據流，最終展示成用戶可見的組件、頁面、編輯器等UI模塊。
服務層主要由web層、service層和數據訪問層組成，主要提供權限驗證、流程管控、插件管理、消息通知、數據訪問等服務。服務采用了微服務架構的設計，按照不同的領域和功能拆分成領域服務、通知服務和插件服務。
領域服務又根據不同的model細分為不同的模塊，各自完成獨立單一的功能；通知服務主要用于email、trippal、sms等消息通知；插件服務主要提供插件的加載、初始化、調用、卸載等相關功能的服務。數據訪問在核心服務的下層，實現了針對多種數據源的訪問和數據處理、校驗的功能。
數據層主要用于存儲元數據、應用數據、插件數據等，應用的備份數據存儲于QC，并且通過QC實現跨環境發布。
下面兩節主要對平臺“組件的可視化拖拽實現”和“應用的開發-部署實現”兩項比較核心的技術詳細闡述。
可視化拖拽組件是低代碼平臺的基本功能，在本平臺中，用戶可以在左側組件庫里選擇任意組件拖拽到中間的編輯區域，并更改其大小。
在實現上述的拖拽功能時，我們會面臨幾個問題：
1）拖拽組件的過程中，組件的位置會實時變更，大量嵌套在一起的dom元素同時變更位置，會頻繁觸發瀏覽器的重繪制，導致性能的消耗。
2）人為的拖拽排布，很難保證組件之間的對齊和排版，頁面最終效果難以達到代碼實現頁面的規整程度。
對于上述的問題1，平臺的解決方案是依托canvas技術，在組件變更位置或者大小時，隱藏實際渲染在頁面上的組件，并在編輯區域最上層渲染一層canvas，在原組件位置畫出一個同等大小的色塊來代替原組件，并用以示意用戶，利用canvas畫布的特性來處理組件位置及大小的變更，在用戶結束拖拽動作后，根據色塊在canvas中的最終位置及大小，重繪制一次組件，并隱藏canvas，展示出組件的最終效果。
在上述描述中可以看到，利用canvas可以極大程度的削減瀏覽器重繪制的次數，達到減少性能消耗的目的；選擇色塊來作為繪制對象而非原組件，既降低了技術實現的難度，又進一步降低了canvas繪制圖形的性能消耗。
對于問題2，平臺的解決方案是陣點系統，當用戶拖拽組件到編輯區域觸發渲染canvas的同時，頁面上會繪制一層陣點并均勻的平鋪在canvas上，當用戶在canvas上拖拽色塊變更其位置或者大小時，在色塊的周邊會繪制出同等大小的虛線邊框，邊框會根據色塊當前的位置及大小動態的定位到合適的臨近陣點上。陣點系統中，橫向及縱向兩個相鄰陣點的間隔即為組件長寬的最小單位，組件的四角位置只能定位在陣點上。由此可見，在拖拽過程中，組件的位置及大小都在一定的限制之內，這可以保證最終繪制出來的頁面的規整性。
以下為一次完整的組件拖拽流程示意圖：
1）頁面無拖拽操作，主編輯區域僅展示組件的靜態狀態，此時為展示態。
2）當用戶開始拖拽組件以期改變其位置及大小的動態狀態，為操作態。操作態又可以細化為拖拽開始、拖拽中、拖拽結束，三個狀態。
當用戶開始拖拽組件時，頁面會從展示態變更為操作態。拖拽開始時，編輯區域內繪制canvas并鋪設陣點，原組件變為不可見，在canvas內原組件的相同位置繪制同等大小的色塊以及虛線邊框；在拖拽過程中，色塊會隨著鼠標移動變更位置或者大小，其外部虛線邊框也會隨色塊移動或變更大小，并實時定位在色塊當前位置的最相鄰陣點上；拖拽結束時，根據當前邊框的最終大小及位置，重新繪制原組件，并隱藏canvas、陣點系統、色塊以及虛線邊框；頁面由操作態變更為展示態，展示出組件的最新狀態。
應用的開發和部署的技術實現主要分為應用的數據結構、數據流轉和多種角色協同三個部分，最后針對應用的數據備份與還原也做了簡單的介紹。
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低代碼平臺已經具備了非常完整的功能，基本上完成了預期的目標，也產生較大的價值，但我們對于它的期望絕非只限于此，并且組建了穩定的支持團隊，制定了明確規劃，在之后的迭代開發中會不斷地完善已有的功能和流程，而且會根據實際的需求和業內平臺的調研繼續增加更強大、便捷的功能。
平臺原有的組件是比較基本的組件庫，未來會難以滿足日漸復雜的業務需求，因此自定義組件的需求就會逐漸凸顯出來，本平臺基于Appsmith框架是支持自定義組件的，但是原有的自定義功能有如下幾個問題：
1）原有的自定義組件功能，需要依托于完整的平臺項目，在其widget文件夾下開發新組件，項目代碼體量大，啟動慢，且以開發組件為目的頻繁更改提交平臺項目并不利于平臺項目的發布及管理。
2）原有的自定義組件功能并不適合多部門自定義組件的場景，沒有相關的權限管理系統，所有自定義組件都會展示在頁面上，隨著時間的推移會造成組件庫的臃腫以及增加編輯頁面時查找使用組件的費力度。
為了解決以上問題，我們會從主項目中抽離出相關代碼，搭建一套獨立的組件開發項目，以達到和平臺主項目分離、代碼純凈、項目快速啟動的目的。同時也會構建一套自定義組件的權限管理系統以便更好的管理各部門開發的自定義組件。
Ctrl+C和Ctrl+V可能是開發人員使用頻率最高的按鍵組合，致使一些鍵盤不是“面目全非”就是“半身不遂”，試想一下，如果我們拿出來一鍵生成部署頁面的功能，是否能讓“久經磨難”的鍵盤依然“歷久彌新”呢？沒錯，這是我們接下來的目標。
低代碼平臺的模板是指根據長期積累的經驗，總結一些具有共性的通用方案，并且提煉成所有用戶都能直接使用的頁面或應用，收錄到模板庫中，當平臺上的其他用戶需要使用類似應用或頁面時，只需要找到合適的模板，一鍵即可生成頁面或應用，甚至能拿來即可用，無需做任何修改。后期可以允許建立團隊自己的模板庫，各成員可以搭建自己的模板專門供團隊使用。
本文鏈接：http://www.tebozhan.com/showinfo-26-17284-0.html攜程后臺低代碼平臺的探究與實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： .Net8頂級性能優化：類型轉換
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號