服務端低程式碼實現和設計思路

語言: CN / TW / HK

一、分享的目的

  • 在理解了服務端低程式碼平臺設計實現的基礎上,能夠讓大家更好的使用低程式碼平臺擴展出更多的能力,豐富工具的打造,知道什麼時候可以使用,如何使用。
  • kuta將來可能會走向內部開源,可以幫助kuta後來開發者對前面搭建的kuta架構有個高度概括的認識,在目前kuta中間層的基礎上,擴展出更多的低程式碼能力,豐富目前kuta低程式碼平臺所支援的功能。

二、低程式碼理念

2.1低程式碼概念的定義

  • 能夠以最少的手寫程式碼和設定快速開發應用、配置和部署業務應用程式。

2.2 低程式碼平臺的歷史

  • 低程式碼概念於 2014 年由 Forrester 首次正式提出,低程式碼產品由此開始了蓬勃發展。2015 年微軟正式釋出低程式碼產品 Power Apps,2017 年分析機構 Gartner 建立了 aPaaS 的低程式碼新門類,2018 年  Outsystems 和Mendix 低程式碼平臺等被爭相收購, Google 釋出自己的低程式碼產品 AppMaker。而在國內的低程式碼領域,阿里在2021 年 1 月釘釘宜搭低程式碼平臺正式對外發布,低程式碼概念也就在國內火熱起來,越來越多的低程式碼產品紛紛問世。

2.3酷家樂低程式碼平臺

  • 酷家樂從2021年下半年開始搭建酷塔kuta低程式碼平臺,我們把低程式碼概念應用在對測試工具的打造上,走了一條符合我們業務特性的道路。藉助kuta低程式碼開發平臺,技術支援可以自己或者在測試的指導下開發出更符合特定業務需求的工具。

三、KUTA低程式碼平臺簡介

3.1現狀

  • 以打造一款工具為例,目前已實現通過工具配置的方式打造工具的前端邏輯,以及通過API配置的方式實現後端介面呼叫的低程式碼邏輯。

3.2劣勢

  • 但代表後端程式碼邏輯的API配置只能實現單介面的呼叫,不能滿足工具個性化打造的需求。我們常常遇到需要呼叫多個介面,並將介面返回資料進行一定邏輯處理再返回給前端,此時,單個介面的API配置就無法滿足業務需求。

3.3 解決方案

  • 因此,我們引入通過在前端編寫少量Groovy程式碼來實現服務端低程式碼的配置,自動生成API,該型別API具有跟API配置中的api同樣的地位,稱之為Groovy API,我們通過在前端配置中關聯該Groovy API,即可打通工具的前後端配置。

四、為什麼要做服務端低程式碼

4.1傳統的純程式碼開發模式與低程式碼開發

4.2 低程式碼開發優勢

  • 通用性:通過前端後端低程式碼配置,降低工具開發的成本和技術門檻,非開發人員可以參與,減少聯調、部署時間。
  • 低成本:減少人力成本、溝通成本和時間成本, 既能夠將工具開發的門檻降低,同時也能通過低程式碼實現更多的擴充套件能力。
  • 連通性:kuta在moon上部署,通過kuta的請求轉發,可以打通各方存量系統,如各測試小組測試平臺、酷家樂工具、商家後臺、七彩石、pub、moon等公司內外部平臺。
  • 高效率:提升工具開發效率,快速打造一款工具的前後端,無需前後端聯調和部署,快速實現工具的個性化打造。
  • 敏捷性:設計靈活,業務與工具打造協同,可以在迭代內進行工具的敏捷開發。
  • 穩定性:程式碼結構化程度高,更容易維護。無需關心伺服器、網路、資料庫等技術概念和底層運維,kuta作為統一的解決方案,低程式碼開發者只需要專注於業務本身。

五、服務端低程式碼選型

5.1 為什麼選擇groovy作為後端低程式碼的實現方式?

兼具融合性和語言優勢:

5.1.1 容易和java環境整合

  • Groovy支援 Java 虛擬機器,在設計之初充分考慮了和Java整合,這使 Groovy 與 Java 程式碼的互操作很容易,非常容易整合在Java環境中, 而且可以無縫整合所有已經存在的 Java物件和類庫。

