如果經(jīng)?？次覀兊?span id="gg8g4gg" class="candidate-entity-word" data-gid="9430296">頭條號，應(yīng)該已經(jīng)關(guān)注到遠行科技已經(jīng)在SOA，微服務(wù)，容器云和DevOps方面有多年的技術(shù)積累和實踐案例。在2018年也推出了基于當前主流云原生思想的云原生技術(shù)中臺整體解決方案。

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

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

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

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

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

下面再對一些關(guān)鍵問題進行整理和說明。

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

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

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

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

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

其核心思想是：

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

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

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

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

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

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

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

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

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

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

沒有銀彈，是低代碼不是零代碼

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

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

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

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

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

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

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

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

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

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

當前在保存前你還可能調(diào)用多個API接口進行多個校驗。

為何叫企業(yè)級低代碼開發(fā)平臺？

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

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

MDA模型驅(qū)動思路

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

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

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

服務(wù)編排能力

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

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

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

當你面對一個企業(yè)級應(yīng)用開發(fā)的時候，那么就必須考慮多組織架構(gòu)，同時考慮對于開發(fā)者的多租戶架構(gòu)。舉個簡單的場景來說，一個企業(yè)本身也可能有多個細分的開發(fā)團隊，每個開發(fā)團隊都負責開發(fā)不同的微服務(wù)應(yīng)用。

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

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

簡單來說，理想化的場景是：

一個開發(fā)團隊首先申請創(chuàng)建一個獨立租戶，在租戶創(chuàng)建完成后開發(fā)團隊可以維護具體的開發(fā)配置人員，同時開發(fā)團隊可以創(chuàng)建一個或多個微服務(wù)應(yīng)用。

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

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