阿里開源低程式碼引擎和生態建設實戰及思考

前言

大家好，今天很開心有機會跟大家分享最近幾年阿里在低程式碼領域的思考和實戰。

我是力皓，目前已經在前端和後端崗位工作了十多年了，近 3 年專注在低程式碼領域，是阿里低程式碼引擎專案負責人。

我的部門是企業智慧事業部，我們部門有大量中後臺場景，所以我們在 6 年前就開始低程式碼領域的探索了，並且一直在持續投入，我們用將近 3 年的時間，牽頭打造了一套全集團通用的低程式碼基礎設施，目前被集團 70% 的低程式碼平臺依賴。

分享內容主要分為 3 塊：首先會介紹，在阿里紛繁複雜的業務背景下，使用者角色繁多，技術棧各異，我們是如何思考低程式碼技術體系架構的；然後，我會介紹低程式碼技術體系的架構實戰，重點介紹過程中沉澱的兩個技術產品；最後，我會跟大家分享阿里的幾個具體的低程式碼場景以及平臺建設。

最後的最後，還有一個小彩蛋。

在正式開始之前，先冒昧地問大家一個問題：如今，PHP 還是最好的語言嗎？是？不是？當然不是，DnD 才是！DnD 是 drag & drop，相信使用過低程式碼平臺的同學肯定知道我的意思。

第一部分 - 低程式碼體系的架構設計思考

好啦，先跟大家聊聊「低程式碼體系的架構設計思考」。

咱們先一起回顧下什麼叫低程式碼？來看下維基百科的定義，低程式碼開發平臺提供了一種讓開發人員通過視覺化+設定的方式來建立應用，而不是通過手寫程式碼。再來看下 Forrester 的定義，平臺提供了一種快捷交付業務應用的能力，而不需要我們手寫太多的程式碼，也不需要了解常規開發中的前置工作，比如瞭解程式語言、設定開發環境等。

字不少，嘗試提取幾個關鍵詞，視覺化、設定化、低門檻、快捷交付（GUI、Configuration、Minimal Upfront Investment 和 Rapid Delivery）。我們先不深究這幾個詞的意思，來看幾個例子。

辦公室行政人員小 A，主任讓他收集全辦公室100個人的行程資訊，他用一個 表單低程式碼平臺 快速搭建了行程記錄表單應用，同事填完後，還能從後臺實時通過圖表看資料。

行銷人員小 B，總監讓他做個行銷小程式，他用一個 小程式低程式碼平臺，拖拖拽拽完成了小程式的搭建，然後一鍵釋出，完成了本不可能完成的任務。

開發人員小 C，天天苦於寫標準化的表單、表格頁面，他感覺是重複勞動，但又不得不做，直到某天他發現用一個 模型驅動的低程式碼平臺，通過定義資料模型後，可以自動化生成頁面 CRUD，又快又好。

好了，相信通過這幾個例子，大家對低程式碼有了更形象、更深的理解。

總結一下，我們可以通過視覺化介面來設定完成傳統的應用程式開發 & 交付過程，而不需要了解太多的開發技能，讓辦公室行政人員、行銷人員等非技術人員輕鬆完成「研發」工作，讓開發人員更快地研發。

所以，我理解的低程式碼的核心價值是「降本提效」和「角色賦能」。

正因為有了這兩點核心價值，阿里有一些部門很早就已經在低程式碼領域探索併產生了一些平臺，平臺之間相互獨立，屬於典型的煙囪架構，煙囪架構從公司整體視角來看有一些問題，比如有一些通用能力沒法複用，導致平臺建設的成本高且質量稂莠不齊。而這些問題正是我們阿里巴巴前端委員會中後臺小組要解決的。

為了避免低水平重複建設，從而降低各業務場景中低程式碼平臺的建設成本，提升低程式碼體系中物料、外掛、解決方案、產物等的可流通性，由前端委員會牽頭，決定對低程式碼技術體系進行拉通共建，制定統一的底層協定，併合力打造一套統一的低程式碼基礎設施。

我們有各種技術棧，有 react / vue / 小程式，我們有各種使用者角色，有產品經理、設計師、業務人員、前後端開發，當然，我們還有各種業務場景，有淘寶 toC 業務，有企業智慧 toB 業務，有做資料類業務，有做設計研發一體化的業務。

