今天再寫一篇文章，談下最近進行低程式碼開發平臺產品架構設計和研發實踐過程中的一些關鍵點的思考。在前面寫過的關於低程式碼開發平臺的文章中，基本已經將平臺本身的核心架構和建模思路表達清楚，在這裡不再重複敘述。

前兩天我準備華南CIO大會關於從數字化轉型到雲原生的主題演講材料，裡面一篇材料涉及到低程式碼開發平臺。

在這頁PPT裡面繼續強調我們實際做的是面向企業的低程式碼開發平臺而非零程式碼開發平臺，特別是在規則引擎方面的技術沒有得到實質性突破的時候，軟體研發沒有銀彈，複雜規則仍然需要自己開發。也就是整個平臺更多是參考類似Mendix的架構設計思路進行。

在雲原生裡面有一個核心技術實踐即ServerLess無伺服器架構，該架構將應用的開發分為了BaaS後端即服務和FaaS函式即服務兩層，並提出一個核心思路就是在BaaS服務積累得足夠好的時候，你開發應用更多僅僅是前端函式或指令碼的編寫，和對後端BaaS提供的API服務介面能力的組裝。

這個思路本身就是低程式碼開發，是雲原生實踐下推薦的一種低程式碼開發的思路。

其次任何一個應用系統應該考慮解耦，微服務化，包括和底層技術平臺的雲化，那麼低程式碼開發平臺本身也應該是微服務架構，遵從基本的分層架構原則。低程式碼平臺本身就應該分散式，可彈性擴充套件，這也是開發出高可用高效能的應用的基礎。

如果一個企業只是想快速開發一個類似週報填寫，考勤記錄的簡單應用，那麼當前主流的低程式碼SaaS服務平臺基本都能滿足需求而且可以做到完全的零程式碼化。但是如果你是要開發一個類似企業內部的業務系統，這個系統可能上萬人使用，上千的秒級併發量，即使是一個簡單的OA系統也不是一般的低程式碼平臺能搞定的事情。

所以你做一個低程式碼開發平臺，不要將重心僅僅放在視覺化表單設計，視覺化流程設計，拖拽式的配置層面，這些雖然很重要，但是對於企業級的低程式碼平臺來說不是重點，底層技術架構本身的高可靠，可擴展才是重點。

再次，企業本身又遺留IT系統，這個時候低程式碼開發平臺如何切入？如何確保低程式碼開發平臺開發完成的應用能夠和已有的IT業務系統很好地融合和整合？

當前很多低程式碼開發平臺都沒有考慮這個問題點，更多開發的都是一個個獨立的資訊孤島，而無法很好地和其它已有業務系統打通，形成整合和協同。如果按這個思路去不斷地開發配置應用，那麼後續開發完成的應用的整合和管控將是大問題。

我今天做的關於低程式碼開發平臺架構設計和實踐的思考，也正是基於以上的前提展開，在今天的思考裡面重點談以下幾個方面的內容。

低程式碼平臺的多租戶架構

低程式碼平臺裡面的多租戶需要從兩個層面來談，第一個是低程式碼平臺本身的多租戶架構設計，其次是低程式碼平臺開發完成的應用多租戶問題。

先談第一個問題。

低程式碼開發平臺本身的多租戶問題，這個問題實際比較複雜，如果是SaaS層面的低程式碼需要考慮甲方企業和企業內部開發團隊兩次的多租戶的資料隔離。即使是部署到企業內部的私有云部署，也需要考慮企業是否存在子公司的情況。

不同的子組織，開發團隊上來，應該只能夠看到自己開發和設計的應用，而無法看到其它應用。這就類似張三和李四開發SRM和CRM兩個應用系統一樣。

張三來說開發SRM，那麼李四設計的CRM系統裡面的物件，介面，流程模型等應該對張三不可見，張三也無法隨意使用CRM系統的資料物件。如果張三需要CRM系統裡面的客戶資料，那麼也需要走開放的API介面呼叫。

