如果經(jīng)常看我們的頭條號(hào)，應(yīng)該已經(jīng)關(guān)注到遠(yuǎn)行科技已經(jīng)在SOA，微服務(wù)，容器云和DevOps方面有多年的技術(shù)積累和實(shí)踐案例。在2018年也推出了基于當(dāng)前主流云原生思想的云原生技術(shù)中臺(tái)整體解決方案。

在整個(gè)云原生技術(shù)中臺(tái)解決方案本身是覆蓋了開(kāi)發(fā)，運(yùn)行，治理運(yùn)維全生命周期管理。對(duì)于整體的全過(guò)程端到端支撐能力我們推出了DevOps過(guò)程能力支撐平臺(tái)，在運(yùn)行態(tài)推出了PaaS技術(shù)服務(wù)中臺(tái)和容器云PaaS平臺(tái)，而在治理層面即參考ServiceMesh服務(wù)網(wǎng)格的思路推出了完整的去中心化微服務(wù)治理架構(gòu)。

而對(duì)于低代碼開(kāi)發(fā)平臺(tái)，當(dāng)前一般將其納入到APaaS的范疇。對(duì)于低代碼開(kāi)發(fā)本身也是遠(yuǎn)行科技整體云原生技術(shù)解決方案中覆蓋開(kāi)發(fā)態(tài)度的一個(gè)關(guān)鍵內(nèi)容。

近年來(lái)零代碼、低代碼行業(yè)發(fā)展迅速，國(guó)內(nèi)APaaS創(chuàng)業(yè)廠(chǎng)商如明道云、伙伴云、輕流、黑帕云等均為模型驅(qū)動(dòng)型廠(chǎng)商，奧哲、華炎魔方以及云廠(chǎng)商代表阿里宜搭等則以可視化IDE模式，傳統(tǒng)快速開(kāi)發(fā)平臺(tái)和BPM廠(chǎng)商如普元，JEPaaS，廣州天翎切入APaaS市場(chǎng)。國(guó)外軟件平臺(tái)發(fā)展強(qiáng)勁，主要廠(chǎng)商如OutSystem、Mendix等在市場(chǎng)上均有較高知名度。

從當(dāng)前我們整體的云原生技術(shù)解決方案看到，在開(kāi)發(fā)態(tài)不僅僅是提供一個(gè)完整的微服務(wù)開(kāi)發(fā)框架和環(huán)境，提供各種共性的技術(shù)組件能力，更加重要的就是提供一個(gè)低代碼開(kāi)發(fā)平臺(tái)來(lái)實(shí)現(xiàn)通過(guò)配置化 少量代碼的方式來(lái)實(shí)現(xiàn)應(yīng)用的快速開(kāi)發(fā)。

同時(shí)低代碼開(kāi)發(fā)平臺(tái)和我們當(dāng)前的DevOps支撐平臺(tái)緊密協(xié)同，低代碼開(kāi)發(fā)完成的應(yīng)用可以快速的部署和交付到容器云環(huán)境。云原生下的低代碼開(kāi)發(fā)平臺(tái)應(yīng)該更加開(kāi)放和友好，比如提供相應(yīng)的代碼導(dǎo)出，部署包導(dǎo)出，對(duì)于導(dǎo)出的內(nèi)容可以直接在標(biāo)準(zhǔn)的eclipse開(kāi)發(fā)環(huán)境編譯構(gòu)建，可以進(jìn)行部署，并脫離低代碼開(kāi)發(fā)平臺(tái)本身運(yùn)行。

下面再對(duì)一些關(guān)鍵問(wèn)題進(jìn)行整理和說(shuō)明。

和市面低代碼開(kāi)發(fā)平臺(tái)的區(qū)別

注意，對(duì)于低代碼開(kāi)發(fā)領(lǐng)域當(dāng)前又細(xì)分為兩類(lèi)，一類(lèi)是類(lèi)似搭搭，宜搭，氚云這種偏零代碼開(kāi)發(fā)的平臺(tái)，一類(lèi)是是存少量代碼和腳本編寫(xiě)的低代碼開(kāi)發(fā)平臺(tái)，類(lèi)似JEPaaS，Jeecg-boot這種快速開(kāi)發(fā)平臺(tái)。