如何找到平臺的共同點？以及支撐平臺差異點？這是架構能否成功的關鍵！思考再三，我們確定了十二字設計原則：協定先行，最小核心和最強生態。

最終我們設計了這樣一套分層架構，自下而上分別是協定 - 引擎 - 生態 - 平臺。底層協定棧定義的是標準，標準的統一讓上層產物的互通成為可能，**引擎是對協定的實現，同時通過能力的輸出，向上支撐生態開放體系，提供各種生態擴充套件能力，**那麼生態就好理解了，是基於引擎核心能力上擴充套件出來的，比如物料、設定器、外掛等，還有工具鏈支撐開發體系，最後，各個平臺基於引擎核心以及生態中的產品組合、銜接形成滿足其需求的低程式碼平臺。

每一層都明確自身的定位，各司其職，協定不會去思考引擎如何實現，引擎也不會實現具體上層平臺功能，上層平臺的客製化化均通過外掛來實現，這些理念將會貫穿我們體系設計、實現的過程。

第二部分 - 求同：阿里低程式碼引擎&UIPaaS

首先聊聊協定棧，目前我們有兩個：一個叫《阿里巴巴中後臺前端搭建協定規範》，另一個叫《阿里巴巴中後臺前端物料規範》。這兩份協定是阿里在低程式碼領域最資深的同學編寫的，歷經了半年之久。因為協定是整個體系的基石，我覺得值得。

內容很多，我這裡簡單做個概括，兩份協定定義了 3 方面的內容，分別是術語、結構和行為。

• 術語是我們溝通的基礎，概念相通，我們才能高效溝通。我們根據物料的顆粒度，定義了基礎元件、區塊、低程式碼元件、模板等術語，另外還包括低程式碼生產過程中一些模組名稱，比如編輯器、畫布、事件繫結、資料繫結、渲染、出碼、設定器之類的術語，
• 結構，包括頁面描述的結構，如何定義頁面元件樹、資料來源、生命週期、頁面狀態等等。
• 行為，不同的業務場景，我們對物料的設定、約束、擴充套件各不相同，所以我們在物料描述中有各種各樣的勾點來支援自客製化。

 

正是有了幾份協定，讓上層的互通成為可能，概念互通，物料互通，生態互通。另外，協定也是實現多技術棧的關鍵，後面我會進一步闡述。

低程式碼引擎分為 4 大模組，入料、編排、渲染、出碼。

• 入料模組就是將外部的物料，比如海量的 npm 元件，按照《物料描述協定》進行描述。注意，這裡僅是增加描述，而非重寫一套，這樣我們能最大程度複用ProCode體系已沉澱的元件。將描述後的資料通過引擎 API 註冊後，在編輯器中使用。
• 編排，本質上來講，就是不斷在生成符合《搭建協定》的頁面描述，將編輯器中的所有物料，進行佈局設定、元件 CRUD 操作、以及 JS/CSS編寫/邏輯編排等，最終轉換成頁面描述，技術細節待會兒我們再展開講講。
• 渲染，顧名思義，就是將編排生成的頁面描述結構渲染成檢視的過程，檢視是面向使用者的，所以必須處理好內部資料流、生命週期、事件繫結、國際化等。
• 出碼，就是將頁面描述結構解析和轉換成應用程式碼的機制。

下面我們展開來聊聊編排，首先我們得有一個工作臺，我們叫編輯器骨架，分為幾個預設可視的區域，以及一些可以展開的區域，可以彈窗顯示的區域。中心區域，是編排和渲染的畫布。

前面說過，編排的本質是不斷生成符合《搭建協定》的頁面描述的過程，然後通過渲染器將頁面描述渲染成真正的檢視。

協定是文字協定，是一個 json 結構，理論上手寫也能完成，但是考慮到可程式化性，我們設計了一套節點和屬性模型，類似於 DOM，這樣操作節點 + 設定屬性就等價於在操作頁面描述，也就是操作 json 結構了。

除了節點模型和屬性模型之外，上層還有檔案&專案模型，對於物料的管理，有物料序號產生器制和物料模型，另外我們提供了通用的面板管理、拖拽引擎、resize引擎，設計器輔助層、原地編輯、快捷鍵等二十幾個模組，這裡就不細說了。

