欧美一区二区九九,夜夜高潮夜夜爽夜夜爱

作者 | 莫春輝

本文整理自華為云主任工程師莫春輝在 GMTC 全球大前端技術大會（深圳站）2021 的演講《多技術棧及高低代碼混合開發(fā)——華為云低代碼平臺架構探討》。

當前，華為云部門內部的前端技術棧并不統(tǒng)一，比如華為云官網的 Console 控制臺使用 Angular 技術棧開發(fā)，其他內部 IT 系統(tǒng)使 Vue 技術棧開發(fā)。因此，華為云要建設一套低代碼搭建平臺，對內提效能要同時兼顧 Angular 和 Vue 兩種技術棧，對外建生態(tài)則要同時支持 Vue 和 React 技術棧。

另外，目前業(yè)界的低代碼搭建平臺大多局限于簡單的應用開發(fā)，而華為云自身的業(yè)務邏輯中，既有需要用高代碼開發(fā)的復雜頁面，又存在一些簡單頁面。這些復雜頁面，你很難完全通過可視化拖拽搭建出來，但對于簡單的頁面，又希望能夠使用可視化拖拽快速生成。因此，支持高低代碼混合開發(fā)的需求就擺在了我們的眼前。

華為云低代碼平臺建設背景與訴求

華為云低代碼平臺的建設背景

在 Gartner 的定義中，低代碼平臺被稱為企業(yè)級低代碼應用平臺，是支持快速應用開發(fā)，使用陳述性、高級的編程抽象（如基于模型驅動和元數(shù)據(jù)編程語言）實現(xiàn)一站式應用部署、執(zhí)行和管理的應用平臺。不同于傳統(tǒng)的應用平臺，它支持用戶界面、業(yè)務邏輯和數(shù)據(jù)服務的開發(fā)，并以犧牲跨平臺的可移植性、應用開放性為代價來提高生產效率。

正因為犧牲了跨平臺的可移植性和應用的開放性，各廠商開發(fā)的低代碼平臺，都不約而同地朝著“低”的方向走，越低越好，甚至是無代碼、智能生成代碼，于是就容易忽略“高”的需求，忽略與“高”的結合。而且，各廠商都希望用戶從頭到尾都在自己的平臺上進行開發(fā)、全程托管，于是就容易忽略“被托”的需求，或者說“被集成”的需求，忽略與存量應用的結合。

這種忽略其實也是不得已而為之。如果不犧牲跨平臺可移植性，就有可能支撐不同平臺不同技術棧、生成可移植的代碼，與現(xiàn)有的高代碼（純手寫代碼）相結合；如果不犧牲應用開放性，就有可能更好地支撐被集成的需求，靈活地與存量應用相結合。事實上，企業(yè)內部有非常多的存量應用，這些存量應用也想通過低代碼平臺去提升開發(fā)效率。

目前華為內部已經有幾套低代碼平臺，華為云的低代碼平臺是否存在重復造輪子的嫌疑？2021 年 7 月北京的 GMTC 大會上，阿里巴巴研究員玉伯在談前端現(xiàn)狀的時候說到：阿里內部的低代碼平臺也很多，但深入到業(yè)務層面去看，你就會發(fā)現(xiàn)，那些“輪子”都是合理的，它確實是在解決特定領域的特定問題。華為云低代碼平臺的建設初衷，就是用來解決華為云領域內部的存量應用想通過低代碼平臺提升開發(fā)效率的問題。

如何在盡量不犧牲跨平臺可移植性、盡量不犧牲應用開放性的情況下建設華為云低代碼平臺？這就是本文要探討的問題。以下內容，我們將華為云領域存量應用的業(yè)務需求為線索，分析這些業(yè)務需求背后的實質問題，討論用什么樣的技術方案去應對這些問題，以及用什么樣的平臺架構去承載技術方案，最后講講建設過程中我們所踩過的坑。

華為云 CRM 系統(tǒng)的低代碼需求分析

華為云內部有一個 CRM 客戶關系管理系統(tǒng)，這個系統(tǒng)已經開發(fā)完成并且上線運行，屬于存量應用。由于后面不斷有新的需求，需要開發(fā)新的頁面，而那些新的頁面又跟原來的頁面非常相似，所以重復性的開發(fā)工作比較多，于是 CRM 的開發(fā)人員就想利用低代碼平臺來搭建新頁面。

由于新的頁面跟原來的頁面非常相似，CRM 的需求其實是想將原來的頁面封裝成可配置的頁面模板。這樣在面對新需求時，只需在低代碼平臺里配置一下頁面模板就能產生新的頁面，不用再重復開發(fā)。可配置的頁面模板也是由 CRM 開發(fā)人員在低代碼平臺搭建而成，而產生的新頁面則必須提供源代碼，以便與 CRM 原系統(tǒng)一起編譯構建，組成一個完整的應用，如下圖所示：

