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

我是力皓，目前已經(jīng)在前端和后端崗位工作了十多年了，最近 3 年專注在低代碼領域，是阿里低代碼引擎項目負責人。

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

分享的內(nèi)容主要分為 3 塊：首先會介紹，在阿里紛繁復雜的業(yè)務背景下，用戶角色繁多，技術棧各異，我們是如何思考低代碼技術體系架構的；然后，我會介紹低代碼技術體系的架構實戰(zhàn)，重點介紹過程中沉淀的兩個技術產(chǎn)品；最后，我會跟大家分享阿里的幾個具體的低代碼場景以及平臺建設。

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

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

第一部分 – 低代碼體系的架構設計思考

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

咱們先一起回顧下什么叫低代碼？來看下維基百科的定義，低代碼開發(fā)平臺提供了一種讓開發(fā)人員通過可視化 配置的方式來創(chuàng)建應用，而不是通過手寫代碼。再來看下 Forrester 的定義，平臺提供了一種快捷交付業(yè)務應用的能力，而不需要我們手寫太多的代碼，也不需要了解常規(guī)開發(fā)中的前置工作，比如了解編程語言、設置開發(fā)環(huán)境等。

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

辦公室行政人員小 A，主任讓他收集全辦公室100個人的行程信息，他用一個 表單低代碼平臺 快速搭建了行程記錄表單應用，同事填完后，還能從后臺實時通過圖表看數(shù)據(jù)。

營銷人員小 B，總監(jiān)讓他做個營銷小程序，他用一個 小程序低代碼平臺，拖拖拽拽完成了小程序的搭建，然后一鍵發(fā)布，完成了本不可能完成的任務。

開發(fā)人員小 C，天天苦于寫標準化的表單、表格頁面，他感覺是重復勞動，但又不得不做，直到某天他發(fā)現(xiàn)用一個 模型驅(qū)動的低代碼平臺，通過定義數(shù)據(jù)模型后，可以自動化生成頁面 CRUD，又快又好。

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

總結一下，我們可以通過可視化界面來配置完成傳統(tǒng)的應用程序開發(fā) & 交付過程，而不需要了解太多的開發(fā)技能，讓辦公室行政人員、營銷人員等非技術人員輕松完成「研發(fā)」工作，讓開發(fā)人員更快地研發(fā)。

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

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

為了避免低水平重復建設，從而降低各業(yè)務場景中低代碼平臺的建設成本，提升低代碼體系中物料、插件、解決方案、產(chǎn)物等的可流通性，由前端委員會牽頭，決定對低代碼技術體系進行拉通共建，制定統(tǒng)一的底層協(xié)議，并合力打造一套統(tǒng)一的低代碼基礎設施。

我們有各種技術棧，也有 react / vue / 小程序，我們有各種用戶角色，有產(chǎn)品經(jīng)理、設計師、業(yè)務人員、前后端開發(fā)，當然，我們還有各種業(yè)務場景，有淘寶 toC 業(yè)務，有企業(yè)智能 toB 業(yè)務，有做數(shù)據(jù)類業(yè)務，也有做設計研發(fā)一體化的業(yè)務。

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

最終我們設計了這樣一套分層架構，自下而上分別是協(xié)議 – 引擎 – 生態(tài) – 平臺。底層協(xié)議棧定義的是標準，標準的統(tǒng)一讓上層產(chǎn)物的互通成為可能，**引擎是對協(xié)議的實現(xiàn)，同時通過能力的輸出，向上支撐生態(tài)開放體系，提供各種生態(tài)擴展能力，**那么生態(tài)就好理解了，是基于引擎核心能力上擴展出來的，比如物料、設置器、插件等，還有工具鏈支撐開發(fā)體系，最后，各個平臺基于引擎內(nèi)核以及生態(tài)中的產(chǎn)品組合、銜接形成滿足其需求的低代碼平臺。

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

第二部分 – 求同：阿里低代碼引擎&UIPaaS

首先聊聊協(xié)議棧，目前我們有兩個：一個叫《阿里巴巴中后臺前端搭建協(xié)議規(guī)范》，另一個叫《阿里巴巴中后臺前端物料規(guī)范》。這兩份協(xié)議是阿里在低代碼領域最資深的同學編寫的，歷經(jīng)了半年之久。因為協(xié)議是整個體系的基石，我覺得值得。

內(nèi)容很多，我在這里簡單做個概括，兩份協(xié)議定義了 3 方面的內(nèi)容，分別是術語、結構和行為。

• 術語是我們溝通的基礎，概念相通，我們才能高效溝通。我們根據(jù)物料的顆粒度，定義了基礎組件、區(qū)塊、低代碼組件、模板等術語，另外還包括低代碼生產(chǎn)過程中的一些模塊名稱，比如編輯器、畫布、事件綁定、數(shù)據(jù)綁定、渲染、出碼、設置器之類的術語，
• 結構，包括頁面描述的結構，如何定義頁面組件樹、數(shù)據(jù)源、生命周期、頁面狀態(tài)等等。
• 行為，不同的業(yè)務場景，我們對物料的配置、約束、擴展各不相同，所以我們在物料描述中有各種各樣的鉤子來支持自定制。