對(duì)于零代碼開(kāi)發(fā)平臺(tái)當(dāng)前很多都是由IDE和界面直接從前驅(qū)動(dòng)開(kāi)發(fā)和配置，而對(duì)于低代碼開(kāi)發(fā)平臺(tái)一般則是基于模型驅(qū)動(dòng)的思路來(lái)進(jìn)行功能模塊開(kāi)發(fā)。

也就是我們的低代碼開(kāi)發(fā)平臺(tái)是完全基于微服務(wù)架構(gòu)的低代碼開(kāi)發(fā)平臺(tái)。同時(shí)和業(yè)界標(biāo)準(zhǔn)的云原生技術(shù)支撐設(shè)施能夠完全協(xié)同和融合。

對(duì)于低代碼開(kāi)發(fā)平臺(tái)的構(gòu)建不僅僅是采用微服務(wù)開(kāi)發(fā)框架，更加重要的是符合當(dāng)前主流的中臺(tái)和微服務(wù)架構(gòu)思想。因此遠(yuǎn)行科技的低代碼開(kāi)發(fā)平臺(tái)不是走零代碼開(kāi)發(fā)的思路，而是真正的基于模型驅(qū)動(dòng)和SOA架構(gòu)思想，允許少量代碼開(kāi)發(fā)和融合。

其核心思想是：

• 低代碼開(kāi)發(fā)的小應(yīng)該應(yīng)該是一個(gè)個(gè)獨(dú)立的微服務(wù)
• 應(yīng)用的構(gòu)建進(jìn)一步貫徹SOA分層構(gòu)建的思路，通過(guò)服務(wù)層解耦
• 低代碼開(kāi)發(fā)應(yīng)該是模型驅(qū)動(dòng)的，這個(gè)模型核心是對(duì)象和數(shù)據(jù)模型

對(duì)于SOA分層構(gòu)建思路，一個(gè)重點(diǎn)就是面向?qū)ο蠛虯PI接口方式進(jìn)行整個(gè)應(yīng)用構(gòu)建。

在低代碼開(kāi)發(fā)時(shí)代，我個(gè)人更加推薦這種基于對(duì)象服務(wù)化的分層開(kāi)發(fā)模式。這個(gè)本身也是更加貼近我當(dāng)前中臺(tái)和微服務(wù)的構(gòu)建思路。即你首先去構(gòu)建你的對(duì)象并發(fā)布你的服務(wù)，然后再考慮如何基于這些發(fā)布的服務(wù)類(lèi)構(gòu)建上層的應(yīng)用。即我們的開(kāi)發(fā)過(guò)程橫向拆分為兩端。而中間基于服務(wù)進(jìn)行松耦合連接。

即：微服務(wù) 服務(wù) 前端應(yīng)用。

為何叫基于低代碼的PaaS自服務(wù)平臺(tái)

如果大家看過(guò)我前面關(guān)于傳統(tǒng)企業(yè)IT架構(gòu)轉(zhuǎn)型，企業(yè)私有云PaaS平臺(tái)構(gòu)建方面的文章就明白，對(duì)于企業(yè)整體的IT架構(gòu)規(guī)劃來(lái)說(shuō)，這個(gè)里面有一個(gè)重點(diǎn)就是底層的技術(shù)支撐平臺(tái)建設(shè)。這個(gè)技術(shù)支撐平臺(tái)包括了諸多的內(nèi)容，如下：

• 容器云的底層資源池和資源調(diào)度中心
• 消息，緩存，文件等各種技術(shù)服務(wù)組件
• 門(mén)戶(hù) 4A 流程引擎的基礎(chǔ)共性平臺(tái)
• 共性平臺(tái)和技術(shù)服務(wù)組件的API能力開(kāi)放和集成
• 微服務(wù)開(kāi)發(fā)框架和環(huán)境
• 微服務(wù)治理和監(jiān)控運(yùn)維平臺(tái)