左圖是開發(fā)人員日常使用的 IDE（Visual Studio Code），低代碼平臺作為 IDE 的插件嵌入到 IDE 里。開發(fā)人員在平臺里通過可視化方式搭建頁面，保存頁面的時候平臺會生成頁面的源代碼（中圖），與原來純手寫的代碼一起編譯生成應用（右圖）。這里的可視化搭建相當于部分代替了原本需要手寫代碼的工作。

CRM 低代碼需求背后的實質問題，其實是 ProCode 與 LowCode 的混合開發(fā)。ProCode 就是我們傳統(tǒng)意義上的高代碼開發(fā)，即所有代碼都是純手寫的，而 LowCode 就是借助可視化工具搭建頁面，只需編寫少量代碼。所謂的高低代碼混合開發(fā)就是：在本地 IDE 里，有些場景直接手寫代碼，有些場景則用可視化工具搭建，生成代碼到本地工程?；旌祥_發(fā)的目的，仍然是想充分利用低代碼平臺的能力，提高開發(fā)階段的生產效率。

華為云 DevOps 系統(tǒng)的低代碼需求分析

再來看一下華為云另一個領域的低代碼需求，這個需求來自 DevOps 系統(tǒng)。在 DevOps 流水線上，我們允許用戶添加自定義的插件，這個插件能讓用戶干預構建和部署過程。

在使用插件前，需要通過一些頁面來配置插件的參數(shù)，而這些頁面當前是由 DevOps 團隊開發(fā)。為了減輕團隊的負擔，他們希望借助低代碼平臺的能力，讓用戶在 DevOps 網站上直接搭建頁面，頁面保存后同樣生成源代碼，集成到 DevOps 系統(tǒng)里。這個需求與 CRM 不同之處有三點：

目標用戶不同

CRM 是 CRM 系統(tǒng)的開發(fā)人員使用低代碼平臺搭建系統(tǒng)頁面，DevOps 則是 DevOps 系統(tǒng)的用戶使用低代碼平臺搭建插件配置頁面。

嵌入方式不同

CRM 是在 IDE 里嵌入低代碼平臺，屬于線下開發(fā)。DevOps 則是在 DevOps 網站上嵌入低代碼平臺，屬于線上開發(fā)。

技術棧不同

CRM 采用 Angular 技術棧，DevOps 采用 Vue 技術棧。所以在 CRM 低代碼平臺搭建頁面所用的組件，必須是 CRM 系統(tǒng)當前使用的 Angular 組件，而 DevOps 則是 Vue 組件。CRM 低代碼平臺生成的源代碼，必須是 Angular 技術棧，而 DevOps 則是 Vue 技術棧。如下圖所示：

如果僅僅是生成不同技術棧的源碼，相信很多低代碼平臺都能做到，但是我們面對的是不同技術棧的組件。比如一個按鈕，CRM 是用 Angular 開發(fā)的，DevOps 是用 Vue 開發(fā)的。兩個技術棧開發(fā)的按鈕，它們的屬性、方法、事件，甚至功能都不一定相同。打個比方，我們要給這個按鈕設置顏色，Angular 的屬性名稱叫 type，屬性的值是 success，而 Vue 的屬性名稱叫 color，屬性的值是 green，兩者并不匹配，如下圖所示：

所以，用 Angular 組件搭建的頁面，生成的 Vue 源碼是跑不通的。有些人可能會說，通過 DSL 做屬性映射，但是，如果功能不同，用 DSL 也無濟于事。那么，我們是不是我們要為不同技術棧，不同領域打造不同的低代碼平臺呢？

如果這樣做了，我們的成本會非常高，這個成本不僅包括軟硬件資源的投入，還包括研發(fā)和運維的投入。而且各技術棧的低代碼物料的不通用，還會造成物料生態(tài)的割裂。因此我們的低代碼平臺方案要能夠支持不同的技術棧。

與傳統(tǒng) Visual Studio 可視化 IDE 的區(qū)別

把低代碼平臺嵌入到 IDE 里，通過可視化搭建生成源代碼，這與 20 年前流行的 Delphi/ C++ Builder/ J Builder/ Visual Studio 非常類似，當然這些工具今天也還有人在用。

如下圖所示的 Visual Studio，左邊是可以拖拽的組件，中間上方是畫布，左邊的組件可以拖到畫布里，中間下方是代碼編輯區(qū)域，右邊是文件系統(tǒng)以及組件的屬性配置面板?？梢?，雖然技術在向前演進，但是解決問題的思路又回到了原點。

兩者的相同點不難看出，都是可視化搭建，都會生成源代碼。要厘清兩者的區(qū)別，我們從以下三個維度去探討：

適用人群

