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

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

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

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

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

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

下面再對一些關鍵問題進行整理和說明。

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

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

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

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

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

其核心思想是：

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

對于SOA分層構建思路，一個重點就是面向對象和API接口方式進行整個應用構建。

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

即：微服務 服務 前端應用。

為何叫基于低代碼的PaaS自服務平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MDA模型驅動思路

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

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

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

服務編排能力

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

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

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

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

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

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

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

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

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

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