正是有了幾份協(xié)議，讓上層的互通成為可能，概念互通，物料互通，生態(tài)互通。另外，協(xié)議也是實現(xiàn)多技術棧的關鍵，后面我會進一步闡述。

低代碼引擎分為 4 大模塊，入料、編排、渲染、出碼。

• 入料模塊就是將外部的物料，比如海量的 npm 組件，按照《物料描述協(xié)議》進行描述。注意，這里僅是增加描述，而非重寫一套，這樣我們能最大程度復用ProCode體系已沉淀的組件。將描述后的數(shù)據(jù)通過引擎 API 注冊后，在編輯器中使用。
• 編排，本質(zhì)上來講，就是不斷在生成符合《搭建協(xié)議》的頁面描述，將編輯器中的所有物料，進行布局設置、組件 CRUD 操作、以及 JS/CSS編寫/邏輯編排等，最終轉(zhuǎn)換成頁面描述，技術細節(jié)待會兒我們再展開講講。
• 渲染，顧名思義，就是將編排生成的頁面描述結構渲染成視圖的過程，視圖是面向用戶的，所以必須處理好內(nèi)部數(shù)據(jù)流、生命周期、事件綁定、國際化等。
• 出碼，就是將頁面描述的結構解析和轉(zhuǎn)換成應用代碼的機制。

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

前面說過，編排的本質(zhì)是不斷生成符合《搭建協(xié)議》的頁面描述的過程，然后通過渲染器將頁面描述渲染成真正的視圖。

協(xié)議是文本協(xié)議，是一個 json 結構，理論上手寫也能完成，但是考慮到可編程性，我們設計了一套節(jié)點和屬性模型，類似于 DOM，這樣操作節(jié)點 配置屬性就等價于在操作頁面描述，也就是操作 json 結構了。

除了節(jié)點模型和屬性模型之外，上層還有文檔&項目模型，對于物料的管理，有物料注冊機制和物料模型，另外我們提供了通用的面板管理、拖拽引擎、resize引擎，設計器輔助層、原地編輯、快捷鍵等二十幾個模塊，這里就不細說了。
而這所有的模塊的能力，也就是 API，都通過插件進行調(diào)用，于是插件成為了擴展編輯器的唯一載體。你可以定制你的面板，可以操作節(jié)點樹，可以定制節(jié)點的擴展操作，可以去操作物料模型，可以去綁定快捷鍵，可以設定畫布大小，可以定制拖拽行為等等。

再來聊聊出碼，對于一些常規(guī)場景，直接由渲染模塊渲染即可。但是考慮到一些特殊情況，比如一些不支持動態(tài)化的場景，小程序，或者為了更好的性能，轉(zhuǎn)碼成 ProCode 打包部署，或者需要二次開發(fā)，因此，我們設計了出碼框架。出碼框架提供一套流水線式的處理流程，類似 babel 的機制，通過一個個的出碼插件 / preset 來定制你的出碼產(chǎn)物，市面上的 react 框架、vue 框架、小程序框架都可以支持。

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

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

我們具象化一點來看引擎生態(tài)，這是一個標準的中后臺設計器頁面。藍色部分是插件，這些都是能被看到的插件，因為調(diào)用的是面板 API，不僅如此，還有一些不能被看到，比如調(diào)用了快捷鍵 API，拖拽 API、事件 API 等。紅色部分就是設置器了，可以定制我們?nèi)绾谓o一個節(jié)點的屬性賦值。橙色部分就是物料了，其實物料本質(zhì)上是一個模型，也是不可見的，不過這里通過物料面板調(diào)用了物料 API 來顯性化展示了物料，再通過拖拽 API 和 節(jié)點 API 來拖拽并插入到畫布中。

豐富的生態(tài)，讓快速、低成本打造低代碼平臺成為可能。我們有物料生態(tài)、設置器生態(tài)、插件生態(tài)，因此，我們推導出一個簡單的公式，打造低代碼的設計器等價于引擎 選擇物料 選擇設置器 選擇插件。

再來聊聊我們?nèi)绾?strong>通過協(xié)議來支持多技術棧。不管是《阿里巴巴中后臺前端搭建協(xié)議規(guī)范》，還是《阿里巴巴中后臺前端物料規(guī)范》，都是與語言無關的。你定義一套物料描述，而具體實現(xiàn)可以是 react / vue 或者任何技術棧，而對于搭建頁面，你可以在設計態(tài)用 react 組件，渲染時也用 react 組件，但注意，因為設計和渲染的中間產(chǎn)物頁面描述也是語言無關的，所以渲染時可以是任意語言，可以是 react，可以是 vue，當然也可以是小程序。

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