低代碼平臺面向的人群，通常是不太懂編程的業(yè)務人員，或者能在幫助文檔下寫一點簡單的業(yè)務邏輯代碼，可視化搭建是他們的主要工作，寫少量的代碼只是輔助工作。在高低代碼混合開發(fā)的方案里，適用人群可分為兩類，一類是不太懂編程的業(yè)務人員，主要負責業(yè)務頁面的搭建，另一類是傳統(tǒng)的專業(yè)編程人員，主要負責業(yè)務邏輯的編寫，兩者協(xié)同開發(fā)一個應用。Visual Studio 面向的是單一人群，即專業(yè)編程的開發(fā)人員，可視化拖拽組件只起到輔助作用，大部分時間他們都在編寫和調試代碼，獨立完成一個應用的開發(fā)。

開發(fā)語言

低代碼平臺本身與開發(fā)語言無關，即便在平臺上寫的少量代碼，也是前端通用的 JavaScript 語言。在高低代碼混合開發(fā)的方案里，不太懂編程的業(yè)務人員可能需要掌握 JavaScript 語言，用來編寫小部分的業(yè)務邏輯。另外，由于本文的低代碼方案可以生成不同技術棧的源代碼，所以專業(yè)編程人員需要掌握 Angular 或 Vue 等前端開發(fā)框架，才能調用低代碼平臺生成的源碼。Visual Studio 的可視化工具與 IDE 本身是天然集成的，一個子產品只支持一種開發(fā)語言，比如 Visual Basic 等。由于主流的前端框架并無統(tǒng)一的組件庫，Visual Studio 系列也就沒有諸如 Visual Angular 或 Visual Vue 的子產品，市面上也沒有類似成熟的面向前端框架開發(fā)的可視化 IDE，所以低代碼平臺的可視化搭建工具正好彌補這一空缺。

協(xié)同開發(fā)

這是高低代碼混合開發(fā)的方案特有的，Visual Studio 并不存在這種情況。因為低代碼平臺雖然嵌入到 IDE 里，但仍然是獨立于 IDE 的模塊，其生成的源代碼需要跟本地純手寫的代碼協(xié)同工作，才能達成混合開發(fā)的目標。協(xié)同的方式按模塊顆粒度分為兩種：一種是頁面級別，另一種是組件級別。頁面級別是指平臺生成的源代碼本身是一個頁面，本地工程通過路由直接跳轉到該頁面即可。這種級別與高代碼部分耦合度最小，也最容易集成。組件級別是指平臺生成的源代碼只是頁面的一個組成部分，需要跟頁面的其他純手寫的部分相互通訊、協(xié)調運行。這種級別與高代碼部分耦合度非常大，但卻是混合開發(fā)的普遍場景，為此我們引入橋接源來解決協(xié)同開發(fā)的問題。

讓業(yè)務人員參與低代碼平臺開發(fā)

厘清兩者的區(qū)別之后，有人可能會指出：為什么讓業(yè)務人員參與混合開發(fā)，全部由專業(yè)編程人員不行嗎？為什么要高低代碼混合開發(fā)？把開發(fā)流程復雜化，增加學習成本。有些人甚至還指出：LowCode 是行業(yè)毒瘤，它沒有任何未來，不值得我們任何的投資和想法。讓不懂軟件開發(fā)的人可以寫代碼，這個想法就是錯的，而且錯的非常離譜。我們從以下兩個方面來回應這些問題和說法：

數(shù)字化轉型需要業(yè)務人員參與

在企業(yè)數(shù)字化轉型的大背景下，應用軟件呈爆炸式增長，開發(fā)應用所需的專業(yè)人員或者供不應求或者成本太高。于是降低開發(fā)門檻，讓懂業(yè)務的人員直接參與應用構建，就成了低代碼平臺的發(fā)展機遇。對于企業(yè)的存量應用，仍然需要面對快速變化的業(yè)務需求，但這些應用很難直接拋棄另起爐灶，改用低代碼平臺重新構建。在專業(yè)編程人力不足的情況下，或者站在提高研發(fā)效率、降低維護成本的角度上考慮，都希望讓了解業(yè)務需求的業(yè)務人員能直接參與進來，與專業(yè)編程人員一起更新這些存量的應用。

低代碼平臺本質上仍然是軟件開發(fā)工具

低代碼是一種軟件開發(fā)技術，屬于軟件開發(fā)的高級語言。低代碼開發(fā)平臺通常整合了軟件開發(fā)所需的 IDE，有些還覆蓋軟件開發(fā)的全生命周期，提供數(shù)據(jù)建模與流程編排的能力，提供編程接口與系統(tǒng)集成的能力等。因此，低代碼與其他軟件開發(fā)技術一樣，值得我們投資和發(fā)展。低代碼開發(fā)平臺有自己專屬的開發(fā)語言，本身也能夠獨立完成應用開發(fā)，當要與傳統(tǒng)的純代碼開發(fā)方式融合時，必然存在兩種開發(fā)語言的磨合。這種磨合是有成本的，但成本是可控的，特別是低代碼平臺直接生成源代碼，能極大方便本地調試與快速排查問題。

