用 Spring Cloud Alibaba 搭多租户后台的快速开发平台（yudao-cloud）

后台管理系统这类项目，功能堆到一定程度都会撞上同一堵墙：单体应用里塞进权限、工作流、支付、商城、报表，团队一扩大，改一个模块要回归测试半个系统。yudao-cloud 是 ruoyi-vue-pro 的微服务重写版本，把原来一个工程里的功能按业务域拆成独立服务，用 Spring Cloud Alibaba 这套技术栈重新组织。

yudao-cloud 是一套用 Java 写的 Spring Cloud Alibaba 微服务后台开发平台，覆盖权限、工作流、支付、商城、CRM、ERP、AI 大模型等模块，开发团队可以拿它当基座，用代码生成器产出前后端代码后直接运行。

仓库按 JDK 版本分了三套分支：master 对应 JDK 8 + Spring Boot 2.7，master-jdk17 对应 JDK 17/21 + Spring Boot 3.5，master-jdk25 对应 JDK 25 + Spring Boot 4.x。另外还有只保留系统功能与基础设施功能的精简版，方便不想要全套模块的团队。GitHub 上的数据是 19585 Star、4894 Fork、345 Watcher，开放 Issue 3 个，采用 MIT 许可证，主要语言 Java（63.4%），PLpgSQL 占 31.2%。仓库地址是 https://github.com/YunaiV/yudao-cloud。

它怎么做到的

从仓库根目录能看出整体拼图。yudao-gateway 是所有外部请求的入口，yudao-module-* 是按业务域拆开的二十来个服务模块，yudao-server 负责把它们组装成一个可启动的进程，yudao-framework 放公共能力，yudao-dependencies 统一管理依赖版本，yudao-ui 放前端工程。

一次请求的路径大致是这样：请求先到网关，网关做鉴权与路由，再转发到对应的业务服务。服务之间的注册与配置由 Nacos 承担，调用链路的保障交给 Sentinel，跨服务的分布式事务交给 Seata，定时任务由 XXL-Job 调度。业务数据通过 MyBatis Plus 落到 MySQL、Oracle、PostgreSQL、SQL Server、MariaDB、达梦 DM、TiDB 等数据库，Redis 加 Redisson 负责缓存，消息可以走 Event、Redis、RabbitMQ、Kafka、RocketMQ。

结果的出口写得很明确：代码生成器一键产出 Java、Vue 前后端代码、SQL 脚本与接口文档；前端提供 Vue3 + element-plus 和 Vue3 + vben（ant-design-vue）两个电脑端版本；移动端用 uni-app 一套代码适配 APP、小程序、H5。服务之间更细粒度的调用约定，README 前段没有展开说明，仓库里也没有给出完整的链路时序图。

几个关键设计

按业务域切模块

目录结构里能数出一长串独立模块：yudao-module-system、yudao-module-infra、yudao-module-bpm（工作流）、yudao-module-pay、yudao-module-mall、yudao-module-member、yudao-module-crm、yudao-module-erp、yudao-module-mes、yudao-module-wms、yudao-module-hrm、yudao-module-fms、yudao-module-pms、yudao-module-oa、yudao-module-ai、yudao-module-iot、yudao-module-im、yudao-module-mp、yudao-module-report。每个模块有自己的工程与业务能力，也可以单独打包成服务部署。

这个拆法解决的是功能边界问题：商城改价不会碰到 ERP 的库存逻辑。代价在于模块数摆在那里，谁想只用一个子集，就得自己动手裁。

多租户的底层封装

项目支持 SaaS 多租户，每个租户可以有独立权限，README 把它描述为「透明化的多租户底层封装」。透明意味着业务代码层不容易感知租户过滤的存在，好处是写业务时不用反复处理租户字段，坏处是这个假设渗透得比较深。

Issue 区里有两条相关记录可以印证：「租户的请求未传递」和「工作流模块不支持多租户关闭」，两条都标记为已解决。第二条说明的正是这个问题——有些模块的设计以多租户为前提，想关掉它并不是改一个开关的事。

完整版与精简版双轨