再來聊聊編排和渲染的雙層架構設計，通過這個架構，我們實現(xiàn)了絕對純凈的編輯態(tài)渲染，即模擬器實現(xiàn)。

這個圖相信大家都很熟悉，編輯器中內(nèi)嵌一個所見即所得的渲染模塊，但這會有一個問題，css 污染的問題，因為編輯器中各個模塊，物料、設置器、插件都來自不同的團隊，很容易產(chǎn)生 css 污染。編輯器中的元素互相污染問題都不算太大，但是污染了渲染視圖就很嚴重了，大家可以思考下為什么？

我們的解法是將模擬器放入到一個新的 iframe 中運行，通過編輯器將相關資源注入到模擬器，建立數(shù)據(jù)通道，使用 facade 模式，即在編輯器和模擬器中各有一個 facade 對象來負責對外的方法暴露和調(diào)用，避免深度耦合。

低代碼引擎通過協(xié)議先行，最小內(nèi)核，最強生態(tài)的理念，形成了 4 大模塊以及生態(tài)擴展性的整體設計，在靈活性上足以支撐各種類型低代碼平臺。

但是，大家此時可能會有些疑問，這引擎 生態(tài)的組合似乎還是偏底層，離一個真正生產(chǎn)可用的低代碼平臺有點距離。比如：

1. 搭建出來的頁面描述保存到哪里去？
2. 搭建完成后，產(chǎn)物打包系統(tǒng)哪家強？
3. 頁面多人編輯沖突如何解決？
4. 研發(fā)流程如何定義？
5. 版本管理，多分支咋搞？
6. 頁面區(qū)塊 / 低代碼組件 怎么搭建？怎么使用？

這里的問題可以列出上百個，因為這都是我們遇到并已經(jīng)解決的問題。

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

1. 解決產(chǎn)品能力的問題，實現(xiàn)了應用管理、研發(fā)流程、打包流程、發(fā)布流程 等一系列能力
2. 解決快速在找到符合需求的生態(tài)元素組合

我們來看看它包含哪些能力以及支持哪些定制化：

• 設計器：提供一個開箱即用的標準版頁面設計器，開箱即用意味著整合了一批插件，插件都已經(jīng)跟后端服務相綁定了；提供簡單版、進階版設計器定制方案。
• 運行時：提供穩(wěn)定的，功能豐富的運行時 SDK，包括頁面描述的獲取、路由、layout，甚至還有一套運行時中間件機制
• 生態(tài)：提供「生態(tài)中心」，大量組件、插件、解決方案唾手可得；提供「一站式研發(fā)平臺」，可開發(fā)、調(diào)試低代碼領域的所有物料
• 管理后臺：提供功能完善、方便定制的管理后臺模板應用，包括研發(fā)流程、應用依賴管理、打包配置、路由配置等
• 后端服務：官方提供 140 網(wǎng)關接口，覆蓋設計器、運行時、管理后臺等全流程；允許上層平臺注冊服務到 UIPaaS，供其他平臺使用。

第三部分 – 存異：百花齊放的低代碼平臺

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

總結了一下目前我們打造的垂直類平臺，有耳熟能詳?shù)闹泻笈_，有運營場景，數(shù)據(jù)報表類場景，還有以設計類為代表的角色協(xié)同、產(chǎn)物互通的平臺，還有移動應用、IoT、aPaaS 等類型。

平臺很多，因為各種原因沒法一一展示，這里我們來看幾個典型的平臺：
這是一個中后臺平臺，功能包含頁面大綱樹、組件面板、源碼面板、國際化、模型編排等核心能力，以及打包系統(tǒng)、研發(fā)管理等模塊。

這是一個數(shù)據(jù)報表類的平臺，會對圖表庫、數(shù)據(jù)模塊、賬號權限體系、設置器等做深度定制。

這是一個小程序編排平臺，核心是接入一套小程序的組件，定制一些小程序特有的配置，以及對接各個發(fā)布渠道。

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

彩蛋 – 協(xié)議對外開放 & 低代碼引擎開源

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

跟大家介紹一下低代碼引擎在阿里的發(fā)展史，大家注意，我將協(xié)議起草這個節(jié)點標注成了橙色，因為這個節(jié)點代表了整個集團從分兵作戰(zhàn)轉(zhuǎn)成集團軍作戰(zhàn)的關鍵里程碑。之后的協(xié)議發(fā)布、集團引擎、UIPaaS 等各個節(jié)點也就順理成章了~

低代碼協(xié)議和低代碼引擎經(jīng)過了近3年在阿里內(nèi)部不斷捶打和磨練，在生態(tài)建設以及平臺支撐上都取得了不錯的成績。后續(xù)我們會將其開源，讓大家共享這套低代碼基礎設施，繼續(xù)接受社會的捶打和磨練

謝謝大家~