本文我們所討論的華為云低代碼平臺，不同于市面上常見的低代碼平臺，它不僅僅可以實現(xiàn)簡單的增刪改查頁面，還能支持復雜的 CRM 系統(tǒng)頁面開發(fā)，還能生成 CRM 和 DevOps 不同技術棧的源代碼，并與原 CRM 和 DevOps 系統(tǒng)編譯集成。此外，它讓不懂編程的業(yè)務人員，與專業(yè)的開發(fā)人員一起協(xié)同工作，每個人負責各自擅長的部分，使得低代碼平臺能夠適應更多的業(yè)務場景，覆蓋更多的行業(yè)領域，進一步拓展了低代碼開發(fā)平臺的邊界。

支持多技術棧與高低代碼混合開發(fā)

前面描述的 CRM 和 DevOps 系統(tǒng)的低代碼需求，除了高低代碼混合與支持多技術棧外，還有搭建復雜頁面的場景。企業(yè)級的 CRM 客戶關系管理系統(tǒng)，如果不能像 Salesforce 一樣，把客戶關系管理系統(tǒng)都做透，通過配置化實現(xiàn)客戶側的定制，那么低代碼平臺很難通過可視化搭建，構建復雜的 CRM 系統(tǒng)頁面。這也是大多數(shù)低代碼平臺為什么只專注于簡單的增刪改查頁面、或者流程審批電子流的原因。

然而這些問題如果沒有解決，那代碼混合開發(fā)就無從談起。企業(yè)內部的存量應用，不會因為你做不到就簡化頁面，畢竟業(yè)務邏輯的復雜度本身就無法忽視。

如何可視化搭建復雜的 CRM 系統(tǒng)頁面

這個問題我們給出的解決方案是：為用戶提供自助搭建可復用區(qū)塊的能力。

什么是區(qū)塊？我們來看下面這張圖，一個頁面通常由多個區(qū)塊拼接而成，每個區(qū)塊由一到多個業(yè)務組件構成，每個業(yè)務組件都由基礎組件實現(xiàn)。在低代碼平臺里，基礎組件和業(yè)務組件都屬于原子組件，即不可拆分的、平臺內置的、可以拖到畫布用于搭建區(qū)塊的組件。一個復雜的頁面通?？梢圆鸱殖扇舾蓚€區(qū)塊，而區(qū)塊里面也可以嵌套區(qū)塊。只要讓用戶能夠復用已搭建好的區(qū)塊，復雜的頁面就像搭積木一樣，一層層摞起來即可。

我們用低代碼平臺搭建的頁面，會有一個描述頁面信息的文件，這個文件我們稱為頁面 Schema。如下圖左邊所示，可以看到這個頁面只包含兩個組件，一個是 Button，另一個是 Input。如果我們認為這個頁面可以復用，我們就把它轉為區(qū)塊，這時候該區(qū)塊可以理解為：可配置的頁面。所以只需在頁面的 Schema 里面，增加區(qū)塊可配置的屬性，它就變成了描述區(qū)塊的 Schema。如下圖右邊所示，該區(qū)塊暴露了兩個配置項：buttonSize 和 inputSize，分別對應頁面包含的 Button 組件和 Input 組件的屬性。

以下這張圖展示了低代碼區(qū)塊的創(chuàng)建和消費過程。首先，從新建空白畫布開始，用戶在畫布上拖拽組件、搭建區(qū)塊，接著添加區(qū)塊的業(yè)務邏輯。這里需要說明的是，我們提供了一些橋接方法，讓用戶可以調用高代碼的部分功能，即前面提到的高低代碼混合開發(fā)時，需要跟頁面的其他純手寫的部分相互通訊、協(xié)調運行。第四步就是保存區(qū)塊，讓用戶選擇暴露的配置項，即將區(qū)塊里所有組件的所有屬性都羅列出來，讓用戶選擇哪些屬性可以對外暴露，以便復用的時候進行配置。第五步是發(fā)布區(qū)塊到物料中心，這樣下次新建頁面的時候，用戶就可以將這個區(qū)塊拖到畫布上，重復使用。

另外，由于我們的頁面和區(qū)塊都會生成源代碼。如果兩個頁面都用到同一個區(qū)塊，只是區(qū)塊的配置有所不同，那么在生成這兩個頁面源碼的同時，我們只會生成一份區(qū)塊源碼，然后讓這兩個頁面都引用這個相同的區(qū)塊。

如何在畫布里展現(xiàn)不同技術棧的 UI 組件

