若依SpringCloud微服务实战：从环境搭建到部署上线全记录

记录若依SpringCloud版本先说结论若依的SpringCloud版本不是一个简单的单体改微服务的换壳项目而是一套把Spring Boot单体能跑的功能全部拆开、重新按微服务方式组织的完整脚手架。我前后用了大概一个半月把它从拉代码到跑通、再到实际改动上线这中间踩了不少坑也理顺了不少以前对微服务只知其名不知其所以然的地方。这篇文章就当作一份实战记录把我这段时间对若依SpringCloud版本的认知、操作过程、遇到的问题和解决办法都写下来。如果你准备入手这个项目或者正处在单体项目想向微服务演进但不知道从哪下手的阶段这篇记录应该对你有参考价值。我会按照实际动手的顺序来写环境准备、启动踩坑、核心模块逻辑、数据库改造、前端联调、部署上线最后再聊聊若依接AI这个近期比较热门的方向。整个过程里我会把关键配置、命令和错误信息都贴出来方便你对照排查。1. 为什么选若依SpringCloud版单体不够用重写又太贵先说清楚一个事如果你只是做个后台管理系统、小程序管理端、内部工具平台单体版的若依完全够用没必要上微服务。微服务带来的分布式事务、服务治理、链路排查成本在小团队或者小项目里就是纯粹的负担。但有几个现实场景单体版确实顶不住多个团队同时开发单体应用里代码冲突频繁到没法干活某个模块的并发量远高于其他模块想单独扩缩容却拆不出去不同业务模块有不同的数据库、不同的技术栈诉求需要对接外部系统但不想把整个系统的认证、权限都暴露出去当时我所在的项目就卡在这几条上一个系统里既有核心交易流程又有OSS文件处理、CMS内容管理还有给外部合作方调的OpenAPI接口。功能全挤在一个Spring Boot应用里每次发版都是全员配合生产环境一台机器扛所有流量出了性能问题只能整体扩容成本高还见效慢。于是我把单体若依和SpringCloud版若依做了个对比最终选了后者理由很实际对比维度单体版若依SpringCloud版若依服务拆分粒度单应用模块化分包gateway auth system file job等独立服务注册配置中心无单机配置Nacos统一配置管理网关路由无直接HTTP访问Spring Cloud Gateway统一入口服务间调用直接注入调用OpenFeign远程调用认证鉴权单应用Session/JWT网关统一鉴权 JWT无状态认证部署方式单Jar包 Nginx多服务独立部署或容器编排数据库单库可按服务分库也支持多数据源当然我也做好了心理准备微服务的复杂度是实打实的尤其是启动顺序、配置同步、服务间调用这些坑不亲自踩一遍根本记不住。事实证明前两周我几乎每天都在跟Nacos、Feign和网关打交道。1.1 若依SpringCloud版到底解决了什么聊到若依SpringCloud版我最想强调的一点是它的核心价值不是把单体拆成多个进程这个动作本身而是拆完之后它顺手解决了几个老大难问题。第一个是多服务下的统一认证。单体时代登录态放Session里服务一拆Session就不共享了。若依微服务版引入了一个认证中心ruoyi-auth专门负责登录、颁发Token其他服务通过网关统一校验Token实现了一次登录全局通行。这在同一公司的多个内部系统打通时非常香很多团队做单点登录改造时甚至直接参考若依的auth模块思路。第二个是网关层的统一入口。所有请求先到Gateway再按路由规则转发到具体服务。这样带来的直接好处是前端只需要知道一个域名后端把服务拆成什么样、内部地址怎么变前端完全不用关心。你在Nacos里调整路由规则、做灰度发布、限流熔断都是在网关层操作不用动业务代码。第三个是配置集中化。单体项目改配置要改文件、重启应用微服务项目几十个配置散落各处更是灾难。若依微服务版把所有服务共用一套Nacos配置改了配置推送到各个服务不用挨个重启这个体验用过就回不去了。1.2 技术栈全景各个组件在项目里的真实角色在动手拉代码之前我先把若依SpringCloud版的技术栈过了一遍。这里我不想只罗列技术名词更想告诉你每个组件在项目里到底扮演什么角色方便你后面看代码时对号入座。Spring Cloud Gateway整个系统的大门负责路由转发、跨域处理、统一鉴权。你在前端调的所有接口包括登录都是先打到它这里。Nacos注册中心 配置中心。所有服务启动后会注册到Nacos服务之间通过服务名互相发现各服务的配置也统一放在Nacos里支持动态刷新。OpenFeign服务与服务之间的电话线。比如system服务需要调用file服务上传文件直接用Feign接口声明式调用像调本地方法一样。Sentinel流量哨兵。主要用来做限流、熔断、降级。若依把它接在了网关和部分核心链路上防止突发流量打垮服务。Spring Security OAuth2 JWT认证授权体系。auth服务负责颁发JWT Token网关解析Token并校验权限服务之间通过Token传递用户身份。Redis缓存 Token存储。登录后的用户信息、验证码、在线用户列表都存在Redis里。RabbitMQ可选异步消息。若依微服务版预留了消息队列的对接比如操作日志、异步任务可以走MQ解耦不用的团队可以不启用。MyBatis 多数据源系统库与业务库隔离。ruoyi-system默认连的是主库你也可以配置动态数据源来连其他业务库。记住这个全景之后你再去看代码就不会一头雾水。我拉下来第一个反应是怎么这么多模块但理清楚网关做路由、auth做认证、system做用户权限、file做文件、job做定时任务之后整个架构就清晰了。2. 从零拉取到启动成功一天半的趟坑记录这一节是纯实战记录我详细说说从拉取若依SpringCloud版代码到把服务全部启动成功的完整过程包括我踩过的坑和最终的解决办法。如果你正准备入手上手这套框架这一段应该能帮你节省至少两天时间。2.1 环境准备与版本对照JDK、Maven、MySQL、Nacos一个都不能错若依官方文档要求的环境很简单JDK 1.8、Maven 3.x、MySQL 5.7/8.0、Redis、Nacos。但版本兼容这四个字在微服务场景下能把人折磨死。我一开始用的JDK是11启动gateway时报了一个奇怪的反射错误后来查资料发现是高版本JDK对某些旧依赖反射访问限制导致。换成JDK 8之后问题消失。所以如果你不想折腾直接用JDK 8最稳。Maven建议用3.6.3及以上太低的话依赖解析容易出问题。我用的3.8.x没有遇到明显问题。另外因为国内网络原因Maven中央仓库拉取Spring Cloud相关依赖很慢强烈建议在settings.xml里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirrorMySQL我选了5.7这是若依官方推荐的版本兼容性最好。如果你用MySQL 8.0需要注意驱动和时区配置后面专门讲。Redis方面Windows下我试过用tporadowski的Redis发行版Linux下直接用apt或yum装即可。Redis没有版本强要求但千万记得设置密码后在若依的配置里同步修改否则服务启动报Unable to connect to Redis。最后是Nacos它在这个项目里有两个角色注册中心和配置中心。若依官方给的Nacos版本是1.4.2或2.x我第一次用2.2.0也顺利跑通了但后来发现2.x的鉴权机制默认开启配置不对会导致服务注册不过来建议新手直接按官方文档用1.4.2。如果是生产环境再考虑升级到2.x并做好鉴权配置。2.2 IDEA导入报错error adding module to project: null的根因这个报错在搜索热词里出现频率非常高我也被它卡了一个小时。现象是这样的从Git拉取若依SpringCloud版代码后用IDEA的File - New - Project from Existing Sources选择根目录ruoyi-cloud导入IDEA分析完Maven模块后弹出错误框提示error adding module to project: null我第一次看到这个错误时以为是代码或Maven配置问题反复reload Maven项目都没用。后来仔细检查才发现问题出在根目录的pom.xml里声明的模块列表和实际目录不一致。若依SpringCloud版的根pom.xml写了如下模块modules moduleruoyi-common/module moduleruoyi-gateway/module moduleruoyi-auth/module moduleruoyi-modules/module /modules而ruoyi-modules是一个父模块里面又包含多个子模块比如ruoyi-system、ruoyi-file、ruoyi-job。IDEA在导入时如果发现父子模块嵌套层级没理清就会报这个null错误。解决办法有几种我用的是最直接的一种不做New from Existing Sources直接Open文件夹作为项目打开让IDEA识别pom.xml后用Maven方式导入。如果还是报错关掉IDEA删除项目根目录下的.idea文件夹和所有模块下的target文件夹重新打开。如果仍然报错执行一次mvn clean install -DskipTests手动编译确认依赖能正常拉取后再次reload Maven项目。我实测下来用Open方式打开、而不是Import方式可以绕开大部分IDEA导入问题。主力开发IDEA的人应该都遇到过类似问题大概率是IDEA的Maven工程模型解析和项目里的嵌套模块结构没对齐导致的。2.3 Nacos配置与启动顺序不改这个服务永远注册不上成功导入项目后接下来要做的就是启动Nacos、初始化数据库然后按顺序启动各个服务。但这里有个最容易踩的坑如果你不修改配置文件里的Nacos地址服务根本注册不上。若依SpringCloud版的默认配置里Nacos服务地址是localhost:8848。如果你在本地启动Nacos这没问题。但如果你用云服务器或者Docker容器里的Nacos就得改配置。问题是配置不只有一个地方你需要在以下位置修改Nacos地址各服务自己的bootstrap.yml里的spring.cloud.nacos.discovery.server-addrNacos配置列表里ruoyi-*.yaml这些配置的数据库、Redis连接信息这里我特别说一下启动顺序。微服务启动有依赖关系不按顺序来会各种连不上先启动MySQL和Redis确认连接正常启动Nacos访问http://localhost:8848/nacos能看到控制台初始化数据库后启动ruoyi-gateway启动ruoyi-auth最后启动ruoyi-modules下的各个模块如果你先启动了system服务它会尝试注册到Nacos但此时网关还没起来不影响注册。真正的坑在于system服务启动时要连数据库而数据库脚本没导入、或者数据库配置不对会导致启动失败且反复重试。所以务必先确认数据库连接没问题。数据库初始化这一步也单独提醒一下。很多人会直接去执行ry_202X.sql但若依微服务版其实是多数据库/多数据源设计的根目录的sql文件夹下有多个脚本ry_202X.sql框架核心表包含用户、角色、菜单、字典等ry_config.sqlNacos配置需要初始化到数据库里的表如果用数据库存储配置时需要quartz.sql定时任务相关表我第一次只导入了ry_202X.sql结果quartz相关表缺失ruoyi-job启动直接报错。把quartz.sql也导入后问题解决。如果你用的是Nacos的配置中心而且是数据库存储模式ry_config.sql也必须导入。3. 核心模块拆解网关、认证、系统服务各自干哪些活跑通之后我开始逐行看核心代码。这一步很值得做因为你只有真正理解了若依微服务版的骨架逻辑后续业务开发才不会被绕晕。3.1 Gateway网关路由、鉴权、跨域、接口文档网关模块ruoyi-gateway是整个系统的入口。它的核心配置在application.yml和Nacos的ruoyi-gateway.yaml里。我看完最大的感受是若依把网关的边界职责划得非常清晰。路由配置长这样spring: cloud: gateway: routes: - id: ruoyi-system uri: lb://ruoyi-system predicates: - Path/system/** filters: - StripPrefix1 - id: ruoyi-auth uri: lb://ruoyi-auth predicates: - Path/auth/** filters: - StripPrefix1关键点有两个。第一uri: lb://ruoyi-system里的lb://表示走负载均衡从Nacos里按服务名找到实例如果有多个实例会自动负载均衡。第二StripPrefix1表示转发时去掉第一段路径前缀。比如前端请求/system/user/list网关会去掉/system转发给ruoyi-system服务的/user/list。网关层的跨域处理也是配置化的ruoyi-gateway.yaml里有如下配置spring: cloud: gateway: globalcors: cors-configurations: [/**]: allowedOriginPatterns: * allowedMethods: * allowedHeaders: * allowCredentials: true注意一个细节如果你改了自己的服务但Nacos里的配置文件没同步更新路由规则是不会变的。我在这里吃过亏改完网关路由后一直不生效后来去Nacos控制台发布配置才刷新。鉴权方面若依在网关层写了一个全局过滤器AuthFilter所有请求进来先解析Header里的AuthorizationToken如果能解析出用户信息就放行并往Header里塞userId、userName等信息解析失败则直接返回401。这意味着下游服务不需要自己解析Token直接从请求头里取用户身份就行大大简化了各业务模块的认证逻辑。接口文档这块若依微服务版把Swagger聚合到了网关层访问/swagger-ui/index.html可以看到所有服务的接口列表。我在搜索热词里看到有人在问若依微服务怎么用swagger核心就是网关聚合各服务的OpenAPI需要每步接口配置好Api注解并让网关知道各服务的swagger路径。如果只想用单服务的Swagger直接访问该服务的/v3/api-docs也行。3.2 认证中心与Token校验从OAuth2代码看流程ruoyi-auth是若依微服务版的认证中心走的是Spring Security OAuth2的授权码/密码模式。但若依并没有把OAuth2那一套代码全堆出来而是做了很多定制。看代码前建议先理解它的Token流程前端请求/auth/login传用户名、密码、验证码auth服务校验验证码从Redis取校验用户名密码远程调用system服务的用户查询接口见RemoteUserService校验通过后auth服务通过TokenService生成JWT Token同时把用户信息以login_tokens:uuid为key存到RedisToken的expiration时间可以和Redis里的key过期时间联动返回Token前端把它放在请求头Authorization: Bearer xxx里网关解析Token确认用户身份有效后放行这里有一个值得单独说的设计Token校验没有全部依赖JWT签名而是结合了Redis存储。JWT本身是无状态的但你无法主动让一个已签发的Token失效。若依的做法是登录时在Redis里存一份登出时删除Redis记录这样可以在不改JWT本身的情况下做到强制下线。这个设计很实用如果完全无状态化在线用户管理、强制踢人这些功能做起来会非常痛苦。看OAuth2相关代码的时候如果对AuthorizationServerConfigurerAdapter不熟悉可能会觉得绕。我的建议是先不看底层框架抓一条主链路/auth/login接口 -SysLoginService.login()-TokenService.createToken()把这条链路的类关系理清楚你已经能应对大部分定制需求了。3.3 业务模块扩展怎么照着system模块新增一个自己的微服务跑通若依微服务版之后大多数人想干的事肯定不只是启动一下看看而是要往里面加自己的业务模块。我在这里讲讲怎么在最省力的情况下扩展出一个新服务。假设你要新增一个ruoyi-order服务管理订单数据。整体操作分为几步在父pom.xml里加模块声明把ruoyi-order加到modules列表里。复制ruoyi-system的结构最省事的做法是复制system模块然后全局替换包名、类名。若依的大部分依赖都在父工程里复制出来的模块基本不会缺依赖。编写自己的bootstrap.yml配置服务名、Nacos地址、端口。在Nacos里新增配置比如新建ruoyi-order.yaml写入数据源、Redis、日志等配置。Nacos是配置中心所以各服务的配置都在这里集中管理。网关加路由在gateway的application.yml或Nacos的网关配置里加一条Path/order/**的路由指向lb://ruoyi-order。这个过程走一遍你就真正体会到微服务模式下新增一个服务的成本比单体低得多。单体里新增模块你的编译、部署单元还是同一个大应用还要小心类冲突和依赖污染微服务模式下新服务独立编译、独立部署完全不影响现有服务。我当时新增了一个业务服务之后顺手把若依自带的RemoteUserService远程调用用了起来。你会发现Feign接口的定义和使用都非常模板化FeignClient(contextId remoteUserService, value RuoYiConstant.SYSTEM_SERVICE_NAME, fallbackFactory RemoteUserFallbackFactory.class) public interface RemoteUserService { GetMapping(/user/info/{username}) RSysUser getUserInfo(PathVariable(username) String username); }其它服务要查用户信息直接注入这个Feign接口就行。但有个细节Feign接口的value必须是目标服务在Nacos里的服务名如果写错运行时会报Unable to find instance for xxx。4. 数据库改库与多数据源最容易翻车的环节跑通框架之后真正进入业务开发第一关就是数据库。若依微服务版默认把所有框架表放在一个库里但实际业务中你往往需要把业务数据和框架数据分开或者一个服务对应一个库。这里面的坑非常多我逐个讲。4.1 SQL脚本导入顺序与常见报错在导入SQL脚本时最常见的报错是ERROR 1064 (42000): You have an error in your SQL syntax或者ERROR 1146 (42000): Table ry-vue.xx doesnt exist前一种通常是MySQL版本或字符集问题。若依的SQL脚本默认带ENGINEInnoDB AUTO_INCREMENTxx DEFAULT CHARSETutf8mb4 COMMENTxxxMySQL 5.7和8.0基本都能直接执行。但如果你的MySQL是5.5以下InnoDB的某些语法不支持建议升级数据库。后一种则是导入顺序问题。比如执行ry_202X.sql之前没建库或建了库但没选中库直接执行。正确的姿势是CREATE DATABASE IF NOT EXISTS ry-cloud DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE ry-cloud; SOURCE /path/to/ry_202X.sql;如果你用的客户端是Navicat直接把SQL文件拖进去执行但注意先选择目标数据库再运行。我见过很多人在黑马若依导入表失败这类问题上卡住大多是因为没选库或字符集不对。4.2 多数据源配置主库与业务库的坑若依微服务版在system服务里做了多数据源支持用的是dynamic-datasource这个库。默认情况下ruoyi-system连接主库但你可以在Nacos配置里增加多数据源spring: datasource: dynamic: primary: master strict: false datasource: master: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ry-cloud?useUnicodetruecharacterEncodingutf8serverTimezoneGMT%2B8 username: root password: your_password biz: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/biz_db?useUnicodetruecharacterEncodingutf8serverTimezoneGMT%2B8 username: root password: your_password在代码里用DS(biz)就能切换到业务库DS(biz) public ListOrder getOrderList() { return orderMapper.selectList(...); }踩坑点dynamic-datasource的DS注解是加在实现类或者方法上的如果你加在Service接口上不生效。另外strict: false表示找不到对应的数据源时用主库兜底不会报错这会导致你写错数据源名时悄悄连到了主库查出来的数据莫名其妙。排查问题时可以临时把strict改成true让错误暴露出来。4.3 时区问题创建时间返回不对8小时偏差从哪来若依创建时间返回时间不对是搜索热词里的一条。这个问题在微服务版里更容易遇到因为涉及两层第一层是数据库连接时区。MySQL的serverTimezone参数如果设置成GMT8而你的服务器是UTC时区入库时间会差8小时。如果在Nacos配置里的JDBC URL没加serverTimezoneGMT%2B8程序读取时间时通常会出偏差。第二层是Jackson序列化时区。Spring Boot默认用Jackson序列化JSON如果配置文件里没指定时区可能按UTC输出。若依框架在application.yml里一般会这样设spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8如果你改了业务服务注意这个配置别漏掉。我当时排查一个列表页时间比数据库少8小时的问题最后就是发现Nacos里ruoyi-order.yaml没配置Jackson时区补上后恢复正常。还有一个小细节如果你的字段类型是LocalDateTimeJackson序列化需要额外加jsr310模块。若依的公共模块已经处理了但你自己新建模块时要注意引入相关依赖。5. 前后端联调与细节功能改造后端服务和数据模型理顺了接下来就是前端。若依SpringCloud版官方前端是Vue3 TypeScript Vite Element Plus这套组合在跑起来后会有不少和单体版不同的地方。5.1 Vue3TS版本跑起来之后先改什么项目拉到本地执行npm install之后直接npm run dev大概率会遇到几个问题。第一个是TypeScript的报错热词里若依vue3 ts报错说的就是这个。我遇到的典型报错有类型定义找不到某些第三方库没有自带类型定义需要在src/types或env.d.ts里补充声明。window上挂载自定义属性报错若依会在window上挂载一些全局配置TS严格模式不认识这些属性需要声明。引入组件的类型不兼容Element Plus版本升级后部分组件的Props类型签名变了和若依代码不完全匹配。面对这些TS报错我的建议是不要一上来就开any大法因为后面维护会很难受。优先看报错位置是不是第三方库的类型问题是的话在env.d.ts里统一声明如果是项目代码自身的类型问题按实际类型修复。第二个要注意的是.env.development里的接口地址。若依微服务版前端默认是VITE_APP_BASE_API /prod-api开发时通过Vite的proxy代理到网关server: { proxy: { /prod-api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/prod-api: } } } }这个target就是网关地址如果你网关端口改了或者部署到远程这里必须同步改否则前端所有请求都404。5.2 表单设计器动态脚本怎么接搜索热词里有若依 表单设计器动态执行脚本这是有一定开发深度的话题。若依本身带了一个表单设计器功能它生成的不是简单的静态表单而是支持对表单元件做联动、校验、数据填充等动态脚本配置。实际使用中你需要在表单设计器对应的组件里找到高级配置或组件事件入口里面可以配置onChange、onMounted之类的脚本片段。这些脚本会以字符串形式存储在表单定义里页面渲染时动态解析执行。这里有一个安全坑需要特别提动态执行任何脚本都有XSS风险如果你不做任何过滤用户权限大一点的人可能通过表单脚本注入恶意代码。若依本身在ruoyi-common-security里有XSS过滤机制但动态脚本这块需要你额外留意。我当时做这块的改造思路是给表单脚本单独做一个白名单限制只允许使用配置化的事件触发函数不允许执行任意JS。这样虽然牺牲了一部分灵活性但安全性大幅提升。5.3 多语言改造思路与XSS防护热词里还有若依实现多语言和存在存储型XSS这两条它们其实都涉及到同一个问题列表输入和动态内容渲染的安全与国际化。多语言改造我的思路是复用若依的字典表机制。你可以新建一张语言包表字段包括lang_key、lang_code、lang_value然后在后端做一个根据请求头Accept-Language动态返回语言文案的接口。前端通过自定义指令或过滤器把lang_key替换成对应语言文案。这个方案的好处是不改动若依原生字典结构只用了一套独立的语言包表骨架完全兼容。坏处是初次工作量大包括管理端的语言包维护界面和前端替换逻辑都要自己写。XSS防护方面除了框架自带的XssFilter外我的一个建议是在网关层做统一的请求体清洗而不是在各业务模块各做一遍。网关层清洗有个前提不能影响跨服务调用时的原始业务数据所以清洗规则要配置得精确一些比如过滤script标签、onerror事件、javascript:伪协议等。另外存储型XSS重点要查的是评论区、意见反馈、富文本编辑器提交的内容输出到前端时尽量走Vue的插值语法避免用v-html渲染不可信内容。6. 部署上线从单体Jar到容器编排的一步到位项目的最后一步就是部署。若依SpringCloud版的部署方式比较灵活小规模可以直接跑Jar包配Nginx正规一点就用Docker Compose再往上就是K8s。搜索热词里有人在问windows服务器上如何部署springcloud系统我这里结合自己实际部署过的方案说一下。6.1 手动部署与Docker部署的取舍我线上环境用的是一台4核8G的云服务器部署了网关、认证、system、file、job这几个服务加上MySQL、Redis、Nacos。手动部署的方式是本地mvn clean package -DskipTests打包把Jar包上传到服务器每个服务用nohup java -jar xxx.jar启动。这个过程问题不大但服务数量一旦增多进程管理就非常麻烦。所以后来我改用了Docker Compose把基础设施MySQL、Redis、Nacos和若依各服务都编入一个docker-compose.yml。这里给一个简化的编排片段version: 3 services: mysql: image: mysql:5.7 container_name: ruoyi-mysql environment: MYSQL_ROOT_PASSWORD: yourpassword ports: - 3306:3306 volumes: - ./mysql/conf:/etc/mysql/conf.d - ./mysql/data:/var/lib/mysql nacos: image: nacos/nacos-server:v1.4.2 container_name: ruoyi-nacos environment: MODE: standalone ports: - 8848:8848 gateway: build: ./ruoyi-gateway container_name: ruoyi-gateway ports: - 8080:8080 depends_on: - nacos注意各服务镜像里要内置好Nacos地址或者通过环境变量注入。我用的做法是在每个服务的Dockerfile里把--spring.cloud.nacos.server-addrnacos:8848作为启动参数这样容器内通过服务名而不是IP访问Nacos服务迁移时不用改配置。6.2 Nginx路由与前端部署前端项目打包后会生成dist目录把它扔到服务器上用Nginx托管。Nginx配置里最关键的是把/prod-api反向代理到网关地址server { listen 80; server_name yourdomain.com; root /opt/ruoyi-ui/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里有一个非常容易踩的坑proxy_pass的URI末尾带不带斜杠含义完全不同。带斜杠http://127.0.0.1:8080/会把/prod-api前缀去掉再转发不带斜杠则会把完整路径带过去。若依网关路由里本身配了StripPrefix所以前端代理到网关时只要保证路径最终到网关是/system/...这种形式就行。我的经验是在Nginx层去掉/prod-api网关层再按需StripPrefix两层配合路径清晰且不容易乱。6.3 监控接入Prometheus、Grafana与Zabbix热词里有若依微服务部署prometheuszabbixgrafana这条说明很多人关心微服务上线后的监控。我的做法是Prometheus负责采集指标Grafana负责展示Spring Boot ActuatorMicrometer暴露/actuator/prometheus端点Zabbix用来做服务器基础资源监控CPU、内存、磁盘和业务指标互不干扰在若依SpringCloud版里如果你在Nacos配置里加上如下的内容就能让服务暴露Prometheus指标management: endpoints: web: exposure: include: * metrics: tags: application: ${spring.application.name}然后在Prometheus配置里加一个针对网关和核心服务的抓取任务scrape_configs: - job_name: ruoyi-services metrics_path: /actuator/prometheus static_configs: - targets: - your-server:8080 - your-server:9201Grafana里可以导入Spring Boot官方Dashboard模板直接看到JVM堆内存、GC、线程数、HTTP请求量这些关键指标。这套监控搭好之后服务有没有出问题看仪表盘基本一目了然。7. 关于若依与AI结合的一点实践想法最近若依AI的热度很高搜索热词里出现了大量相关描述。我自己的实践体会是若依SpringCloud版的清晰模块边界让它跟AI能力结合时非常自然。最简单的一种玩法是在system服务里新增一个AI对话记录模块用RemoteAiService这个Feign接口去调用一个独立的AI服务AI服务负责对接大模型API。用户在前端发起提问请求经过网关路由到system服务system服务再通过Feign转到AI服务AI服务把答案返回。这个链路不修改若依任何核心代码只在业务模块层面扩展完全符合微服务的设计初衷。复杂一点的玩法是利用若依已有表单设计器把用自然语言描述需求自动生成表单做成一个AI工具。用户在表单设计器里点一个AI生成按钮系统把用户输入的需求描述发给大模型大模型返回一个JSON结构的表单定义再反填充到表单设计器里。这个方向上若依的数据结构比较标准做起来比从零搭建一个系统省力很多。在这个过程里我最大的体会是若依的价值不只是代码而是它把所有通用的管理后台基础设施都准备好了你只需要关注自己的业务差异点。接入AI也一样认证、权限、多租户、审计日志、菜单管理这些都不用操心专注把AI业务模型定义清楚就行。我在这段时间里记录了这么厚一本笔记从环境搭建反复排查到路由规则调整从单表CRUD开发到服务间调用联调中间无数次想放弃但真正跑通之后回头看这套微服务框架确实帮我建立了对分布式系统落地节奏的完整感知。如果你也在用若依或者准备迁移到微服务希望这篇记录能让你少走一些弯路。