从零搭建企业级低代码平台全栈开发指南

本文以「鲁班低代码平台」为例，给出一套可落地的企业级低代码平台全栈架构与实现路线：从组件库、设计器与运行时渲染（Render），到接入层 BFF，再到主后端 luban-backend（Java：Spring Boot + MyBatis + Redis + MySQL），最后覆盖管理后台与对外站点的交付形态。

文章目标不是“把所有代码一次写完”，而是帮你用清晰的边界把系统搭起来，并能在后续迭代中持续演进。

1. 系统全貌：六库分工，边界固定

鲁班平台由多个独立仓库组成（强烈建议保持拆分），各自职责如下：

• luban-ui：底层组件库（基础组件 + 低代码组件 + 设计器 + Render 运行时）。不包含管理后台应用。
• luban-backend（主后端）：Java 实现（Spring Boot + MyBatis + Redis + MySQL）。提供站点、页面、用户、系统设置等原子化接口；平台 API 权威文档在本仓库维护（luban-backend/docs/API.md）。
• luban-backend-go：与主后端同契约的 Go 实现，可作为参考或备用运行时。
• luban-bff：Node 接入层（API Gateway）。对前端提供统一接口，对内通过 BACKEND_BASE_URL 调用 luban-backend；负责认证上下文注入（Header）与必要的协议/聚合适配。
• luban：系统管理后台。负责站点接入、页面创建与管理、发布等运营能力。
• luban-website：对外站点（Nuxt 3 SSR）。根据 URL 从 BFF 拉取已发布页面 schema，交给 Render 运行时渲染。

整体调用关系可以理解为：

这套拆分的核心收益是：后端契约稳定、接入层可控、前端（管理后台/对外站点）都只关心“拿到 schema 并渲染”。

2. 数据模型：站点 / 页面 / 用户 / 系统设置

后端以四类领域模型为主（详见 luban-backend/docs/API.md）：

• Site（站点）：id / name / slug / baseUrl / status / createdAt / updatedAt
• Page（页面）：id / siteId / name / path / status(draft|published) / schema(JSON) / createdAt / updatedAt
• User（用户）：id / username / name / role(admin|user) / status(active|disabled) / password(bcrypt) / createdAt / updatedAt
• SystemSettings（系统设置）：单行 JSON，承载系统级配置（站点名称、Logo、安全策略等）

关键约束：

• site.slug 全局唯一（用于对外站点寻址与运营管理）
• 同一站点下 page.path 唯一（用于路由映射，如 /home）
• page.status 决定能否被对外公开接口返回（只允许 published）

3. 主后端：luban-backend（Spring Boot + MyBatis + Redis + MySQL）

3.1 为什么主后端选择 Java 版？

在企业级场景中，后端往往需要更成熟的：

• 规范化分层与扩展（Controller/Service/Mapper）
• 统一错误模型与可观测性（日志、链路、异常处理）
• 权限与审计能力的演进空间（RBAC、资源级权限）

因此将 luban-backend 定位为主后端，并把 API 文档固化为权威契约（luban-backend/docs/API.md），可以显著降低多端联调与跨团队协作成本。

3.2 MySQL：业务真相源（Source of Truth）

MySQL 存储核心业务数据（sites/pages/users/system_settings）。典型落地建议：

• id：UUID（便于分布式与跨系统整合）
• 时间：统一 ISO 8601 输出；数据库使用 DATETIME/TIMESTAMP 按团队习惯定
• schema：JSON（MySQL JSON 类型或 TEXT 存储均可，视查询需求）

3.3 Redis：配置缓存与热点加速

Redis 在鲁班平台中非常适合做两件事：

• 系统设置缓存（SystemSettings）：读多写少、强时效要求不高
• 页面/站点热点缓存：对外站点高 QPS 时，按 siteSlug + path 做短 TTL 缓存

注意：缓存只是加速层，最终一致性以 MySQL 为准。

3.4 认证与授权：Header 上下文（由 BFF 注入）

平台采用“BFF 负责认证，后端负责授权”的分工：

• BFF 完成登录态校验、JWT 验证、会话管理等
• BFF 把用户上下文注入到后端请求 Header：
  • X-User-ID
  • X-User-Role（admin/user）
• 后端只做明确角色字段的权限判断（例如 role == 'admin'），禁止用 username == 'admin' 之类的逻辑“猜权限”

这种模式的优势是：后端保持原子化与领域内聚，接入策略（Web/APP/小程序、不同会话方案）都能在 BFF 层演进。