而這所有的模組的能力，也就是 API，都通過外掛進行呼叫，於是外掛成為了擴充套件編輯器的唯一載體。你可以客製化你的面板，可以操作節點樹，可以客製化節點的擴充套件操作，可以去操作物料模型，可以去繫結快捷鍵，可以設定畫布大小，可以客製化拖拽行為等等。

再來聊聊出碼，對於一些常規場景，直接由渲染模組渲染即可。但是考慮到一些特殊情況，比如一些不支援動態化的場景，小程式，或者為了更好的效能，轉碼成 ProCode 打包部署，或者需要二次開發，因此，我們設計了出碼框架。出碼框架提供一套流水線式的處理流程，類似 babel 的機制，通過一個個的出碼外掛 / preset 來客製化你的出碼產物，市面上的 react 框架、vue 框架、小程式框架都可以支援。

再來聊聊引擎生態的設計，前面也提到，最小核心最強生態是我們的設計原則，因此如何定義什麼是核心能力，什麼是生態以及如何支撐生態，是我們整個體系設計的重中之重。

經過我們支撐眾多平臺的經驗，我們發現平臺的差異性體現在這 3 點，物料、設定器和外掛，其中外掛是擴充套件的入口，包括物料和設定器也是通過外掛才能註冊到引擎。我們定義了引擎的約束，這是唯一不可變的部分，以及引擎 API 的能力，包括面板、畫布、物料管理、拖拽等所有能力，都可以通過外掛來使用。同時，外掛我們設計成高內聚、顯性化設定、可流通的形態，這支撐了外掛生態的形成，甚至更高層面，讓自定義設計器也可以通過視覺化設定實現。多說一嘴，因為生態體系如此重要，我們在生態元素偵錯能力上也下了一番功夫，目前我們通過工具鏈 + 偵錯外掛讓一切生態元素均可偵錯，可相互組合偵錯，可線上偵錯。

我們具象化一點來看引擎生態，這是一個標準的中後臺設計器頁面。藍色部分是外掛，這些都是能被看到的外掛，因為呼叫的是面板 API，不僅如此，還有一些不能被看到，比如呼叫了快捷鍵 API，拖拽 API、事件 API 等。紅色部分就是設定器了，可以客製化我們如何給一個節點的屬性賦值。橙色部分就是物料了，其實物料本質上是一個模型，也是不可見的，不過這裡通過物料面板呼叫了物料 API 來顯性化展示了物料，再通過拖拽 API 和 節點 API 來拖拽並插入到畫布中。

豐富的生態，讓快速、低成本打造低程式碼平臺成為可能。我們有物料生態、設定器生態、外掛生態，因此，我們推匯出一個簡單的公式，打造低程式碼的設計器等價於引擎 + 選擇物料 + 選擇設定器 + 選擇外掛。

再來聊聊我們如何通過協定來支援多技術棧。不管是《阿里巴巴中後臺前端搭建協定規範》，還是《阿里巴巴中後臺前端物料規範》，都是與語言無關的。你定義一套物料描述，而具體實現可以是 react / vue 或者任何技術棧，而對於搭建頁面，你可以在設計態用 react 元件，渲染時也用 react 元件，但注意，因為設計和渲染的中間產物頁面描述也是語言無關的，所以渲染時可以是任意語言，可以是 react，可以是 vue，當然也可以是小程式。

當然混搭的場景不是我臆想的哈，阿里內部有不少混搭的實踐。

再來聊聊編排和渲染的雙層架構設計，通過這個架構，我們實現了絕對純淨的編輯態渲染，即模擬器實現。

這個圖相信大家都很熟悉，編輯器中內嵌一個所見即所得的渲染模組，但這會有一個問題，css 汙染的問題，因為編輯器中各個模組，物料、設定器、外掛都來自不同的團隊，很容易產生 css 汙染。編輯器中的元素互相汙染問題都不算太大，但是汙染了渲染檢視就很嚴重了，大家可以思考下為什麼？

我們的解法是將模擬器放入到一個新的 iframe 中執行，通過編輯器將相關資源注入到模擬器，建立資料通道，使用 facade 模式，即在編輯器和模擬器中各有一個 facade 物件來負責對外的方法暴露和呼叫，避免深度耦合。

低程式碼引擎通過協定先行，最小核心，最強生態的理念，形成了 4 大模組以及生態擴充套件性的整體設計，在靈活性上足以支撐各種型別低程式碼平臺。

