低代碼平臺技術架構白皮書

一、概述

低代碼開發平臺這幾年火得不行，從Gartner的報告來看，到2025年全球低代碼開發平臺市場規模預計將達到約470億美元（資料來源：Gartner, 2023）。國內這邊，信通院的調研也顯示，超過60%的企業已經在用或者正在評估低代碼平臺（資料來源：中國信通院《低代碼發展白皮書（2023）》）。

算數科技作為低代碼平臺一級渠道商，在大量企業落地實踐的基礎上，把平臺的技術架構梳理成了這份白皮書。目的很直白——讓技術決策者搞清楚低代碼平臺到底是怎麼運作的，而不是只看到表面的拖拽介面。

本白皮書覆蓋五個核心部分：前端渲染引擎、後端服務架構、資料層設計、AI能力整合層和安全架構。每一層都不是簡單堆砌技術名詞，而是在實際專案中反覆驗證過的方案。

二、前端渲染引擎

低代碼平臺的前端渲染引擎是整個平臺的"面子"，直接決定了使用者體驗。我們採用的是基於JSON Schema的宣告式渲染方案，說人話就是：頁面的結構、樣式、行為全部用JSON描述，引擎負責把這些JSON翻譯成真實的DOM節點和互動邏輯。

2.1 渲染引擎核心設計

渲染引擎的核心是一個Schema解析器和一個元件登錄檔。Schema解析器接收JSON配置，遞迴遍歷節點樹，根據每個節點的type欄位查詢元件登錄檔中對應的元件例項，然後建立React元件並注入props。這個過程看起來挺簡單，但要在效能上做到不卡頓，需要做不少最佳化。

首先是虛擬DOM的diff最佳化。我們用的是React 18的Concurrent模式，結合memo和useMemo做了元件級別的快取。對於大型表單（100+欄位），渲染時間能控制在200ms以內。其次，元件登錄檔用了懶載入機制——只有頁面實際用到的元件才會被下載和註冊，初始載入包體積控制在150KB（gzip後）以內。

2.2 拖拽編排引擎

拖拽編排是低代碼平臺的標誌效能力。我們的拖拽引擎基於HTML5 Drag and Drop API做了一層封裝，支援巢狀容器拖放、對齊線輔助、撤銷重做。編排過程中產生的操作會實時同步到JSON Schema，也就是說，使用者拖的每一步都有據可查，可以序列化、可以回放。

2.3 自定義元件擴充套件

平臺內建了80+常用元件（表單控制元件、佈局容器、資料展示、圖表等），但企業級場景總有定製需求。自定義元件透過標準的元件協議接入——只要實現了render方法和getPropertyConfig方法，就能註冊到平臺中被拖拽使用。元件協議相容React和Vue，這塊設計參考了阿里LowCode Engine的元件規範（參考：阿里低代碼引擎開源協議規範）。

三、後端服務架構

後端這塊，我們沒有搞什麼花哨的東西，就是老老實實用Spring Cloud微服務架構。為什麼不用單體？因為低代碼平臺天然需要支援多租戶、多應用、多場景，單體架構在擴充套件性上會很快碰到天花板。IDC的報告也指出，採用微服務架構的企業應用平臺在迭代效率上比單體架構高出40%以上（資料來源：IDC《企業低代碼開發平臺評估指南, 2023》）。

3.1 微服務拆分策略

我們按業務域來拆服務，而不是按技術層。每個服務有獨立的資料庫、獨立的部署單元，服務之間透過REST API或訊息佇列通訊。下表列出了核心服務的職責劃分：

3.2 服務治理

服務註冊發現用的Nacos，配置中心也是Nacos——一個元件搞定兩件事，省心。服務間呼叫走OpenFeign，熔斷降級用Sentinel。鏈路追蹤整合了SkyWalking，請求從閘道器進來一直到資料庫執行SQL，全鏈路視覺化。

有一點值得說一下：我們的限流不是在閘道器層一刀切，而是做了分級限流。閘道器層做全域性QPS限流（保護整個叢集），服務層做介面級限流（保護單個服務），資料庫層做連線池限流（保護儲存）。三層限流各司其職，不會出現"一刀切導致正常請求被誤殺"的問題。

四、資料層設計

資料層是低代碼平臺最容易出問題的地方。因為低代碼平臺要支援各種各樣的業務場景，資料結構千差萬別，不可能給每個應用都建一套表。我們的方案是多源異構資料統一管理。

4.1 資料來源介面卡

平臺內建了多種資料來源介面卡，透過統一的DataSource抽象層對接：

4.2 動態資料建模

使用者在平臺上建立的資料模型，底層會自動生成對應的資料庫表。欄位型別對映做了精心設計——比如平臺上的"富文字"型別對映為MySQL的LONGTEXT，"附件"型別對映為JSON（儲存檔案後設資料）。關聯關係透過外來鍵約束+應用層校驗雙重保障。