3.5 API 契约：以 luban-backend/docs/API.md 为准

平台后端 API 的权威文档在：

• luban-backend/docs/API.md

建议团队立下硬规则：

• 先改文档，再改实现（避免“实现已变但文档没更新”的长期技术债）
• BFF 与前端以文档为对接规范
• luban-backend-go 只做契约一致性参考/备用

4. 接入层：luban-bff（对外统一接口、对内调用后端）

BFF 的职责通常包括：

• 对管理后台提供 /api/*（需要登录与权限）
• 对对外站点提供 /api/public/*（无需登录）
• 统一错误格式、跨域策略、限流、熔断、重试（按需）
• 把后端多接口聚合为前端易用的接口（但避免把领域逻辑搬到 BFF）

4.1 对外站点的“公开页面接口”

对外站点必须能按 URL 获取已发布页面 schema。鲁班采用“后端公开接口 + BFF 转发”的方式：

• 后端（无需鉴权）：GET /backend/public/sites/:slug/pages?path=:path
• 行为：只返回 status=published 的页面（含 schema）；找不到返回 404

这样 luban-website 永远不用直连后端，也不需要 JWT。

5. 组件库与运行时：luban-ui（Designer + Render）

低代码平台的前端能力通常分三层：

• 基础组件（按钮、输入框、布局等）
• 低代码组件（可被 schema 描述、可在运行时渲染的组件）
• 运行时渲染（Render）：把 PageSchema 转成真实组件树渲染

鲁班里，luban-website 与 luban（管理后台）都通过 luban-ui 的 Render 能力渲染页面。对外站点只用运行时，不引入设计器。

在工程规范上，建议保持：

• 统一设计语言（Material Design 风格、响应式）
• 组件库产物必须生成 TS 类型声明
• 新增/修改组件必须补齐单元测试与 e2e 测试（按仓库约束执行）

6. 管理后台：luban（站点与页面的生产工具）

管理后台典型能力链路：

1. 站点管理：创建/编辑站点（slug/baseUrl/status）
2. 页面管理：创建页面、编辑 schema、保存草稿、发布（draft/published）
3. 用户管理：账号与角色（admin/user）、禁用/启用
4. 系统设置：系统级配置（可落 Redis 缓存）

管理后台不直接访问后端：统一走 BFF，方便认证与策略收敛。

7. 对外站点：luban-website（Nuxt 3 SSR + Render）

对外站点是“把 schema 变成可访问网页”的交付面：

• 输入：siteSlug + path
• 输出：SSR/CSR 渲染后的 HTML 页面

基本流程：

1. 浏览器访问某 URL
2. Nuxt 调用 BFF public 接口获取页面数据（含 schema）
3. 把 schema 传给 Render 组件（如 LubanPage / RuntimeRenderer）渲染

在企业实践中，SSR 的价值在于：

• 更好的首屏与 SEO
• 更稳定的多端渲染体验

8. 工程化建议：测试、发布、演进

8.1 测试策略（建议最小闭环）

• 后端：接口级测试（鉴权/权限/404/冲突码 409 等关键分支）
• BFF：契约测试（确保转发/聚合不破坏后端语义）
• UI：组件单测 + 关键交互 e2e（设计器拖拽、运行时渲染）
• Website：最少做一条端到端链路（访问 URL -> 拉取 schema -> Render 出页面）

8.2 发布策略（推荐分层）

• luban-backend：独立部署（容器化），MySQL/Redis 作为依赖
• luban-bff：独立部署（容器化），通过环境变量指向后端
• luban：静态资源部署（或容器化 Nginx）
• luban-website：SSR 服务部署（Node 进程/容器），通过环境变量指向 BFF

8.3 演进路线（从 MVP 到企业级）

• MVP：站点 + 页面 + 发布 + 对外访问闭环
• 第 2 阶段：组件市场、权限细化（资源级）、审计日志
• 第 3 阶段：多租户、灰度发布、CDN/缓存、页面渲染性能优化

9. 小结

一套可持续演进的低代码平台，关键不在“把所有功能都塞进一个仓库”，而在于：

• 边界清晰：luban-backend 做领域与授权，BFF 做接入与认证，前端只管渲染与交互
• 契约稳定：以 luban-backend/docs/API.md 作为权威 API 文档
• 渲染复用：luban-ui 的 Render 运行时同时服务管理后台与对外站点

如果你正准备从零落地企业级低代码平台，建议先把“站点-页面-发布-对外访问”闭环跑通，再逐步增强设计器能力与企业级治理能力。