目前大多數(shù)的低代碼平臺為了方便實現(xiàn)，都會限定畫布只支持一種技術棧，甚至一套組件庫。因為沒有為用戶提供頁面源代碼的需求，搭建出來的頁面也不需要被其他系統(tǒng)集成，所以沒必要考慮多技術棧，用一套組件庫實現(xiàn)的成本是最低的。但是在華為云領域，面對 CRM 和 DevOps 的需求，我們要解決一個問題：如何在畫布里展現(xiàn)不同技術棧的 UI 組件？這個問題我們給出的解決方案是——使用 Web Component 技術。

上圖是 InfoQ 2020 年一季度，Web 開發(fā)相關的語言、標準、模式趨勢圖?？梢钥吹?Web Component 處于中間位置，說明它已經到了主流成熟階段，我們可以使用 Web Component 來解決跨技術棧問題。

目前三大主流前端框架：Angular、React、Vue 都已經提供官方的 Web Component 轉換工具，我們利用這些轉換工具，就可以輕松的將各技術棧的 UI 組件，全部包裹成 Web Component，然后當做 HTML 原生組件顯示到畫布上。需要指出的是，在生成的代碼里，我們引用的仍然是原始的 UI 組件，而不是 Web Component，這是因為畫布是設計態(tài)，源碼是運行態(tài)，兩者是不同的。

當前 Angular、React、Vue 是三大主流前端框架，未來又會出現(xiàn)什么樣的框架代替它們呢？我們不得而知。但是，不管未來的前端框架如何變化，我們都先用 Web Component 技術收斂，再通過 DSL（Domain Specific Language）機制發(fā)散，生成不同框架不同技術棧的源碼，這就是我們低代碼平臺的演進策略：

我們來舉個 Vue 的例子說明 Web Component 方案。首先按照 Vue 官方的示例，定義一個 Vue 的組件，并注冊成為 Web Component。然后在畫布的 HTML 代碼里，我們聲明該 Web Component。假設這個 Vue 組件暴露的 options 屬性，是數(shù)組類型。我們知道，在 HTML 標簽上，attribute 屬性只能設置為字符串或數(shù)值類型，因此，我們需要通過 JavaScript 腳本動態(tài)設置 options 的屬性值。如下圖所示：

接下來，我們將畫布的 HTML 內容，用 AST 抽象語法樹，解析成一個 JSON 對象，即描述頁面的 Schema。從下面左側的圖可以看到，Web Component 組件的 options 屬性，它仍然是數(shù)組類型。然后我們通過 DSL 將頁面描述 Schema 轉換成 Vue 的源碼。從下面右側的圖可以看到，Vue 組件的 options 屬性，也仍舊是數(shù)組類型。于是我們發(fā)現(xiàn)，從 Web Component 封裝組件開始，到生成 Vue 的源碼，整個過程中，給組件屬性設置的值是可以透傳的。

講到這里，大家可能會有疑問，為什么不能在 Vue 應用中，直接使用 Web Component？以下列出 5 個理由，都摘自 Vue 的官網。簡而言之，就是 Web Component 技術還不夠強大，還不能完全替代現(xiàn)有的主流前端框架。

我們需要一個聲明式的、高效的模板系統(tǒng)
我們需要一個有助于跨組件邏輯提取和重用的響應式狀態(tài)管理系統(tǒng)
我們需要一個能在服務器端渲染組件并在客戶端集成的高效方法
原生插槽沒有 Vue 的作用域插槽提供的組件整合機制
隱式 DOM scoped CSS 的自定義元素需要將 CSS 嵌入到 JS 中

生成源代碼 VS 運行時渲染

要將畫布的描述生成不同技術棧的源碼，需要借助 DSL 機制。我們知道，用可視化方式搭建頁面，這個屬于設計態(tài)。將頁面描述文件通過 DSL 轉換成源代碼，然后編譯成可以運行的應用，這個屬于運行態(tài)?？梢赃@么說，DSL 的作用就是將低代碼從設計態(tài)轉換成運行態(tài)。

但是，并不是所有低代碼平臺都會采用生成源碼的方案。事實上，有很多低代碼平臺采用的是運行時渲染的方案，即將頁面描述文件直接傳給運行時解析引擎，然后動態(tài)地渲染頁面。兩種方案各有所長，這里列出四個對比項，如下圖所示：

第一項，從性能上來看，運行時渲染要用到解析引擎，這個肯定不如生成源碼編譯跑的快；

第二項，由于運行時渲染一般要求所有應用都用統(tǒng)一的解析引擎，因此升級和修復平臺問題時，只需針對統(tǒng)一的解析引擎，其效率自然要高于每個應用的源碼都需要重新編譯的方式；

第三項，DSL 生成源碼天然具有很高的靈活性，只要用戶通過自定義 DSL，就能生成任意想要的源碼，因此擴展性和開放性要比運行時渲染高；

第四項，開發(fā)和運維的成本，兩者應該相差不大。

