1 背景介紹

低代碼開(kāi)發(fā)基于可視化開(kāi)發(fā)的概念，結(jié)合了云原生和多終端體驗(yàn)技術(shù)，它可以在大多數(shù)業(yè)務(wù)場(chǎng)景中，幫助企業(yè)顯著的提升效率。同時(shí)為專(zhuān)業(yè)開(kāi)發(fā)者提供了一種全新的高生產(chǎn)力開(kāi)發(fā)方式，讓不懂代碼的人通過(guò)“拖拉拽”開(kāi)發(fā)組件來(lái)完成應(yīng)用程序的構(gòu)建。從某種意義上說(shuō)，低代碼可以彌補(bǔ)日益擴(kuò)大的專(zhuān)業(yè)技術(shù)人才缺口，同時(shí)也可以促進(jìn)企業(yè)與技術(shù)之間深度協(xié)作的最終敏捷形式。

本文以技術(shù)方案視角，對(duì)華為云Astro低代碼平臺(tái)的一些核心功能進(jìn)行簡(jiǎn)要介紹。

2 關(guān)鍵能力介紹

|2.1 數(shù)據(jù)建模和數(shù)據(jù)管理

華為云Astro的一個(gè)核心特性就是運(yùn)行時(shí)提供數(shù)據(jù)建模和與數(shù)據(jù)存儲(chǔ)，幫助開(kāi)發(fā)者做到所見(jiàn)即的的發(fā)布，在其表現(xiàn)形式上，通常低代碼平臺(tái)通常分為”表單驅(qū)動(dòng)”和”模型驅(qū)動(dòng)”兩種模式。不管是哪種模式，都要求低代碼平臺(tái)具備靈活存儲(chǔ)用戶自定義數(shù)據(jù)模型的能力。當(dāng)下主流的低代碼平臺(tái)主要有以下一下兩種大的方案。

方案一：

使用關(guān)系型數(shù)據(jù)庫(kù)，將數(shù)據(jù)模型的定義和修改直接轉(zhuǎn)化為數(shù)據(jù)庫(kù)中DDL的表操作。該方案的優(yōu)勢(shì)在可以直接利用關(guān)系型數(shù)據(jù)庫(kù)的能力，包括SQL優(yōu)化與事務(wù)一致性等。弊端在于有大量的DDL語(yǔ)句操作，并且關(guān)系型數(shù)據(jù)庫(kù)的Schema數(shù)量和表的數(shù)量也都都是有限制的，在成本控制上面臨著較大挑戰(zhàn)。因此該方案適用于一些線下交付，單租形態(tài)的低代碼。

方案二：

Meta+Data的寬表模型，將模型的定義轉(zhuǎn)化為寬表的模型存儲(chǔ)。該方案的優(yōu)勢(shì)在于可以靈活的定義數(shù)據(jù)模型，不需要考慮因模型變化導(dǎo)致的DDL語(yǔ)句。再具體實(shí)踐中，寬表可以有不同的選型，例如文檔數(shù)據(jù)庫(kù)，搜索、分析型數(shù)據(jù)庫(kù)、關(guān)系數(shù)據(jù)庫(kù)等。不同類(lèi)型的存儲(chǔ)的寬表選型面臨著事務(wù)一致性、行列擴(kuò)展限制、索引構(gòu)建不同的挑戰(zhàn)。

|2.2 頁(yè)面編排

頁(yè)面編排是低代碼的核心功能。狹義上的頁(yè)面一般指的是表單表格，廣義上的頁(yè)面還可以包含登錄Portal頁(yè)、大屏頁(yè)等多種樣式。對(duì)于頁(yè)面編排目前實(shí)現(xiàn)方式也基本相同，采用JSON格式的頁(yè)面Schema定義，同時(shí)提供頁(yè)面編排的設(shè)計(jì)引擎和頁(yè)面運(yùn)行時(shí)的渲染引擎。技術(shù)方案基本圍繞Vue與React兩大技術(shù)框架與相關(guān)UI實(shí)現(xiàn)。

在交互邏輯處理方面，頁(yè)面編排基本上采用兩種思路來(lái)處理。

思路一：

固定交互行為，通俗的說(shuō)法就是平臺(tái)預(yù)置的組件與組件的行為方式。所以，組件的多少、組件的能力、組件的擴(kuò)展性也是衡量低代碼平臺(tái)競(jìng)爭(zhēng)力的一個(gè)指標(biāo)。

