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

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

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

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

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

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

第一部分 – 低代碼體系的架構(gòu)設(shè)計思考

好啦，先跟大家聊聊「低代碼體系的架構(gòu)設(shè)計思考」。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是，大家此時可能會有些疑問，這引擎 生態(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)了應(yīng)用管理、研發(fā)流程、打包流程、發(fā)布流程 等一系列能力
2. 解決快速在找到符合需求的生態(tài)元素組合

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

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

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

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

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

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

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

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

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

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

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

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

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

謝謝大家~