低代碼平臺架構開發(fā)及生態(tài)建設思路

低代碼平臺架構設計

下圖是我們低代碼平臺架構設計圖。先看底部的平臺服務，我們會利用華為云原生的能力搭建后端服務，會跟華為云的業(yè)務集成互通，比如跟我們的 Console 控制臺業(yè)務集成等。中間這塊是我們搭建平臺的核心，底層能力提供搭建頁面所需的基礎組件、移動組件和業(yè)務組件，提供頁面運行用到的邏輯編排、流程編排。

往上一層是我們用來粘合各個模塊的平臺協(xié)議，這個頁面搭建協(xié)議是用來描述頁面信息的，而組件描述協(xié)議是用來給組件設置屬性的，物料資產協(xié)議是用來描述平臺用到的組件、區(qū)塊以及技術棧等信息，DSL 轉換協(xié)議則是用來將頁面或區(qū)塊 Schema 轉換成各技術棧的源代碼。

低代碼設計器是我們核心中的核心。首先從導入物料開始，中間是設計器的各個模塊，這些模塊會接入我們的平臺擴展生態(tài)，包括設計器的插件生態(tài)，以及組件和區(qū)塊生態(tài)。最后，設計器還要負責生成源代碼，適配多終端多技術棧。再看上圖右下角，我們?yōu)榱藢崿F(xiàn)設計開發(fā)一體化，會提供在線設計平臺、提供支持高低代碼混合開發(fā)的 VSCode 插件。

平臺管理中心包含很多個中心，我們會先在物料中心挑選物料，然后打成物料資產包，再到平臺中心選擇剛打好的物料資產包，用來構建各領域的平臺，接著在應用中心管理各領域平臺生成的應用。PaaS 平臺服務就是支撐我們去構建定制的平臺，提供平臺的運行時服務，另外還要支撐應用的設計、開發(fā)、構建、部署等。

有了 PaaS 平臺之后，我們就可以提供 SaaS 能力，既可以開發(fā)傳統(tǒng)的中后臺應用，也開發(fā)華為云的 Console 控制臺應用，甚至包括我們的 WeLink 移動端應用、鴻蒙的多端應用，然后再將這些應用發(fā)布到我們的應用生態(tài)市場。

低代碼平臺工作流程

下圖是我們的低代碼平臺工作流程。先從底部的低代碼后端說起，可以看到包含了前面說的物料中心、平臺中心以及應用中心，這三個中心的后端都會連接一個數(shù)據(jù)中心，再由數(shù)據(jù)中心連接數(shù)據(jù)庫。平臺中心構建出來的產物是低代碼平臺實例，VSCode 模塊根據(jù)模板工程把這個低代碼平臺實例打包編譯，構建出一個 VSCode 插件。

物料中心會構建出兩個產物，分別是物料資產包，以及搭建頁面所需的組件庫，它們會被低代碼平臺實例動態(tài)加載。每個平臺實例都是由設計器各個模塊組裝而成，這些設計器的模塊都來源于 npm 倉庫。每個平臺的實例都會請求對應的平臺服務，平臺服務提供各技術棧的頁面預覽功能，并且將生成的代碼提交到 Git 庫，再通過流水線發(fā)布應用。

低代碼組件及區(qū)塊構建流程

接下來我們看一下，物料中心的兩個產物，物料資產包和組件庫，它們是如何構建的。如下圖所示，首先在物料中心的前端頁面，我們點擊構建組件和區(qū)塊的按鈕，后端服務就會分別執(zhí)行構建動作。先看左邊的組件構建流程，我們會根據(jù)用戶選擇的技術棧，安裝相應的 Web Component 組件庫，接著生成構建代碼，代碼里引入用戶選擇的組件，并且按照物料資產協(xié)議，輸出該組件的描述信息，最后用 Rollup 打包構建，生成組件庫。

再來看右邊的區(qū)塊構建流程，我們先從數(shù)據(jù)中心里獲取區(qū)塊的 Schema，然后將 Schema 轉成區(qū)塊的描述信息，所有區(qū)塊的描述信息都會插入到 material.config 文件里，這個文件是按照物料資產協(xié)議進行整理，包含平臺用到的組件、區(qū)塊以及技術棧等信息，這個文件最后被打到物料資產包里，并且保存到數(shù)據(jù)中心。

低代碼平臺項目開發(fā)流程

下圖我們低代碼平臺的項目開發(fā)流程。流程分三個角色，首先由項目經理在平臺中心新建一個項目，然后設置可視化設計器的默認配置，比如設計器用什么樣的主題，是深色還是淺色主題、設計器的面板有哪些插件、工具欄上有哪些按鈕等。接著設置平臺的默認配置，比如使用自定義的 DSL 配置、設置代碼倉庫的地址、監(jiān)控應用所需的埋點信息等，下一步是設置項目所用的物料，比如用什么技術棧的組件、用什么領域的區(qū)塊及模板。最后，項目經理點擊構建平臺的按鈕，等平臺生成后，就會通知開發(fā)人員登錄平臺網址，或者安裝 VSCode 插件。