也就是SRM和CRM兩個系統，不僅僅是在開發階段對應開發人員來說資料是隔離的，對於開發完成最終上線的應用來說，資料也是隔離的。

再談第二個問題開發完成的應用隔離。

對於獨立開發的CRM和SRM兩個應用，你如何進行應用部署交付？一種方法就是完全獨佔資源進行部署，兩個應用都採用獨立的資料庫例項，獨立的應用中介軟體容器，分別進行部署，相互之間也完全獨立自治和解耦。

還有一種思路就是類似SaaS多租戶架構設計一樣，開發完成的應用最終都在一個大的資料庫裡面，只是透過類似Org_ID組織ID或租戶ID進行資料邏輯隔離。或者在一個大的資料庫中企業不同的Schema來進行隔離。

那麼如何選擇？

簡單來說就是開發大的應用一定是要獨立部署資源完全隔離，但是如果你是開發的一個小應用那麼完全可以採用多租戶架構思路一個大資料庫並進行資料邏輯隔離即可。

最後，低程式碼平臺本身還會用到流程引擎，類似訊息，快取各種技術服務能力。那麼這些技術服務能力本身也需要是多租戶架構，做到資料隔離。這個租戶不是在組織或開發團隊層面，而是需要到具體的一個個業務系統層面。每個業務系統才是最底層最細化的租戶。

技術平臺和服務整合

技術平臺和技術服務能力提供，技術服務的整合是企業級低程式碼開發平臺的另外一個關鍵點。這點可以再參考下雲原生ServerLess的思路，即技術能力提供不應該是在應用系統內部，而是應該單獨剝離和下沉到雲平臺BaaS層能力，做為獨立的服務提供。

獨立提供技術服務才可能讓最終低程式碼開發完成的應用具備高擴充套件性。

低程式碼開發的應用更多隻關於業務場景，業務規則和邏輯的實現，而不用去關心底層技術平臺細節，比如低程式碼平臺本身也需要用到快取能力。那麼這個快取就應該使用雲平臺提供的快取服務，即使快取服務出現效能瓶頸，也是雲平臺來考慮如何擴充套件而不是低程式碼平臺本身去考慮。

對於技術平臺和服務分為兩類。

公共流程引擎，4A平臺各類技術服務：包括訊息，快取，檔案，日誌等

以上列的平臺和技術服務，如果你是做一個企業級的低程式碼開發平臺，那麼這些平臺服務能力也必須獨立出來，下沉到企業內部私有云PaaS平臺以服務化方式提供，同時還需要滿足前面提到的多租戶架構要求。

什麼意思呢？

一個低程式碼開發平臺的執行，即使是在測試環境也離不開上面這些平臺或技術服務能力先執行起來。即低程式碼開發平臺開發完成的功能，最終釋出出來後需要呼叫上面這些平臺提供的API介面服務才能夠成功執行。

而低程式碼開發平臺最終從測試環境交付和遷移到生產環境，同樣這些服務能力介面也需要切換到呼叫生產環境BaaS層服務能力。

所以構建企業級低程式碼平臺，你首先要做的是構建企業內部的雲原生技術平臺或者內部的私有云PaaS服務平臺。這個是構建低程式碼平臺的基礎。

否則你最終透過低程式碼平臺開發出來的應用很難是一個企業級應用。

再次強調，低程式碼平臺只是將我們傳統開發業務系統的過程儘量的自動化和可配置化掉了，但是整個自動化過程仍然需要遵循當前的微服務架構，分層，平臺+應用的構建思路。

基於API的規則定製和整合

前面已經談到，我們做的是低程式碼而非零程式碼，是類似國外Mendix低程式碼開發平臺的思路，特別是在規則引擎技術沒有重大突破前，必須要結合自定義程式碼開發。

否則就會出現你寫大量的指令碼程式碼，而這些指令碼在後期更加難以維護。

在10多年前，個人就主持做過類似的CS架構的快速開發平臺產品，當時基本物件，流程，介面設計全部都可以靈活配置。複雜的規則邏輯還提供一個指令碼編輯器來完成。但是最終發現的問題就是指令碼編輯器裡面寫的指令碼越來越多，後期難以維護。

