低代碼開發(fā)平臺(tái)需要解決的核心問題-服務(wù)編排和規(guī)則引擎(低代碼開發(fā)平臺(tái)是什么意思)
今天再談下對(duì)低代碼開發(fā)平臺(tái)的一些思考。
在前些日子,ThoughtWorks 中國(guó)區(qū) CTO 徐昊在接受采訪的時(shí)候談到,低代碼不是一個(gè)新概念,現(xiàn)在也不是低代碼第一次引發(fā)業(yè)界討論,以降低程序員門檻為目的的低代碼從底層邏輯上就是不通的,這類低代碼不是風(fēng)口,而是行業(yè)毒瘤。
這個(gè)在當(dāng)時(shí)引起了廣泛的討論和爭(zhēng)議,當(dāng)然反擊聲音最大的肯定是各種低代碼開發(fā)廠商,這本身也可能極大的影響到這些廠商本身的商業(yè)利益和發(fā)展融資。
實(shí)際上對(duì)于徐昊整個(gè)采訪一直在強(qiáng)調(diào),以降低程序員門檻為目的的低代碼是最沒用的。從某種程度上來講,這類低代碼產(chǎn)品最終會(huì)演變成程序員的工作,甚至引發(fā)新一類程序員的出現(xiàn),而它本身則從低代碼退化成為真正的代碼。
在10多年前我們就做過類似的快速開發(fā)平臺(tái),里面有完整的界面建模,對(duì)象建模,流程建模,規(guī)則建模,組織權(quán)限建模等能力。但是應(yīng)用到后期發(fā)現(xiàn)的一個(gè)關(guān)鍵問題就是對(duì)于規(guī)則引擎部分,通過腳本代碼實(shí)現(xiàn)的規(guī)則越來越復(fù)雜和龐大,而且極難維護(hù)。也就是說很很多業(yè)務(wù)需求或復(fù)雜規(guī)則的實(shí)現(xiàn)很難抽象出統(tǒng)一標(biāo)準(zhǔn)規(guī)則或模型,你必須用腳本代碼去實(shí)現(xiàn),但是對(duì)于復(fù)雜規(guī)則腳本卻變得越來越龐大。
在《人月神話》這本書里面提出一個(gè)重要的觀點(diǎn)就是沒有銀彈,只有焦油坑。當(dāng)時(shí)提出這個(gè)觀點(diǎn)的背景仍然是大型工程類復(fù)雜軟件系統(tǒng)的開發(fā)和實(shí)現(xiàn)。對(duì)于這類系統(tǒng)可以看到的重點(diǎn)已經(jīng)不是后續(xù)的編碼工作,而是整個(gè)系統(tǒng)分析和設(shè)計(jì)過程。
在我前面一篇對(duì)沒有銀彈的論述文章里面也談到,整個(gè)從需求到軟件開發(fā)實(shí)現(xiàn)的過程實(shí)際上可以分為幾個(gè)關(guān)鍵環(huán)節(jié),即:現(xiàn)實(shí)世界-》業(yè)務(wù)建模-》系統(tǒng)建模-》開發(fā)實(shí)現(xiàn)。
也就是說低代碼開發(fā)平臺(tái)并不能省略掉業(yè)務(wù)建模和系統(tǒng)建模這個(gè)動(dòng)作,而這個(gè)建模本身又需要一些業(yè)務(wù) 技術(shù)的雙背景往往才能夠更好去承擔(dān)該任務(wù)。
簡(jiǎn)單來說,隨便一個(gè)人,給你一個(gè)低代碼開發(fā)平臺(tái),你就能夠?qū)崿F(xiàn)一個(gè)完整的業(yè)務(wù)系統(tǒng),這個(gè)本身就不現(xiàn)實(shí)。那么是否就說低代碼開發(fā)平臺(tái)本身沒有價(jià)值?
要回答這個(gè)問題,還是要將低代碼開發(fā)平臺(tái)分為兩大類。一類是零代碼偏配置的平臺(tái),一類是真正低代碼面向開發(fā)人員的平臺(tái)。
零代碼偏配置的平臺(tái)
對(duì)于零代碼偏配置類低代碼平臺(tái),整體來看,可以看到三類發(fā)展和演進(jìn)方向。
其一是將傳統(tǒng)企業(yè)工作中日常的表單流程實(shí)現(xiàn)電子化,自動(dòng)化,流程化。這里表單流本身更多是表單CRUD邏輯,配置權(quán)限和流程審批,沒有復(fù)雜的類似ERP系統(tǒng)一樣的后端業(yè)務(wù)規(guī)則需要實(shí)現(xiàn)。因此低代碼平臺(tái)一般能夠勝任。
其二是基于垂直行業(yè)應(yīng)用下擴(kuò)展低代碼開發(fā)能力,比如項(xiàng)目管理應(yīng)用,CRM應(yīng)用,包括復(fù)雜的ERP系統(tǒng)等。在這種場(chǎng)景下底層核心業(yè)務(wù)模型和對(duì)象模型是穩(wěn)定的,不能輕易出現(xiàn)變化,外部人員更多是基于低代碼開發(fā)能力進(jìn)行快速外圍能力擴(kuò)展。
其三是SaaS平臺(tái)類應(yīng)用的外圍生態(tài)構(gòu)建,最典型的就是類似釘釘這種SaaS應(yīng)用,其本身就是面對(duì)類似OA,HR等日常協(xié)同類應(yīng)用,流程表單多而規(guī)則并不復(fù)雜。因此提供一個(gè)低代碼平臺(tái)能力更加方便用戶進(jìn)行能力擴(kuò)展,SaaS平臺(tái)唯一需要考慮的就是底層組織引擎本身的穩(wěn)定性,統(tǒng)一注冊(cè)接入的接口標(biāo)準(zhǔn)和集成等。
真正低代碼面向開發(fā)人員的平臺(tái)
當(dāng)前我們談平臺(tái) 應(yīng)用構(gòu)建模式,談中臺(tái)和能力開放,談云原生平臺(tái)和ServerLess架構(gòu)。而這些都體現(xiàn)出一個(gè)關(guān)鍵特征,即:
應(yīng)用開發(fā)應(yīng)該是分層的,前后端分離的。
后端提供的是各種可復(fù)用的API接口服務(wù)能力,這些能力既包括了類似消息,緩存等技術(shù)服務(wù)能力,也包括了類似人員,組織,規(guī)則處理等業(yè)務(wù)服務(wù)服務(wù)能力。
前端應(yīng)用的開發(fā)更多的應(yīng)該是基于后端的API服務(wù)能力靈活地進(jìn)行組裝和編排來完成?;谶@個(gè)思路你會(huì)發(fā)現(xiàn)前端實(shí)際包括了兩個(gè)關(guān)鍵事情。
- 其一是低代碼平臺(tái)常說的界面建模能力
- 其二是接口服務(wù)本身的組裝,服務(wù)編排能力
而對(duì)于后端來說核心則是提供各種API接口服務(wù)。這些接口本身本身也分為了兩類,一類是在進(jìn)行對(duì)象建模完成后將簡(jiǎn)單對(duì)象或復(fù)合數(shù)據(jù)對(duì)象發(fā)布為API接口服務(wù)。其二是提供規(guī)則引擎來實(shí)現(xiàn)各種規(guī)則能力并發(fā)布為API接口服務(wù)。
對(duì)象直接發(fā)布為API接口很容易實(shí)現(xiàn)。
而真正困難或難以自動(dòng)化的就是規(guī)則引擎實(shí)現(xiàn),并將規(guī)則發(fā)布為API接口服務(wù)的過程。前面已經(jīng)談到對(duì)于復(fù)雜業(yè)務(wù)規(guī)則或邏輯的實(shí)現(xiàn),即使采用規(guī)則引擎,那么也存在大量手工編寫的規(guī)則實(shí)現(xiàn)腳本代碼,由于是腳本代碼,這些規(guī)則越寫越復(fù)雜,越是難以維護(hù)。
當(dāng)我重新思考這個(gè)問題的時(shí)候,發(fā)現(xiàn)面向開發(fā)的低代碼平臺(tái),核心是規(guī)則引擎和服務(wù)編排,同時(shí)在引入這兩個(gè)關(guān)鍵組件時(shí)候,你也要意識(shí)到對(duì)于復(fù)雜規(guī)則實(shí)現(xiàn),復(fù)雜的編排,最好的方式仍然是寫代碼來實(shí)現(xiàn),最終將其暴露為API接口服務(wù)。
也就是說這類規(guī)則服務(wù)或領(lǐng)域服務(wù)能力本身還是可以代碼實(shí)現(xiàn)的,是可以維護(hù)的。
就規(guī)則引擎和服務(wù)編排來講。
個(gè)人理解前期在自動(dòng)化的實(shí)現(xiàn)中,重點(diǎn)不是規(guī)則引擎,而是可視化的服務(wù)編排能力實(shí)現(xiàn)。當(dāng)前已經(jīng)有不少的微服務(wù)架構(gòu)下的微服務(wù)API編排開源組件實(shí)現(xiàn),但是前面我文章也分析過并不是特別的靈活和可配置。
對(duì)于服務(wù)編排場(chǎng)景的詳細(xì)闡述,可以參考下面這篇文章。
從ESB服務(wù)組合編排到NetflixConductor微服務(wù)編排
一個(gè)可視化服務(wù)編排,重點(diǎn)在哪里?
我們可以對(duì)這個(gè)問題簡(jiǎn)單思考,比如前端在進(jìn)行界面設(shè)計(jì)建模的時(shí)候,最喜歡的就是各種界面組件,控件,按鈕,能夠直接掛接到一個(gè)統(tǒng)一的組合服務(wù)API上面,而不是說前端人員在界面設(shè)計(jì)的時(shí)候還需要去搞清楚點(diǎn)擊安排究竟要調(diào)用幾個(gè)API接口,而且調(diào)用過程中還需要遵循什么樣的規(guī)則邏輯。
在前后端分離的場(chǎng)景下,前端并不關(guān)心復(fù)雜的后端邏輯。
從這個(gè)道理上來講,微服務(wù)編排需要考慮的就是將多個(gè)細(xì)粒度的原子服務(wù)或API接口,統(tǒng)一組合或組裝為一個(gè)大的API接口服務(wù)的能力。
這種服務(wù)組裝或組合本身只包括兩大類。
第一類是偏靜態(tài)的數(shù)據(jù)組合,組裝和拆分。比如你點(diǎn)按鈕要獲取數(shù)據(jù),原來是要查詢兩次API接口,現(xiàn)在我給你組合下,調(diào)用一個(gè)大API組合服務(wù),一次給你返回所有數(shù)據(jù)?;蛘哒f類似單據(jù)保存過程,你原來是需要調(diào)用兩個(gè)API接口分別保存頭和明細(xì),現(xiàn)在我給你組合下,你一次把完整數(shù)據(jù)對(duì)象送過來,我一次給你保存完。這些是屬于典型的傳統(tǒng)基于領(lǐng)域?qū)ο蟮念I(lǐng)域服務(wù)API接口實(shí)現(xiàn)的。
第二類是偏動(dòng)態(tài)的自動(dòng)化業(yè)務(wù)流程處理,類似在傳統(tǒng)SOA架構(gòu)里面說的BPEL自動(dòng)化業(yè)務(wù)流程處理。這種業(yè)務(wù)流都是系統(tǒng)后端自動(dòng)完成,不需要人工干預(yù),比如點(diǎn)擊按鈕要自動(dòng)產(chǎn)生一個(gè)待辦工單,比如提交報(bào)賬前要首先調(diào)用預(yù)算API接口進(jìn)行預(yù)算檢查,比如在單據(jù)保存成功后自動(dòng)化去啟動(dòng)流程API接口等。這類服務(wù)組裝或編排往往體現(xiàn)出一張接口服務(wù)串行調(diào)用的典型特征,即前一個(gè)API接口輸出會(huì)成為一個(gè)接口的輸入。
那么第二類服務(wù)編排究竟應(yīng)該是基于服務(wù)的同步事務(wù)處理,還是基于消息事件的異步編排就變成一個(gè)關(guān)鍵點(diǎn)。如果是同步你需要考慮補(bǔ)償或回退機(jī)制,如果是異步消息,你需要保證消息最終一致性等。
當(dāng)前我沒看到任何一個(gè)輕量級(jí)的基于微服務(wù)API接口的可視化服務(wù)編排工具,如果有相關(guān)的可以推薦給我進(jìn)行分析和研究。同時(shí)我也再次提出基于微服務(wù)API的輕量,靈活,可視化服務(wù)編排工具,往往是一個(gè)重要的低代碼平臺(tái)發(fā)展趨勢(shì)。