開發(fā)人員可以在平臺上創(chuàng)建低碼或無碼應用。如果是低碼應用，則可以創(chuàng)建分支，支持多人協(xié)作；如果是無碼應用，只需選擇模板，做一些簡單的配置。經過一系列的迭代開發(fā)，用可視化工具搭建完頁面，平臺就可以通過 DSL 生成代碼，最后用流水線部署應用。在開發(fā)過程中，如果發(fā)現(xiàn)組件缺失，還可以通過專業(yè)前端開發(fā)相應的組件，然后作為源碼物料導入到物料中心。另外，由于用戶也可以自行搭建可復用的區(qū)塊，將區(qū)塊作為低代碼物料發(fā)布到物料中心，形成物料的雙向流通。

低代碼平臺建設過程中踩過的坑

第一個坑是關于 Vue 的 Web Component 轉換工具，我們使用 Vue3.2 版本推出的轉換工具。當時發(fā)現(xiàn)一個問題，就是 Vue 組件轉換成 Web Component 之后，使用 JavaScript 腳本設置它的 property 屬性，只有第一次設置是生效的，后面再設置是無效的，請注意：這不是 HTML 標簽上的 attribute 屬性。什么原因呢？

我分析了一下 Vue 的源代碼，原來轉換后的 Web Component 只在初始化時讀取 property 屬性，后面并沒有監(jiān)聽 property 屬性的變化。但是低代碼平臺就是要對畫布上的組件進行屬性設置。

于是我就對轉換工具做了點改進，給轉換后的 Web Component 添加了一個方法，把要設置的屬性傳進去，然后調用它內部的 render 方法重新渲染組件，這樣設置就生效了。值得一提的是，我發(fā)現(xiàn) Angular 的 Web Component 轉換工具并沒有這個問題。

第二個坑是關于 VSCode 插件，我們是通過 VSCode 插件來實現(xiàn)高低代碼混合開發(fā)的需求，如下圖所示。

首先把低代碼平臺解耦，然后通過 VSCode 的 WebView 嵌入這個低代碼平臺。接著我們就發(fā)現(xiàn)，平臺通過 WebView 發(fā)送網絡請求的時候，是不能攜帶 Cookie 的，這樣就導致我們的低代碼平臺無法進行鑒權。

我從 VSCode 的 Github 上搜到這個問題的官方回復，他們是這么說的，WebView 沒有 host 主機的概念，它只是在渲染一個 HTML 文檔，并不是你想要訪問的網頁，所以不會有 Cookie 和 LocalStorage 的概念。那我們該怎么辦？

由于 VSCode 它本身自帶 Node.js 客戶端，于是我們就想到，把這個 Node.js 客戶端當做代理服務器，轉發(fā) WebView 的請求。當后端服務返回生成的源代碼后，再借助 Node.js 客戶端將源代碼寫入到本地工程。這樣，就實現(xiàn)了高低代碼混合開發(fā)的基本功能。最后我們還需要在 VSCode 里，實現(xiàn)內置的賬號登錄功能，這樣才能讓請求帶上 Cookie，完成整個平臺的鑒權。

低代碼平臺的相關問答

以下問答系演講結束后根據(jù)聽眾的反饋整理的，選取一些有代表性的問答分享給大家：

對于接口請求渲染數(shù)據(jù)的，這種是如何實現(xiàn)的？

在頁面描述 Schema 里除了描述頁面信息，還有一個 Datasource 對象。Datasource 對象里新建一個數(shù)據(jù)源對象，描述接口請求數(shù)據(jù)的參數(shù)。頁面描述 Schema 通過 DSL 生成代碼時，單獨生成一個數(shù)據(jù)源的 JS 文件。JS 文件里 export 導出一個對象，對象的每個屬性都是一個單獨的數(shù)據(jù)源對象。每個數(shù)據(jù)源對象有 fetch 獲取數(shù)據(jù)等方法，以及其他數(shù)據(jù)源相關配置項。每個 fetch 方法內部是將該數(shù)據(jù)源的參數(shù)傳給統(tǒng)一的獲取后臺數(shù)據(jù)的方法。給每個需渲染數(shù)據(jù)的組件配置數(shù)據(jù)源對象，生成的代碼包含雙向綁定數(shù)據(jù)。在頁面加載的時候，就調用數(shù)據(jù)源對象的 fetch 方法，給雙向綁定的數(shù)據(jù)賦值。

頁面代碼編輯出來后，持續(xù)維護這塊如何考慮的？方案是什么？