所以對於複雜規則的實現還是需要自己寫程式碼來實現。

開發人員自己開發API並暴露

在低程式碼平臺進行物件建模後，物件最終會生成後臺的資料庫物件和資料表，這些要對開發人員可見。那麼開發人員基於這些資料庫物件可以開發自己的介面API服務。

對於介面的開發，介面服務最終的部署和執行應該獨立管理，也就是還需要提供一個類似API全生命週期管理的一個平臺。這個平臺可以進行API介面的設計，開發，部署和執行管理。開發人員最終開發完成的API介面部署到這個平臺，同時透過一個API閘道器或能力開放平臺統一對外開放能力介面。

而低程式碼開發平臺在進行前端介面設計的時候，可以靈活地去呼叫這些可複用的API介面服務能力來完成複雜邏輯處理。也就是前端介面和API介面服務之間透過簡單的前端指令碼程式碼來完成整合和協同。

多個API介面的組合和編排

在前面文章我已經談到過，一個好的低程式碼開發平臺應該提供一個視覺化的微服務API介面編排的工具，進行服務的組裝和編排工作。

舉個簡單的例子，當你提交一個採購訂單的時候，需要進行預算控制，平臺層本身提供了預算控制API介面服務，但是需要輸入專案編碼。因此首先要根據採購訂單號查詢到專案編碼，然後再去呼叫預算控制服務。

而基於採購訂單號查詢專案編碼本身又是另外一個API介面。那麼就需要對兩個API介面服務進行組裝和編排。在這種場景下就可以透過前端視覺化服務編排工具來完成介面的組裝和編排工作。而非一定要透過自己編寫程式碼來完成。

門戶和應用整合

最後談下門戶整合方面的內容。還是先從場景和期望的目標出發來談。

對於一個企業往往建設了多個IT系統，在多個系統建設完成後一般會建設一個EIP統一門戶來實現統一認證和單點等。使用者登入門戶後除了看到場景的通知，公告，待辦資訊外。門戶還提供了一個重要功能，即：

所有接入的IT系統的快捷入口連線。透過這個快捷連線可以快速地單點登入到具體的業務系統裡面，比如CRM系統，SRM系統等。

那麼低程式碼開發平臺需要和門戶整合。

簡單來說就是透過低程式碼開發平臺開發完成的應用，在應用最終釋出完成後並透過相關的應用授權配置後，能夠自動的體現到門戶的應用快捷入口處。

門戶授權和應用系統功能授權

門戶授權和應用系統裡面的功能選單和資料授權是兩個概念。

門戶授權要解決的問題是某一個使用者是否能夠使用某個系統，比如張三能否使用CRM系統，而CRM系統裡面的授權要解決的問題是張三能夠使用CRM系統裡面的哪些功能選單。

因此當開發者在低程式碼平臺建立了CRM這個應用後。首先要做的一個關鍵步驟就是在門戶裡面自動化註冊CRM這應用，並CRM也自動完成和門戶的單點整合。如果是已有應用接入門戶，你會看到是門戶管理員手工在門戶裡面進行應用註冊和配置。

開發者本身可以自動授權可以使用這個應用，但是其它哪些使用者能夠使用CRM應用則需要在門戶裡面進行授權處理。

只有授權後的使用者在登入門戶後的快捷選單才能夠看到該應用。剩餘的具體功能選單授權則是透過進入到具體的應用系統裡面的系統管理功能來完成。

對於應用裡面的系統管理功能也是4A的一個關鍵內容。那麼這個系統管理也需要考慮多種租戶架構，各個應用系統裡面的系統管理基礎資料和配置要做到完全隔離。

低程式碼開發平臺關注的是具體業務功能，對於常用的組織，人員，使用者這些資訊統一都應該作為門戶的底層基礎資料能力提供給低程式碼開發完成的應用。而不是在低程式碼開發平臺完成的應用中還單獨搞一套基礎系統管理功能。