對於高頻查詢場景，系統會自動分析SQL執行計劃，建議新增合適的索引。這個功能不是我們自己拍腦袋做的，是參考了Percona的慢查詢分析工具的思路。

五、AI能力整合層

AI能力整合是算數科技平臺區別於傳統低代碼工具的核心差異化。我們把AI能力封裝成獨立的微服務，透過標準API暴露給平臺其他模組呼叫。這樣做的好處是AI模型可以獨立升級，不影響業務服務的穩定性。

5.1 大模型對接架構

AI服務層支援對接多種大語言模型，包括OpenAI GPT系列、百度文心一言、阿里通義千問、智譜GLM等。透過統一的LLMAdapter介面，上層業務程式碼不需要關心底層用的是哪個模型。切換模型只需要改配置，程式碼零修改。

模型選擇策略上，我們做了A/B測試機制——同一請求同時發給兩個模型，對比響應質量和延遲，自動選擇最優結果。這個機制讓平臺的AI能力始終能用上效果最好的模型。

5.2 NL2SQL自然語言轉查詢

這是最受使用者歡迎的AI功能之一。使用者用自然語言描述想查什麼資料，AI自動生成對應的SQL語句。技術上用了Few-shot Prompt + Schema注入的方案——把資料庫的表結構、欄位含義、已有查詢示例作為上下文餵給大模型，生成的SQL準確率在內部測試集上達到了87%。

當然，NL2SQL不能直接執行生成的SQL，必須經過SQL語法校驗和許可權檢查兩道關卡。許可權檢查會校驗當前使用者是否有權訪問涉及的表和欄位，防止越權查詢。

5.3 智慧表單識別

使用者上傳一張紙質表單的掃描件，AI自動識別表單欄位並生成對應的數字化表單配置。底層用了OCR + LayoutLMv3的文件理解模型，欄位識別準確率92%以上。這個功能在政務和製造業場景特別受歡迎。

六、安全架構

安全是低代碼平臺的生命線。我們在架構設計階段就把安全考慮進去了，不是事後打補丁。安全架構覆蓋傳輸層、應用層、資料層三個維度。

6.1 傳輸安全

所有API通訊強制HTTPS，證書用Let's Encrypt自動續期。內部服務間通訊走mTLS（雙向TLS認證），防止內網被突破後的橫向移動。API閘道器層配置了HSTS、X-Frame-Options、X-Content-Type-Options等安全響應頭。

6.2 應用安全

認證採用OAuth2 + JWT方案，access_token有效期2小時，refresh_token有效期7天。許可權模型用的是RBAC（基於角色的訪問控制），支援角色繼承和許可權組合。多租戶隔離採用"邏輯隔離+行級許可權"方案——每條資料都帶tenant_id，查詢時自動注入租戶過濾條件，確保租戶間資料絕對隔離。

輸入校驗方面，所有API引數都經過白名單校驗和XSS過濾。SQL查詢全部使用預編譯語句（PreparedStatement），從根本上杜絕SQL隱碼攻擊。檔案上傳做了型別白名單、大小限制和病毒掃描三重防護。

6.3 資料安全

敏感資料（密碼、金鑰、身份證號等）在資料庫中加密儲存，加密演算法用AES-256-GCM。審計日誌記錄所有關鍵操作（誰在什麼時間做了什麼），日誌保留180天，支援按時間、使用者、操作型別檢索。

資料備份策略是"每日全量+每小時增量"，備份檔案加密後儲存到異地。恢復演練每季度執行一次，確保RTO（恢復時間目標）不超過4小時。

資料來源說明：本白皮書引用的市場資料和行業趨勢來自 Gartner《Magic Quadrant for Low-Code Application Platforms, 2023》、IDC《企業低代碼開發平臺評估指南, 2023》以及中國信通院《低代碼發展白皮書（2023）》。技術方案部分基於算數科技實際生產環境實踐總結。

七、技術選型對比

在架構設計過程中，我們對幾個關鍵技術的選型做了對比分析：

八、總結

低代碼平臺的技術架構不是什麼神秘的東西，本質上還是前後端分離+微服務+多租戶這套組合拳。真正的門檻在於：怎麼把這套架構做到足夠穩定、足夠靈活、足夠安全，讓企業敢把核心業務跑在上面。算數科技在這份白皮書中分享的每一個技術決策，都是在實際專案中踩過坑、做過取捨之後的結果。

如果你對某個具體技術點有疑問，或者想了解平臺在你的業務場景下怎麼落地，歡迎聯絡我們的技術團隊：cooper@micount.cn，電話 18016313342。