5.1.2 語言容易上手

  • Groovy與Java的語法很相似,可以將Groovy想象成 Java 語言的一種更加簡單、表達能力更強的變體。從學習的角度看,如果知道如何編寫 Java 程式碼,那就已經瞭解 Groovy 了。它們的主要區別是:完成同樣的任務所需的 Groovy 程式碼比 Java 程式碼更少。在 Groovy 中 , 可以完全使用 Java語法進行開發 ;

5.1.3 語言特性優勢

  • Groovy在支援常規的Java操作或者說是語法的同時,結合了Python、Ruby和Smalltalk的許多特性。Groovy更像是Java的一個框架,類似SpringBoot這樣的框架,封裝了提升程式設計效率的語法。缺點也是因為它的語言相容特性帶來的。groovy對一些操作進行封裝縮減,降低編寫工作量,方便靈活程式設計。特性越多,越靈活的語言,效能越低。例如:Groovy 語言是動態語言.與之相對的 , Java 是一門靜態語言 ; 具體就是在宣告變數前 , Java 語言必須宣告該變數的型別 , groovy宣告變數時 , 可以暫時不指定變數型別;

5.2 前端編輯器選型

前端嵌入線上程式碼編輯器AceEditor,優化前端線上coding體驗。

前端編輯器選型: 普通文字輸入框——>CodeMirror2——>AceEditor

六、服務端低程式碼實現原理

Groovy 整合在Java環境中:

  • 我們所使用的整合機制是: GroovyShell
  • groovy.lang.GroovyShell作用:
  1. 執行 Groovy 程式碼
  2. 有更豐富的功能,比如 繫結更多的變數 ,從檔案系統、網路載入程式碼等。
  • GroovyShell允許在Java類中(甚至Groovy類)求任意Groovy表示式的值。通過使用Binding物件輸入引數給表示式,並最終通過GroovyShell返回Groovy表示式的計算結果.
  • Binding類主要用於傳遞引數集, 而GroovyShell則主要用於編譯執行Groovy程式碼

private Object byGroovyShell(GroovyDto groovyDto, JSONObject paramObject) {

Binding binding = new Binding(paramObject);

GroovyShell shell = new GroovyShell(binding);

return shell.evaluate(groovyDto.getGroovyCode());

}

七、服務端程式碼與kuta融合-從懷疑中誕生,在摸索中前進

7.1 從簡單的線上執行指令碼到與kuta融合

線上執行groovyUI介面

上述版本僅簡單實現了服務端線上動態執行前端輸入的程式碼,和服務端低程式碼還相差甚遠。

7.2 與kuta融合的版本

UI介面:

7.3 融合方式

通過在Groovy配置介面進行Groovy api的配置,線上除錯groovy指令碼,提交後,服務端會對Groovy code和groovy params做儲存,自動生成Groovy Api展示在groovy列表中。

Groovy Api可以在工具配置時被工具關聯,當工具呼叫時,會呼叫儲存的groovy code和params,實現工具的服務端低程式碼呼叫。

7.4 豐富的功能

  • 線上編輯groovy指令碼自動生成api,通過資料庫儲存groovy內容,在kuta前端通過配置工具可以呼叫groovy api,動態獲取介面groovy api入參,動態執行groovy指令碼,實現較為複雜工具的低程式碼打造。(優點:免除了使用者在打造工具時的一系列繁瑣行為,如安裝程式碼編輯器/環境,除錯時的環境啟動,git操作,程式碼倉管理,聯調,部署等,這些行為都可以被免去。同時還能使用更加簡潔高效的語言。)
  • 前端的嵌入程式碼編輯器,支援程式碼提示和程式碼補全,近似於idea的編碼體驗。
  • 支援線上除錯groovy程式碼, 程式碼除錯支援返回資料的展示, 方便使用者根據資料返回調整程式碼;支援線上除錯的程式碼錯誤的異常提示,增加返回錯誤堆疊。
  • 實現了後端groovy常用方法封裝, 封裝簡化http get和post請求,支援使用低程式碼呼叫已在kuta上配置的tool等,呼叫語句通常只有一行程式碼. 讓使用者使用更簡單的語句實現工具的功能。
  • groovy後端支援預設匯出包列表,已支援大部分常用包的匯出,使用者大多數情況下無需自己import包.(groovy預設匯入常用的包)。
  • 支援程式碼模板一鍵複製,快速生成程式碼,提升編碼效率,目前已提供了一些常用的程式碼模板,方便使用者選擇和使用。

八、整體架構圖

九、工具呼叫流程圖