思路二：

使用擴(kuò)展性腳本語(yǔ)言，JS和TS都是常用的選擇。在代碼中包含循環(huán)、遞歸、變量等抽象操作，這些抽象的邏輯是無(wú)法通過(guò)拖拉編排來(lái)完成的。腳本語(yǔ)言作為低代碼平臺(tái)的膠水部分，在執(zhí)行安全性、沙箱環(huán)境等方面仍然面臨較大挑戰(zhàn)。一份權(quán)威機(jī)構(gòu)的報(bào)告中，編程接口被認(rèn)定為企業(yè)級(jí)低代碼開(kāi)發(fā)平臺(tái)的重要標(biāo)志，不具備編程接口的“低代碼”被劃歸為“無(wú)代碼”，轉(zhuǎn)移到那些只適用有限用例的平臺(tái)報(bào)告中。

|2.3 流程和業(yè)務(wù)邏輯

流程編排是低代碼平臺(tái)的的另一基礎(chǔ)能力。低代碼平臺(tái)能否構(gòu)建出復(fù)雜的流程來(lái)支撐企業(yè)業(yè)務(wù)和流程編排的易用性是衡量流程能力的重要指標(biāo)。

通常我們?cè)僬f(shuō)”流程編排”的時(shí)候，指的是工作流的編排。BPMN2.0的規(guī)范之上，開(kāi)源工作流已經(jīng)具備了非常成熟的能力。業(yè)界的低代碼廠商在實(shí)現(xiàn)工作流的方案商通常有兩種，一是基于開(kāi)源框架擴(kuò)展和封裝，二是基于BPMN2.0規(guī)范來(lái)自己來(lái)實(shí)現(xiàn)。

另個(gè)”流程編排”的概念指的是集成流編排基于EIP（Enterprise Integration Patterns）協(xié)議。目前Spring Integration、 Apache Camel等都是比較成熟的集成流框架。

上述兩種編排在協(xié)議、框架和使用場(chǎng)景上有著明確區(qū)分，目前國(guó)內(nèi)的低代碼平臺(tái)大多數(shù)只提供工作流編排的能力。

|2.4 接口和集成

為了避免“數(shù)據(jù)孤島”現(xiàn)象，企業(yè)級(jí)應(yīng)用通常需要與其他系統(tǒng)進(jìn)行集成，協(xié)同增效。此時(shí)，內(nèi)置的集成能力和編程接口就變得至關(guān)重要。

這里涉及到連接器的概念，連接器是API的代理和包裝器。連接器的定義廣泛使用OpenApi的規(guī)范，基于Swagger2.0或者Swagger3.0的規(guī)范來(lái)實(shí)現(xiàn)。API的調(diào)用大多采用HttpClient的方式，基于Oauth等授權(quán)協(xié)議完成調(diào)用。

除了Rest接口的集成，云廠商的低代碼在系統(tǒng)集成商還有著更多方面的拓展。基于云上的網(wǎng)絡(luò)方案與授權(quán)協(xié)議，可以與用戶的MQ、DB、K8S集群等打通，完成與用戶托管方案的深度集成。

|2.5 代碼生成與低代碼高代碼融合

基于華為云Astro完成表單構(gòu)建、模型構(gòu)建之后，很容易基于模型元數(shù)據(jù)定義生成對(duì)應(yīng)后端模型和與之對(duì)應(yīng)的模型操作接口。在一些復(fù)雜的業(yè)務(wù)場(chǎng)景下，需要開(kāi)發(fā)者以高代碼的形式對(duì)這些模型和接口進(jìn)一步重載或復(fù)寫(xiě)。

在高代碼融合上，基礎(chǔ)功部分提供了預(yù)置函數(shù)和用戶自定義函數(shù)功能，通過(guò)條件表達(dá)式引擎來(lái)實(shí)現(xiàn)。高級(jí)代碼部分，通常與Servless框架進(jìn)行整合，將計(jì)算資源通過(guò)獨(dú)立集群或者沙箱的方式單獨(dú)承載。

3 總結(jié)

在介紹了原理之后，華為云Astro距離實(shí)現(xiàn)低代碼的能力高上限、門(mén)檻低下限的要求仍然有大量細(xì)致工作要做。