在前面我一直在強(qiáng)調(diào)，低代碼開(kāi)發(fā)最終完成的就是一個(gè)個(gè)的微服務(wù)應(yīng)用，這個(gè)微服務(wù)本身需要有底層平臺(tái)能力，后端的管控治理能力做支撐。

低代碼開(kāi)發(fā)平臺(tái)不僅僅是一個(gè)開(kāi)發(fā)平臺(tái)，更加重要的是通過(guò)平臺(tái)在開(kāi)發(fā)的時(shí)候如何調(diào)用平臺(tái)可復(fù)用的已有技術(shù)和業(yè)務(wù)服務(wù)能力，通過(guò)開(kāi)發(fā)平臺(tái)完成的微服務(wù)后續(xù)的運(yùn)行管理，運(yùn)維監(jiān)控，治理等。

而我們的低代碼開(kāi)發(fā)平臺(tái)則是基于當(dāng)前我們已有的強(qiáng)調(diào)PaaS平臺(tái)和技術(shù)服務(wù)平臺(tái)之上的，只有這種模式構(gòu)建的應(yīng)用才可能做到獨(dú)立自治，后續(xù)可以靈活彈性擴(kuò)展并滿(mǎn)足高性能和高并發(fā)的業(yè)務(wù)需求。

沒(méi)有銀彈，是低代碼不是零代碼

注意，我們做的是低代碼開(kāi)發(fā)平臺(tái)而不是零代碼。

企業(yè)信息化和業(yè)務(wù)系統(tǒng)遠(yuǎn)遠(yuǎn)比一個(gè)簡(jiǎn)單的OA系統(tǒng)復(fù)雜，即使是OA系統(tǒng)你也會(huì)看到中大型企業(yè)的OA系統(tǒng)也無(wú)法完全通過(guò)零代碼模式開(kāi)發(fā)和完成。

這一方面是底層的技術(shù)架構(gòu)，高可用性方面的問(wèn)題。一個(gè)方面是面向集團(tuán)企業(yè)帶入的多組織，權(quán)限管理，業(yè)務(wù)規(guī)則邏輯等的復(fù)雜性引入。

對(duì)于復(fù)雜業(yè)務(wù)規(guī)則的實(shí)現(xiàn)，當(dāng)前主流做法是引入規(guī)則引擎來(lái)進(jìn)行靈活配置，但是如果是復(fù)雜業(yè)務(wù)規(guī)則規(guī)則引擎也很難配置，而且引入大量難以管理和后期運(yùn)維的腳本代碼。

在前面實(shí)際我已經(jīng)強(qiáng)調(diào)了我們的低代碼開(kāi)發(fā)實(shí)際是前端界面開(kāi)發(fā)設(shè)計(jì)和后端能力分層，中間通過(guò)服務(wù)層進(jìn)行解耦，當(dāng)前核心仍然是對(duì)象模型驅(qū)動(dòng)。

在解耦后，我們的思路是對(duì)于前端開(kāi)發(fā)盡量完全做到可視化設(shè)計(jì)和靈活配置。而對(duì)于后端開(kāi)發(fā)則是標(biāo)準(zhǔn)對(duì)象模型發(fā)布的API接口能力自動(dòng)化，但是對(duì)于復(fù)雜規(guī)則的實(shí)現(xiàn)仍然是自己編寫(xiě)代碼然后發(fā)布為標(biāo)準(zhǔn)的Http Rest API接口服務(wù)，前端設(shè)計(jì)器能夠通過(guò)少量的JS代碼來(lái)調(diào)用后端服務(wù)能力。

如果這樣還是無(wú)法滿(mǎn)足復(fù)雜規(guī)則實(shí)現(xiàn)。