通過 DSL 將頁面描述 Schema 生成源代碼，這個過程是單向的。單向意味著生成的源代碼是只讀的，不可以編輯，只能被調用。如果對生成的源代碼改動，后續(xù)保存頁面生成代碼會覆蓋改動。持續(xù)維護還是要走持續(xù)改進和提升頁面搭建能力的方式。高低代碼混合的特點，就是低代碼可以通過橋接方法調用高代碼。用戶在頁面搭建時通過橋接方法，直接調用本地相對路徑的 JS 文件。將包含復雜邏輯等需要經常維護的業(yè)務代碼包含在這些 JS 文件里。低代碼搭建平臺始終主要做頁面、區(qū)塊等 UI 界面的搭建工作。

高低代碼混合開發(fā)中的橋接源可以理解為回調嗎？

低代碼平臺生成的源代碼存放在用戶指定的本地工程專有目錄下，與高代碼部分是隔離的。高代碼可以直接用相對路徑的方式導入或者引用低代碼生成的模塊，而低代碼要導入或者引用高代碼的模塊，則需借助橋接源。比方說，在低代碼平臺里定義一個橋接源，里面聲明高代碼模塊的相對路徑，或者 npm 依賴包的名稱。這樣在低代碼平臺的自定義方法里就可以導入高代碼的模塊或者引用 npm 依賴包。而傳統(tǒng)的低代碼平臺，如果當前提供的 API 接口不能滿足業(yè)務，需引入第三方模塊，一般要先提需求，等開發(fā)完成后重新部署，再告知調用方式，整個鏈路會比較長。

總結和展望

華為云的低代碼平臺要想持續(xù)發(fā)展，就需要建設物料生態(tài)、平臺生態(tài)以及應用生態(tài)。只有物料的雙向流通才能促進物料生態(tài)的發(fā)展，除了組件、區(qū)塊之外，我們還要為用戶提供自助搭建可復用模板的能力，進一步豐富物料的生態(tài)。我們要做低代碼的 PaaS 平臺，利用 Web Component 技術以及 DSL 機制，為不同領域，比如辦公、零售、制造等，去創(chuàng)建定制的平臺。不僅要能夠生成桌面端應用、移動端應用，還要能夠生成鴻蒙的多端應用，擴展我們的應用生態(tài)。

低代碼的物料生態(tài)、平臺生態(tài)、應用生態(tài)，這三者不是互相孤立的，而是相輔相成的。我們要把這三個生態(tài)圈打通，形成合力，這樣下面這張圖，就不是三個圈，而是三個環(huán)環(huán)相扣的 8。

據(jù) Gartner 預計，到 2024 年，低代碼應用開發(fā)將占應用開發(fā)總數(shù)的 65% 以上，將有 3/4 的大型企業(yè)會使用至少 4 個低代碼平臺進行 IT 應用開發(fā)。

另外，據(jù)不完全統(tǒng)計，目前國內外大大小小的低代碼廠商至少有 60 個以上，而且大廠商內部的低代碼平臺可能還不止一個。作為企業(yè)數(shù)字化轉型的工具引擎之一，低代碼平臺必然會被越來越多的企業(yè)所了解并加以使用，使用的場景也會越來越豐富。我們在開發(fā)或使用低代碼平臺時，要清楚低代碼不能一蹴而就，而要持續(xù)迭代、持續(xù)演進，要不斷探索和拓展低代碼開發(fā)平臺的邊界。

作者簡介

莫春輝，華為云主任工程師，華為云 Web 能力中心低代碼平臺負責人，AUI 前端框架負責人。2014 年加入華為，帶領團隊開發(fā) HAE（Huawei Application Engine）前端框架，其底層核心是自研的面向對象的 JS 類架構，支持與 AngularJS 相似的數(shù)據(jù)雙向綁定，可靈活配置的系統(tǒng)、頁面、組件生命周期，以及支撐華為內部 IT 應用的高性能 UI 組件庫。2017 年 HAE 演進成為基于 Vue 的 AUI 框架，并以落實體驗一致性規(guī)范的要求，在公司各 BET 領域大規(guī)模推行，2019 年底發(fā)布了全新架構支持跨端跨框架的 AUI 3.0 版本，2020 年推出同時支持 Vue 2 和 Vue 3 的 AUI 4.0 版本，2021 年開始負責華為云低代碼平臺研發(fā)工作。

除前端框架開發(fā)、低代碼平臺研發(fā)外，還參與制定公司的前端開發(fā)規(guī)范，擔任信息技術任職的評委、JavaScript 認證考試專家組成員，系公司開源能力中心 Vue SIG 組織 Maintainer 成員。

文章轉載自：InfoQ

原文鏈接：https://mp.weixin.qq.com/s/5h2K8ektFD1ZNilCxrRbXA

若有侵權請告知，我們將及時刪除，本文僅供學習交流、我們注重分享，勿作商用，版權歸原作者。

繼續(xù)閱讀：