SpringBoot微服务架构实战：从单体到自驾游攻略系统

自驾游攻略系统看起来业务不算复杂但真要把它做成高可用、可扩展的微服务项目踩坑的细节一点不少。我最近刚完成了一个基于 SpringBoot Vue Spring Cloud 的四川自驾游攻略管理系统覆盖了攻略发布、景点检索、路线规划、评论点赞、文件上传等完整功能算是对微服务分布式架构的一次深度实践。这篇博文把我的设计思路、拆服务经验、核心代码实现以及运维中遇到的问题完整记录下来尤其适合准备做微服务项目练手、或者正在从单体转型微服务的同学参考。1. 项目整体设计与微服务拆分思路1.1 为什么选微服务而不是单体架构四川自驾游攻略管理系统从表面看功能无非是攻略管理、景点展示、用户登录、评论收藏即便是用单体应用也能在几周内搞定。但我做这个项目的目的很明确不是为了“完成功能”而是为了验证微服务架构在生产级场景下的落地路径。这个系统的业务特点其实非常适合微服务不同模块的访问峰值差异明显例如节假日期间攻略浏览量大而用户登录压力集中在白天评论区可能因为热点营销瞬间出现高并发文件上传服务需要独立扩展存储带宽。如果全部塞进一个 SpringBoot 单体里一次发布要重启所有功能一旦某个接口内存溢出整个系统都跟着宕机。我按“独立演进、独立伸缩、独立故障隔离”的原则把系统拆成了 6 个可独立部署的微服务。每个服务都有独立的数据库或至少独立的 schema服务之间只通过 API 通信。为了不让团队沟通成本爆炸我还限制了服务间的同步调用深度避免出现 A 调 B、B 调 C、C 再调 A 这种循环依赖。适合参考这套方案的人是想理解“微服务拆分粒度”的开发者。我见过很多人一上来就拆十几个服务结果注册中心里全是没意义的服务名部署一次光启动就要半小时。我的经验是哪怕未来有 50 个服务第一版也只拆 6 个后续根据监控数据和团队规模逐步演进。1.2 服务拆分方案与边界定义我最终确定的拆分方案如下服务名核心职责独立数据存储主要技术点user-service用户注册/登录/JWT签发user_dbSpring Security OAuth2 资源服务器guide-service攻略文章CRUD、攻略搜索、点赞收藏guide_dbElasticsearch 搜索 Redis 缓存scenic-service景点信息、地区标签、景点评分scenic_db缓存 地理位置检索route-service自驾路线规划、路线推荐、途经点管理route_db路线算法 地图坐标处理comment-service攻略评论、回复、评论审核comment_db异步消息 敏感词过滤file-service图片/视频上传、Minio 对象存储file_db元数据Minio 分片上传除了上述业务服务还有三个基础设施组件Nacos注册与配置中心、Spring Cloud Gateway统一入口网关、Sentinel限流熔断。在微服务架构图里用户请求先经过 Nginx再到网关网关根据路径前缀转发到对应服务。这种设计让前端只认一个域名后端任意扩缩容对客户端无感。边界定义是拆分中最容易出错的地方。我的原则是一个服务不要同时依赖另外两个服务的数据库表所有跨服务查询必须走 API 或事件。比如攻略详情页需要展示景点名称guide-service 不直接查 scenic-service 的库而是调用 scenic-service 的接口获取景点摘要或者把景点名称冗余到攻略表里。这里我采用了冗余快照的方式攻略发布时前端会传入景点 IDguide-service 异步从 scenic-service 拉取景点名称并存储到本地这样详情页展示时无需远程调用延迟更低。1.3 技术选型背后的取舍主框架选择上我用的 SpringBoot 2.7.x Spring Cloud Alibaba 2021.x。之所以不用 SpringBoot 3.x 和 SpringCloud 2023是因为当时团队对 JDK17 的兼容性还有顾虑而且很多演示代码和网上的踩坑案例都集中在 2.x 版本。如果你是新项目且不依赖老组件可以直接上 SpringBoot 3 JDK17但要注意 Nacos 客户端、Seata 这些组件必须使用适配版本否则会出现各种奇怪的 NoSuchMethodError。前端选择了 Vue 3 Vite Element Plus。Vue 技术栈在社区里最活跃Element Plus 的表单、表格组件特别适合后台管理类页面。其实这套系统包括了用户端 H5 和运营管理后台两部分我共用了同一套 Vue 工程通过路由和权限来做区分比维护两个前端项目省力得多。数据存储方面MySQL 8.0 承担核心业务数据Redis 6.x 做缓存和分布式锁Elasticsearch 负责攻略关键词搜索。文件存储我用 Minio 私有化部署兼容 AWS S3 API比直接用云对象存储更灵活也便于演示部署到自己的服务器。这套组合基本就是国内微服务项目的标准答案好处是遇到问题时搜索引擎里能找到大量现成解决方案。2. 核心功能设计与数据模型2.1 攻略发布与浏览的完整链路攻略发布是整个系统的核心流程。用户在 Web 端填写攻略标题、正文、封面图、途经景点、游玩天数、预算等信息点击发布后请求先到网关再转发到 guide-service。guide-service 首先对请求做 JWT 解析拿到用户 ID 和权限然后校验攻略内容的敏感词和合法性接着把封面图片异步通知 file-service 做持久化攻略正文中引用的图片地址也会被替换成经过 CDN 加速的 URL。这里我设计了两个值得说的点第一攻略正文采用富文本编辑器用户可能粘贴外部图片为了不让外部图床热链失效我在后端写了一个图片外链抓取功能发布时解析 HTML 中的 img 标签把外链图片下载到 Minio替换成本地地址。第二攻略状态机包括草稿、待审核、已发布、已下架四种状态。审核通过后攻略 ID 会被发送到 RabbitMQ消费端负责把攻略的标题、摘要、标签写入 Elasticsearch。用户搜索时guide-service 直接查 ES避免了 MySQL 的 LIKE 全表扫描。浏览端的分页查询我加了两层缓存。第一层是 Redis 缓存攻略列表页的 DTO 对象缓存 key 包含查询条件和页码第二层是缓存单篇攻略的详情。为了保证数据一致性我在攻略更新和删除时主动删除对应缓存并引入了版本号机制避免并发更新导致缓存与数据库不一致。实测浏览接口在缓存命中时 TPS 能到 5000 以上而直接查库只有 800 左右。2.2 自驾路线规划与推荐算法思路“自驾游”是这个系统的灵魂功能。如果只是把景点列表罗列出来用户还不如去携程看。我做了一个简单的路线规划服务用户输入出发城市、游玩天数、偏好标签比如自然风光、历史文化、亲子route-service 会根据景点之间的距离、预计游玩时长、道路类型自动生成一条环形路线保证不走回头路。算法层面我没有用复杂的图论动态规划因为景点数量最多几十个直接用贪心 局部搜索就够。先把候选景点按评分排序然后从出发城市作为起点每次选择距离当前位置最近且未被访问的景点同时满足单日驾驶里程不超过 300 公里自驾游的舒适阈值。如果剩余的景点无法在限定天数内游览完就优先舍弃评分较低或距离偏远的点。这样算出来的路线不一定全局最优但用户根本感知不到差别。真正重要的是地图可视化前端用高德地图 JS API 加载路线后端将每个景点的经纬度存储为 MySQL 的 Point 类型计算距离时用 Haversine 公式换算。我没有引入 GIS 数据库因为四川境内的景点即便有一千个内存中计算两两距离也毫无压力。推荐算法方面我基于用户的历史浏览和收藏行为做了一个简单的协同过滤用户 A 收藏了攻略 X而攻略 X 与攻略 Y 被同一群人收藏则把 Y 推荐给 A。实现上不写算法而是使用 Redis 的 Set 计算交集。这个方案比机器学习模型可控性强多了而且冷启动时可以用热门攻略作为兜底推荐。如果你想把推荐做深可以引入 Spark Mlib 或者向量检索但对这个小规模业务没必要。2.3 核心数据库表结构设计我挑几张最重要的表分享一下设计思路。用户和攻略是基础但更有代表性的是路线规划表和评论表。CREATE TABLE route_plan ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, start_city varchar(50) NOT NULL COMMENT 出发城市, days tinyint NOT NULL COMMENT 游玩天数, preference_tags varchar(200) DEFAULT NULL COMMENT 偏好标签逗号分隔, total_km int DEFAULT NULL COMMENT 总里程, route_json json DEFAULT NULL COMMENT 路线明细包含每日行程, status tinyint DEFAULT 1 COMMENT 状态 1有效 0废弃, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT自驾路线规划表;route_json 字段直接存 JSON省去复杂的关联表。优点是一张表就能完整描述整条路线读取快缺点是如果要统计“哪些路线经过某景点”就只能用 JSON 函数搜索性能堪忧。针对这个问题我另建了一张 route_scenic_rel 关联表存储路线 ID 和景点 ID 的多对多关系统计时走关联表展示时读 JSON。这是反范式设计的典型案例牺牲一些冗余换取了灵活性。攻略表的核心是正文全文检索我用了 ESMySQL 里的 content 只是为了数据备份和后台管理界面展示。评论表则采用了“祖先路径”设计每条评论记录 parent_id 和 ancestor_id并用 depth 字段标记层级。查询某个攻略的整棵评论树时只需要按 ancestor_id 一次查出来在应用内存里组装成树性能远好于递归查询。3. SpringBoot 微服务基础设施落地实战3.1 版本选型与依赖踩坑实录做微服务项目最让人头疼的就是版本兼容。我列出我用的一套稳定组合照着配基本不会出错组件版本说明JDK1.8建议 112.7.x 支持良好3.x 必须 JDK17Spring Boot2.7.14最后一个 2.x 小版本文档丰富Spring Cloud2021.0.8对应 Spring Boot 2.7Spring Cloud Alibaba2021.0.5.0含 Nacos、Sentinel、Seata 适配Nacos Server2.2.1配置中心 注册中心MySQL8.0.32字符集 utf8mb4Redis6.2缓存与分布式锁MinioRELEASE.2023-7-4对象存储这里特别提醒Spring Boot 版本太高反而是坑。网上很多教程喜欢用 3.0但如果你引入的第三方 starter 没有适配新版本运行时会报错。我的做法是锁定上述版本pom 中的 parent 直接用 Spring Boot 版本Spring Cloud Alibaba 的版本不要自己猜去官网查对应的 Release Notes。另外一点一定要在依赖里显式声明spring-cloud-starter-alibaba-nacos-discovery的版本。因为 Spring Cloud Alibaba 的 BOM 只能管理其自身的组件版本有些传递依赖可能拉到你本地 Maven 仓库里另一个老的版本导致接口不兼容。我在第一次启动时就是没锁定版本Nacos 客户端报了com.alibaba.nacos.api.exception.NacosException: Client not connected后来才发现是依赖冲突。3.2 Nacos 注册中心与配置中心的最佳实践Nacos 不止是注册中心我更常用它来做配置中心。微服务架构中的每个服务都有自己的配置文件而且不同环境dev、test、prod配置不同。如果沿用 Spring Boot 的 application.yml 管理打包时要带上多套配置非常容易出错。我把数据库连接、Redis 地址、消息队列开关等配置全部放到 Nacos 配置中心服务本地只保留应用名称和 Nacos 地址。配置中心的命名规则我采用${spring.application.name}-${spring.profiles.active}.yml。比如guide-service-dev.yml这样同一个服务在启动时根据 profile 加载对应配置。Nacos 配置支持热更新无需重启服务但要注意使用ConfigurationProperties方式读取配置并使用RefreshScope注解否则修改配置不生效。服务注册方面我启用了 Nacos 的临时实例模式服务掉线后 30 秒内自动剔除。健康检查机制默认是 TCP 端口探测对于需要长连接的服务建议开启 HTTP 健康检查并配置/actuator/health端点让 Nacos 能感知服务内部的真实状态。另一个细节是务必在核心服务中引入spring-boot-starter-actuator不仅是为了健康检查后续接入 Prometheus 监控也要靠它暴露指标。3.3 网关统一鉴权、限流与跨域处理Spring Cloud Gateway 是整个流量的咽喉。我在网关层做了三件事路由转发、JWT 鉴权、限流。路由规则很简单/api/user/**转发到 user-service/api/guide/**转发到 guide-service以此类推。网关鉴权我使用全局过滤器。白名单路径比如/api/user/login、/api/user/register以及静态资源路径其余请求都必须携带有效 JWT。解析 JWT 成功后我会把userId放到请求头中向下游传递下游服务从ServerHttpRequest中获取。这个方案比在业务服务内各做一遍鉴权更统一也避免了重复代码。Component public class AuthGlobalFilter implements GlobalFilter, Ordered { Autowired private StringRedisTemplate redisTemplate; Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String path exchange.getRequest().getURI().getPath(); if (isWhitelist(path)) { return chain.filter(exchange); } String token exchange.getRequest().getHeaders().getFirst(Authorization); // 解析 token校验签名和有效期从 redis 取出 token 黑名单 if (token null || !token.startsWith(Bearer )) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } String userId JwtUtil.parseToken(token.replace(Bearer , )); ServerHttpRequest mutatedRequest exchange.getRequest().mutate() .header(X-User-Id, userId).build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } }跨域问题在微服务架构中异常常见。开发和调试阶段前端在 localhost:5173后端网关在 localhost:8080如果不解决 CORS浏览器会拦截所有请求。我在网关配置了GlobalCorsProperties允许指定来源的跨域请求。生产环境则反着来前端和网关部署在同域下由 Nginx 反向代理完全不需要跨域。所以我建议开发环境开启网关 CORS生产环境关闭用 Nginx 转发。3.4 分布式事务与分布式锁的落地经验自驾游系统里最容易出现分布式事务的场景是用户发布一条攻略需要同时更新guide表和guide_stats统计表或者用户收藏攻略需要同时写收藏记录和累加攻略收藏数。如果是单体项目一个本地事务就解决了拆成微服务后这两个写操作可能落在不同的服务或数据库里本地事务无力回天。我先澄清不是所有跨服务调用都需要分布式事务。对于收藏数这种允许稍微延迟甚至丢失的统计数据我直接走 RabbitMQ 异步通知消息失败就重试最终一致即可。而对于那些必须强一致的场景例如支付订单创建与行程锁定我用 Seata 的 AT 模式接管。Seata AT 模式对代码侵入极小业务代码只需要在方法上加GlobalTransactional注解Seata 会拦截并协调分支事务。它的原理是在本地事务提交前自动记录 UNDO_LOG 快照如果全局事务失败根据快照自动回滚数据。听起来很美好但用起来有几个关键坑。第一所有参与事务的服务必须共用同一个 Seata Server 的配置且application.yml里的事务分组名要一致否则分支事务注册不到全局事务上。第二UNDO_LOG表必须在每个业务库中创建很多新手会遗漏这一步导致回滚时报Table undo_log not exists。第三Seata 默认使用全局锁高并发下会放大锁冲突所以别把热点数据的频繁更新放进全局事务宁可牺牲强一致性也要保证吞吐。至于 Redis 分布式锁我在文件上传去重和秒杀式抢限量优惠券场景中用了 Redisson 客户端。Redisson 封装了看门狗机制能避免锁过期导致的操作冲突。我踩过的一个经典坑是两个业务并发执行时如果 A 持锁时间超过锁的超时时间锁自动释放B 拿到锁进入临界区此时 A 完成操作后调用 unlock 会把 B 的锁给释放掉。补救方案是锁 value 设置为每个请求的唯一 ID释放时用 Lua 脚本判断是否持有才删除。这个细节在面试里也是高频考点能说出原理很加分。4. 前端 Vue 实现与前后端联调细节4.1 Vue 项目结构、动态路由与权限控制前端的定位是全栈中的“另一半”。我使用 Vue 3 组合式 API Vite 搭建工程目录结构如下src/api按服务模块封装的 API 请求每个函数对应一个后端接口src/router路由配置包含静态路由与动态路由src/storePinia 状态管理存储用户信息、权限标识src/components通用组件如上传组件、地图组件src/views页面视图分为user、guide、admin等模块动态路由是后台管理系统必须处理的问题。不同角色登录后看到的菜单不同管理员能看到攻略审核、用户管理等页面普通用户只看到攻略浏览和发表中心。如果一开始就把所有路由注册任何一个登录用户通过 URL 就能访问管理员页面这是一个很严重的越权漏洞。我的做法是登录成功后后端返回当前用户的路由权限标识数组permissions前端遍历后端配置好的“菜单-路由映射表”筛选出用户可访问的页面再调用router.addRoute动态添加。同时页面加载时还会判断按钮级权限比如“删除攻略”按钮只有管理员可见。为了便于拦截路由守卫里加入逻辑如果没有 token 就跳转登录页如果有 token 但访问了未注册的动态路由则跳转 403 页面。这里注意router.addRoute添加的路由在刷新页面后会消失所以必须在应用初始化时App.vue的onMounted或者路由守卫里重新从后端拉取权限并重新添加否则刷新后直接白屏。我最初就是因为没处理刷新场景调试了很久。4.2 自驾路线地图可视化实现路线地图是整个系统最有视觉冲击力的部分。前端使用高德地图 JavaScript API在index.html中引入 SDK并通过window.AMap获取地图实例。Vue 组件中初始化地图后将从后端获取的路线坐标点数组以折线标记途经点使用圆形标记并添加文字标签。关键点是后端返回的route_json包含每日行程节点每个节点有景点名称、坐标、预计游览时间。前端在地图上同时绘制多条折线时用不同颜色区分第二天的路线。例如第一天用蓝色第二天用红色让用户一目了然。同时我会在地图覆盖物上绑定点击事件点击某个景点点标记弹出信息窗口显示景点照片和介绍。地图加载有坑首次使用需要申请密钥并把服务器域名加入白名单。开发环境域名是localhost也需要配置。地图容器必须设置固定高度否则地图初始化为 0 高度不会显示。另外地图实例在 Vue 路由切换时不会自动销毁会造成内存泄漏我使用onBeforeUnmount钩子调用map.destroy()。高德地图的AMap.Geocoder插件可以将地址文字解析成经纬度但我建议让后端在数据库中直接存储坐标前端尽量少做地理编码因为地理编码有每日免费调用次数限制而且异步返回容易导致组件状态混乱。4.3 富文本编辑器与文件上传的联调方案富文本编辑是攻略管理的核心交互。我使用 vditor 或 wangEditor 这类开源编辑器在工具栏上挂载一个“上传图片”按钮。图片上传不走普通的multipart/form-data接口而是先由前端调用 file-service 的预签名接口获得 Minio 的上传地址和凭证然后前端直传 Minio。这种设计避免了大文件经过业务服务转发占用带宽并且支持断点续传。直传完成后前端把返回的文件 URL 插入编辑器中的图片标签。Minio 的对象名规则我用{服务名}/{年}/{月}/{日}/{uuid}.{后缀}。这样方便后续按时间清理和做生命周期管理。上传接口需要校验文件类型和大小图片类型白名单为 jpg/jpeg/png/webp视频则为 mp4。SpringBoot 的MultipartFile接口在处理大文件时如果没有配置spring.servlet.multipart.max-file-size和max-request-size默认只有 1MB上传稍大一点就报错。我这边将图片限制在 5MB视频限制在 200MB并在网关层的路由配置中也同步调大请求体限制。还有一个容易忽略的问题Nginx 默认client_max_body_size是 1m如果不改即便后端配置再大视频上传也会在 Nginx 层被拒。服务器运维时必须同步修改 Nginx 配置。这个坑我是在上线压测时发现的前端报413 Request Entity Too Large查了半天。5. 分布式环境下的部署与运维实践5.1 Docker Compose 一键搭建基础中间件为了能让项目在别人的机器上快速跑起来我准备了一套 Docker Compose 文件用来管理 MySQL、Redis、Nacos、Minio、RabbitMQ、Elasticsearch 等基础设施。这样不用本机装一堆软件只要 Docker 环境正常docker-compose up -d就能在一分钟内完成中间件初始化。我列了一个关键配置比如 Nacos 需要暴露 8848 端口和 9848 端口。9848 是 Nacos 2.x 新增的 gRPC 端口只配置 8848 会导致服务能注册成功但后续心跳连接出现问题表现为服务列表闪烁。这个坑很多人忽略。MySQL 的容器设置时区为Asia/Shanghai否则CURRENT_TIMESTAMP会少 8 小时。Redis 的持久化我选择 AOF 和 RDB 双重开启因为作为缓存和锁存储数据丢失会直接影响业务。中间件容器最好使用自定义网络让服务名作为域名互相访问。比如微服务里数据库地址写成mysql:3306而不是localhost:3306这样在 Docker 环境下无需修改代码即可互联。我提供的 Compose 文件中配置了networks: micro-service-net所有容器共用该网络。5.2 微服务镜像打包与服务器部署流程每个微服务都是一个独立的 SpringBoot 可执行 JAR打包成镜像部署到服务器。我使用 Dockerfile镜像基础使用openjdk:8-jre-alpine将 JAR 通过COPY放入/app目录。启动命令执行java -jar并添加 JVM 参数限制最大堆内存为 512MB防止某个服务内存泄漏拖垮整台服务器。打包发布我用 Maven 的mvn clean package多模块项目需要在根目录执行。注意子模块之间的依赖要先执行install到本地仓库否则单独打包某个服务会出现找不到依赖模块的报错。GitHub Actions 是另一个选择但为了简化演示我这里只给出手动构建脚本。部署时我的服务器内存只有 16G为了保证所有服务能同时运行我采取资源分配策略每个业务服务限制内存 512M网关 256MMySQL 2GRedis 1GNacos 600MMinio 512M剩余给系统缓存。如果想要更节约可以把多个服务合并到一个 Jar 内部通过 profile 切换实现但那就违背了微服务独立部署的初衷所以我宁可减少一些服务数量也不合并部署。生产环境的高可用我用 Nginx 负载均衡两台应用服务器前端静态文件也由 Nginx 提供。注册中心 Nacos 至少部署三个节点但我个人测试环境只跑单节点。如果读者要做真正的集群方案建议使用 K8s 管理服务实例自动扩容与故障重启能减少大量运维精力。5.3 链路追踪与日志收集微服务调试的最大噩梦是一个请求从网关到 guide-service再到 scenic-service全程调用了四个服务某一步报错返回 500却不知道该看哪个服务的日志。为此我引入了 Sleuth Zipkin 做链路追踪。Sleuth 会自动在请求头中生成traceId和spanId日志中输出格式为[traceId, spanId]。Zipkin 收集器将这些 trace 数据上报并可视化我能通过一条 trace 看到整个请求树定位耗时瓶颈。日志收集上我采用 Elasticsearch Kibana 集中方案。每个业务服务多加一个 logstash 或者 filebeat 配置将应用日志以 JSON 格式发送到日志管道。Kibana 上按serviceName和traceId搜索日志检索效率非常高。如果不想上 ELK可以直接用docker logs加上 grep但那样调试跨服务问题效率太低。监控指标这块我使用 Prometheus 拉取每个服务/actuator/prometheus端点。重点监控 JVM 堆内存、GC 次数、接口响应时间 P99、QPS。Sentinel 也自带 Dashboard可以查看某个接口的实时流控效果。这些监控数据不只用于运维还能指导我后续做容量评估比如发现 guide-service 的 CPU 在热点攻略发布时达到 80%就说明需要扩容或优化 SQL。6. 常见问题与排查技巧实录6.1 SpringBoot 与 SpringCloud 版本冲突怎么破版本冲突是微服务入门最阴暗的角落。我汇总了几个高频错误错误现象根本原因解决办法启动报ClassNotFoundException: okhttp3.OkHttpClientNacos 客户端依赖okhttp版本号与管理依赖冲突显式引入okhttp4.x 版本Failed to configure a DataSource但 yml 中配置了数据库服务中没有引入spring-boot-starter-jdbc且自动配置类未生效检查依赖确保数据库驱动存在网关路由不生效返回 404网关中的spring.cloud.gateway.routes配置项缩进错误或遗漏uri前半段用http://服务名:端口格式启用 Nacos 后可用服务名协议No Feign Client for loadBalancing definedFeign 接口未添加FeignClient(name xxx)或未启用EnableFeignClients主启动类添加注解并确保 name 与注册服务名一致我踩得最惨的是 Spring Cloud Gateway 的Spring Cloud Loadbalancer与 Nacos 集成问题。默认 LoadBalancer 不认识 Nacos 注册的服务导致用lb://guide-service路由时报Service instance cannot be found。解决办法是引入spring-cloud-starter-alibaba-nacos-discovery后再添加spring-cloud-loadbalancer依赖并在配置中指定spring.cloud.loadbalancer.ribbon.enabledfalse。这个版本问题在官方文档里写得模棱两可实操时必须反复验证。6.2 分布式事务回滚失效的原因与分析使用 Seata 时我遇到过回滚失效的真实案例在GlobalTransactional方法内第一个服务的本地事务提交后第二个服务抛出业务异常全局事务发起回滚但第二个服务回滚成功第一个服务的数据却没有恢复。检查半天发现第一个服务的数据源没有纳入 Seata 代理。在 AT 模式下Seata 是通过DataSourceProxy包装数据源实现回滚的。如果业务代码里自行创建了多数据源或者用了动态数据源框架默认只代理了一个主数据源其他数据源不会记录 UNDO_LOG。必须手动把参与事务的数据源都定义为DataSourceProxy并且保证每个数据源对应的库有undo_log表。后来我把代码更新为Bean Primary public DataSource dataSource(DataSourceProperties properties) { DruidDataSource ds new DruidDataSource(); ds.setUrl(properties.getUrl()); ds.setUsername(properties.getUsername()); ds.setPassword(properties.getPassword()); return new DataSourceProxy(ds); }这种代理关系才和 Seata 匹配。另一个坑是GlobalTransactional必须加在事务发起方的 public 方法上如果被同类内部调用Spring AOP 代理不生效全局事务根本不会开启。6.3 前端常见问题路由刷新 404、跨域与图片显示前端的问题们看着很小但足以让联调崩溃。路由刷新 404 主要出现在 Vue Router 使用 history 模式时Nginx 没有配置try_files回退。解决办法是在 Nginx 的 location 中加上location / { try_files $uri $uri/ /index.html; }如果不加刷新页面时 Nginx 会按路径去找真实文件找不到就返回 404。这个配置我见公司里很多前端同事踩坑其实一行就能解决。跨域问题如果在网关层已经解决还是会遇到“接口通但浏览器报 CORS”多半是 Vue 的 axios 请求被网关拦截后网关过滤器返回的异常响应没有携带 CORS 头部。所以在网关全局异常处理中也要手动添加Access-Control-Allow-Origin头否则浏览器看到跨域标识丢失就毫不犹豫地拦截了。图片显示不出的场景和 Minio 相关。Minio 的桶默认私有URL 如果不是预签名 URL 就无法访问。我在 file-service 中加载图片时采用了两种方式封面图这类需要公开访问的我会在 Minio 桶中设置匿名只读策略而用户头像这种敏感文件则通过 file-service 的接口读取后端将文件内容流式返回。如果直接上传后前端img srchttp://ip:9000/bucket/xxx.jpg一直转圈先确认是否设置了桶策略。6.4 数据库与缓存一致性维护在 guide-service 中我维护攻略列表缓存时遇到了缓存穿透和击穿。穿透是指用户疯狂请求一个不存在的攻略 ID导致每次请求都穿过缓存直达数据库。解决方式是缓存空值并设置较短过期时间比如 30 秒并在网关层用 Sentinel 做热点参数限流。击穿指某个热点攻略的缓存同时失效大量请求涌向数据库。解决方式是逻辑过期不设置自然过期时间而是保存一个过期时间戳查询时发现过期则异步更新缓存同时当前请求返回旧数据。这个方案可能造成短暂的数据不一致但对攻略点击数、浏览量这些不敏感数据的场景完全适用。另外数据库主从同步的延迟也值得一提。当用户发布攻略后如果立刻去查询在读写分离的架构下可能因为从库尚未同步而查不到刚发的数据。解决方法是在发布成功的 Cookie 或 Redis 中标记一个“已发布”标识查询接口判断标识则强制走主库。这个细节一般只有被老板催“为什么发完看不到”的人才会懂。7. 这个项目还可以怎么扩展最后我可以分享几个后续演进方向也算是我自己接下来准备做的事。第一个方向是引入容器化编排把 Docker Compose 升级为 K8s。微服务拆出来后真正能发挥弹性伸缩优势需要依赖 K8s 的 HPA水平自动伸缩。目前我用 Compose 部署是静态分配资源无法根据 QPS 自动扩缩容。比如节假日四川自驾游热度飙升时我希望能自动把 guide-service 的实例数从 1 扩到 5用完后自动缩回这样既能节省服务器成本也能保证响应速度。第二个方向是完善数据可视化。目前管理系统里只有基础的趋势图表后续可以加一个“四川自驾游热门路线热力图”基于用户路线规划数据聚合展示哪些路线在哪些时间段最受欢迎。这将提升产品的差异化竞争力。第三个方向是引入更智能的内容审核流程。目前评论和攻略的敏感词校验是提前维护关键词库误杀率很高。可以接入大模型的文本审核能力更精准地识别恶意内容。不过这会增加成本和响应延迟需要做个权衡。我个人在实际操作中体会最深的一点微服务不是一个银弹它带来的架构红利要靠大量的工程化配套才能兑现。如果你只是写个毕业设计或者练手项目单体加上一个 Redis 缓存几乎能应对所有需求而如果你认真决定走微服务这条路就要有心理准备需要同时搞定 Spring Cloud 全家桶、分布式事务、消息队列、容器化、监控告警这些复杂组件。希望这篇总结能帮你少踩一些我踩过的坑。