那么我們的低代碼開(kāi)發(fā)平臺(tái)還支持你將對(duì)象建模，界面設(shè)計(jì)等完成的配置開(kāi)發(fā)內(nèi)容完全導(dǎo)出為源代碼，你在該源代碼基礎(chǔ)上進(jìn)行接口擴(kuò)展，在擴(kuò)展接口中增加你自己的業(yè)務(wù)規(guī)則和邏輯定義實(shí)現(xiàn)。

比如保存按鈕，事件觸發(fā)后就調(diào)用表單保存操作對(duì)數(shù)據(jù)進(jìn)行保存。但是實(shí)際上你會(huì)看到在保存前你可能需要進(jìn)行業(yè)務(wù)規(guī)則和邏輯處理，在保存后你可能觸發(fā)其它關(guān)聯(lián)操作。

//Form.SaveBefore();//Form.Save//Form.SaveAfter();

當(dāng)前在保存前你還可能調(diào)用多個(gè)API接口進(jìn)行多個(gè)校驗(yàn)。

為何叫企業(yè)級(jí)低代碼開(kāi)發(fā)平臺(tái)？

首先我提一個(gè)問(wèn)題給大家，即當(dāng)前很多做低代碼開(kāi)發(fā)平臺(tái)的廠(chǎng)家，這些廠(chǎng)家是否建設(shè)和實(shí)施過(guò)類(lèi)似大中型企業(yè)負(fù)責(zé)的業(yè)務(wù)系統(tǒng)。

實(shí)際對(duì)于大部分廠(chǎng)家都沒(méi)有做過(guò)，更多的是參考國(guó)外低代碼開(kāi)發(fā)平臺(tái)的做法，當(dāng)前主流的一些SaaS小應(yīng)用的抽象歸納，形成自己的低代碼開(kāi)發(fā)平臺(tái)。包括前面我談到的，如果整個(gè)平臺(tái)完全是從界面設(shè)計(jì)一直驅(qū)動(dòng)到后端對(duì)象和數(shù)據(jù)庫(kù)表，那么整個(gè)前端和后端很難解耦，你會(huì)發(fā)現(xiàn)當(dāng)涉及到有多表共同實(shí)現(xiàn)的業(yè)務(wù)規(guī)則和邏輯的時(shí)候很難實(shí)現(xiàn)。

MDA模型驅(qū)動(dòng)思路

真正好的低代碼開(kāi)發(fā)平臺(tái)一定是類(lèi)似MDA模型驅(qū)動(dòng)的，是基于服務(wù)層來(lái)實(shí)現(xiàn)前端界面設(shè)計(jì)和后端數(shù)據(jù)提供之間的解耦。這個(gè)類(lèi)似當(dāng)前云原生技術(shù)實(shí)踐中的ServerLess無(wú)服務(wù)器化，即FaaS層和BaaS層分離。BaaS層很多服務(wù)能力開(kāi)始代碼開(kāi)發(fā)，但是FaaS層界面設(shè)計(jì)和服務(wù)組合實(shí)現(xiàn)低代碼和靈活編排。

而對(duì)于遠(yuǎn)行科技自身，我們本是也建設(shè)和實(shí)施類(lèi)似財(cái)務(wù)共享類(lèi)大型企業(yè)業(yè)務(wù)系統(tǒng)，這個(gè)大應(yīng)用本身又包括了報(bào)賬，預(yù)算，資金，發(fā)票等多個(gè)微服務(wù)應(yīng)用。而我們的低代碼開(kāi)發(fā)平臺(tái)本身是來(lái)源于我們的系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)實(shí)踐。

即將完成的低代碼開(kāi)發(fā)平臺(tái)本身就能夠滿(mǎn)足財(cái)務(wù)域復(fù)雜業(yè)務(wù)場(chǎng)景的設(shè)計(jì)和實(shí)現(xiàn)，對(duì)于業(yè)務(wù)需求變更的快速配置開(kāi)發(fā)上線(xiàn)等需求。

服務(wù)編排能力

前端開(kāi)發(fā)的靈活性不僅僅體現(xiàn)在表單設(shè)計(jì)，JS簡(jiǎn)單腳本代碼編寫(xiě)，更加重要的是支撐輕量的微服務(wù)編排能力，即對(duì)于標(biāo)準(zhǔn)的API接口服務(wù)，我們可以直接進(jìn)行服務(wù)編排組裝，形成組合服務(wù)能力API供前端調(diào)用。