README 列了两个仓库：完整版 yudao-cloud 与精简版 yudao-cloud-mini，各自再按 JDK 版本分三个分支。完整版包含系统功能、基础设施、工作流程、支付系统、数据报表、微信公众号、商城系统、会员中心、ERP、WMS、CRM、MES、HRM、FMS、PMS、OA 协同办公、AI 大模型、IoT 物联网、IM 即时通讯；精简版只留系统功能与基础设施功能。

两个仓库之间靠迁移文档打通，README 给出的说法是「只需要 5-10 分钟，即可将完整版按需迁移到精简版」。这套双轨制的用意是让选型不卡在第一步：先用精简版跑起来，需要哪个模块再迁哪个。注意这是工程级裁剪，不是运行时的插件开关，迁移动作会动到代码与依赖。

代码生成器

代码生成器是这个平台提高开发效率的主要抓手，能一键生成 Java、Vue 前后端代码、SQL 脚本、接口文档，支持单表、树表、主子表三种表结构。Issue 里提到两个与它相关的真实问题：主键字段不叫 id（例如叫 item_id）时，生成的 vm 模板会报错；导出 Excel 时 Long 类型的 ID 会丢失精度。两条都已解决。

这样设计的代价

第一项代价来自依赖栈的长度。要在本地把整套跑起来，需要 Nacos 做注册与配置、Sentinel 做服务保障、Seata 处理分布式事务、XXL-Job 调度定时任务、Redis 做缓存，再加 MySQL 之类的数据库。这是一条不短的中间件清单，任何一环没准备好，服务就起不来。

第二项是仓库体量。仓库体积 60812 KB，最新版本的统计是总代码行数 647011、源码 416656 行、注释 135879 行、单元测试用例 4285 个。clone 下来和让 IDE 建索引都不是轻量操作。

第三项是多分支维护。三套 JDK 与 Spring Boot 组合意味着同一处改动往往要在三个分支上对齐，团队选型时必须先想清楚自己锁在哪一档，中途换档的成本不低。

第四项是微服务化本身带来的性能与排查成本，这一项有实际案例。Issue 区里有人把老项目迁到 yudao cloud，原接口是毫秒级，迁移之后降到 10s、20s、30s+。这个接口的特点是 SQL 语句很长但响应很快、返回数据量大、层次结构多而深。作者排查后定位到与一项默认开启的配置有关，该 Issue 已解决。另一条「infra 模块内存溢出」也已解决。

同类项目横向对照

如果团队只要一套能跑起来的权限管理后台，或者成员里没人碰过 Nacos、Seata 这类组件，yudao-cloud 的模块数量与中间件清单会先变成负担，这时候 RuoYi-Cloud 更贴近需求本身，装起来要处理的东西更少。反过来说，需要商城以外的 ERP、MES、AI 模块时，mall-swarm 只覆盖电商链路，补不齐其他部分，这也是它作为同类项目的边界。

对你的实际影响

选分支这件事要在动手前定下来。团队如果还在 JDK 8 上，用 master；升到 JDK 17 或 21 就用 master-jdk17；只有确定要上 JDK 25 + Spring Boot 4.x 才选 master-jdk25。选错分支的返工成本，远高于一开始多花十分钟确认。

机器资源的账要提前算。仓库里没有给出最低配置要求，但服务数加中间件数量摆在这里，本机同时起网关、若干业务模块、Nacos 和 Redis，开发机的内存要按这个规模准备，而不是按单体后台应用的预期准备。

后期改动的影响面也值得掂量。多租户、权限、数据权限都封在 yudao-framework 这一层，业务模块跟着这套约定走。要往平台里塞一个本来就带着自己权限体系的旧系统，改造成本会集中在适配层；Issue 里那条迁移后接口变慢的案例，就属于这种情况，最后落点在一项默认开启的配置上。

这套基座适合正在做多租户 SaaS 后台、需要工作流与商城等模块开箱可用、并且团队已经熟悉 Spring Cloud Alibaba 的后端团队。它不适合只想找一套轻量权限管理后台的人，也不适合不打算引入 Nacos、Seata 等中间件的团队。项目采用 MIT 许可证，个人与企业都可免费使用，Star 19585 可以作为社区活跃度的一个参照。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.5 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。