阿裡開源低代碼引擎和生態建設實戰及思考

Posted on 2022-06-20 by WalkonNet

前言

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

我是力皓，目前已經在前端和後端崗位工作瞭十多年瞭，近 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，當然也可以是小程序。

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