在傳統(tǒng)模式下這種服務(wù)組合可能需要手寫(xiě)后端代碼來(lái)完成并發(fā)布為一個(gè)API接口，但是現(xiàn)在這塊能力可以通過(guò)服務(wù)編排引擎來(lái)完成，進(jìn)一步提升了前端開(kāi)發(fā)和配置的效率。

企業(yè)級(jí)應(yīng)用的多租戶(hù)，多組織模型

當(dāng)你面對(duì)一個(gè)企業(yè)級(jí)應(yīng)用開(kāi)發(fā)的時(shí)候，那么就必須考慮多組織架構(gòu)，同時(shí)考慮對(duì)于開(kāi)發(fā)者的多租戶(hù)架構(gòu)。舉個(gè)簡(jiǎn)單的場(chǎng)景來(lái)說(shuō)，一個(gè)企業(yè)本身也可能有多個(gè)細(xì)分的開(kāi)發(fā)團(tuán)隊(duì)，每個(gè)開(kāi)發(fā)團(tuán)隊(duì)都負(fù)責(zé)開(kāi)發(fā)不同的微服務(wù)應(yīng)用。

那么各個(gè)開(kāi)發(fā)團(tuán)隊(duì)之間的租戶(hù)數(shù)據(jù)，權(quán)限應(yīng)該做到完全隔離。其次你開(kāi)發(fā)的一個(gè)應(yīng)用需要滿(mǎn)足企業(yè)負(fù)責(zé)的多組織架構(gòu)模型，包括組織，用戶(hù)，授權(quán)模型。

而這些內(nèi)容需要有一個(gè)強(qiáng)調(diào)的4A平臺(tái)和流程引擎平臺(tái)來(lái)進(jìn)行支撐，同時(shí)通過(guò)上層的統(tǒng)一的云門(mén)戶(hù)來(lái)進(jìn)行整合，實(shí)現(xiàn)所有微服務(wù)應(yīng)用的集中管理，單點(diǎn)登錄和統(tǒng)一認(rèn)證等。

簡(jiǎn)單來(lái)說(shuō)，理想化的場(chǎng)景是：

一個(gè)開(kāi)發(fā)團(tuán)隊(duì)首先申請(qǐng)創(chuàng)建一個(gè)獨(dú)立租戶(hù)，在租戶(hù)創(chuàng)建完成后開(kāi)發(fā)團(tuán)隊(duì)可以維護(hù)具體的開(kāi)發(fā)配置人員，同時(shí)開(kāi)發(fā)團(tuán)隊(duì)可以創(chuàng)建一個(gè)或多個(gè)微服務(wù)應(yīng)用。

對(duì)于每個(gè)微服務(wù)應(yīng)用可以規(guī)劃具體的業(yè)務(wù)功能菜單和功能權(quán)限配置。對(duì)于每一個(gè)業(yè)務(wù)功能的實(shí)現(xiàn)則是采用表單建模，對(duì)象建模，規(guī)則建模，流程建模等各個(gè)建模功能來(lái)完成。完成的業(yè)務(wù)功能掛接到具體的功能菜單，并進(jìn)行功能權(quán)限和數(shù)據(jù)權(quán)限的授權(quán)操作。

在一個(gè)功能完全開(kāi)放完成后可以持續(xù)發(fā)布和交付到云門(mén)戶(hù)中，即開(kāi)發(fā)完成的微服務(wù)應(yīng)用能夠自動(dòng)增加和集成到云門(mén)戶(hù)的統(tǒng)一入口中，只有一個(gè)業(yè)務(wù)用戶(hù)授權(quán)使用該微應(yīng)用，同時(shí)業(yè)務(wù)用戶(hù)登錄了云門(mén)戶(hù)，那么就能夠快速的進(jìn)入到微應(yīng)用中。