但是，大家此時可能會有些疑問，這引擎 + 生態的組合似乎還是偏底層，離一個真正生產可用的低程式碼平臺有點距離。比如：

• 搭建出來的頁面描述儲存到哪裡去？
• 搭建完成後，產物打包系統哪家強？
• 頁面多人編輯衝突如何解決？
• 研發流程如何定義？
• 版本管理，多分支咋搞？
• 頁面區塊 / 低程式碼元件 怎麼搭建？怎麼使用？

這裡的問題可以列出上百個，因為這都是我們遇到並已經解決的問題。

所以，我們在引擎之上再加上一層，形成一個低程式碼平臺的基座，或者叫孵化器。我們把這個低程式碼平臺的孵化器叫做 UIPaaS，在阿里內部，我們更多是基於 UIPaaS 來開始打造低程式碼平臺，這樣會更輕鬆一點。為什麼要做 UIPaaS？兩點原因：

• 解決產品能力的問題，實現了應用管理、研發流程、打包流程、釋出流程 等一系列能力
• 解決快速在找到符合需求的生態元素組合

我們來看看它包含哪些能力以及支援哪些客製化化：

• 設計器：提供一個開箱即用的標準版頁面設計器，開箱即用意味著整合了一批外掛，外掛都已經跟後端服務相繫結了；提供簡單版、進階版設計器客製化方案。
• 執行時：提供穩定的，功能豐富的執行時 SDK，包括頁面描述的獲取、路由、layout，甚至還有一套執行時中介軟體機制
• 生態：提供「生態中心」，大量元件、外掛、解決方案唾手可得；提供「一站式研發平臺」，可開發、偵錯低程式碼領域的所有物料
• 管理後臺：提供功能完善、方便客製化的管理後臺模板應用，包括研發流程、應用依賴管理、打包設定、路由設定等
• 後端服務：官方提供 140+ 閘道器介面，覆蓋設計器、執行時、管理後臺等全流程；允許上層平臺註冊服務到 UIPaaS，供其他平臺使用。

第三部分 - 存異：百花齊放的低程式碼平臺

最後來看一下百花齊放的低程式碼平臺。我們有各種業務場景，各種使用者角色，各種技術棧，因此產生形形色色的低程式碼平臺幾乎是個必然結果。唯一的問題是如何低成本、快速地支撐各個平臺的開發，在阿里，我們通過 UIPaaS 孵化器來支撐。

總結了一下目前我們打造的垂直類平臺，有耳熟能詳的中後臺，有運營場景，資料包表類場景，還有以設計類為代表的角色協同、產物互通的平臺，還有移動應用、IoT、aPaaS 等型別。

平臺很多，因為各種原因沒法一一展示，這裡我們來看幾個典型的平臺：這是一箇中後臺平臺，功能包含頁面大綱樹、元件面板、原始碼面板、國際化、模型編排等核心能力，以及打包系統、研發管理等模組。

這是一個資料包表類的平臺，會對圖表庫、資料模組、賬號許可權體系、設定器等做深度客製化。

這是一個小程式編排平臺，核心是接入一套小程式的元件，客製化一些小程式特有的設定，以及對接各個釋出渠道。

雖然提到了很多低程式碼平臺，似乎讓使用低程式碼開發成為了一種風潮。但是我建議不要盲目跟風，低程式碼研發也只是一種研發正規化，跟以往任何一種研發正規化相比，沒有孰高孰低。適合的，才是最好的，評估標準只有兩點：是否能研發提效？以及是否能角色賦能？

彩蛋 - 協定對外開放 & 低程式碼引擎開源

最後，就是喜聞樂見的彩蛋了~

跟大家介紹一下低程式碼引擎在阿里的發展史，大家注意，我將協定起草這個節點標註成了橙色，因為這個節點代表了整個集團從分兵作戰轉成集團軍作戰的關鍵里程碑。之後的協定釋出、集團引擎、UIPaaS 等各個節點也就順理成章了~

低程式碼協定和低程式碼引擎經過了近3年在阿里內部不斷捶打和磨練，在生態建設以及平臺支撐上都取得了不錯的成績。後續我們會將其開源，讓大家共用這套低程式碼基礎設施，繼續接受社會的捶打和磨練