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

自驾游攻略系统看起来业务不算复杂，但真要把它做成高可用、可扩展的微服务项目，踩坑的细节一点不少。我最近刚完成了一个基于 SpringBoot + Vue + Spring Cloud 的四川自驾游攻略管理系统，覆盖了攻略发布、景点检索、路线规划、评论点赞、文件上传等完整功能，算是对微服务分布式架构的一次深度实践。这篇博文把我的设计思路、拆服务经验、核心代码实现以及运维中遇到的问题完整记录下来，尤其适合准备做微服务项目练手、或者正在从单体转型微服务的同学参考。

1. 项目整体设计与微服务拆分思路

1.1 为什么选微服务而不是单体架构？

四川自驾游攻略管理系统从表面看，功能无非是攻略管理、景点展示、用户登录、评论收藏，即便是用单体应用，也能在几周内搞定。但我做这个项目的目的很明确：不是为了“完成功能”，而是为了验证微服务架构在生产级场景下的落地路径。这个系统的业务特点其实非常适合微服务：不同模块的访问峰值差异明显，例如节假日期间攻略浏览量大，而用户登录压力集中在白天，评论区可能因为热点营销瞬间出现高并发，文件上传服务需要独立扩展存储带宽。如果全部塞进一个 SpringBoot 单体里，一次发布要重启所有功能，一旦某个接口内存溢出，整个系统都跟着宕机。

我按“独立演进、独立伸缩、独立故障隔离”的原则，把系统拆成了 6 个可独立部署的微服务。每个服务都有独立的数据库或至少独立的 schema，服务之间只通过 API 通信。为了不让团队沟通成本爆炸，我还限制了服务间的同步调用深度，避免出现 A 调 B、B 调 C、C 再调 A 这种循环依赖。

适合参考这套方案的人，是想理解“微服务拆分粒度”的开发者。我见过很多人一上来就拆十几个服务，结果注册中心里全是没意义的服务名，部署一次光启动就要半小时。我的经验是：哪怕未来有 50 个服务，第一版也只拆 6 个，后续根据监控数据和团队规模逐步演进。

1.2 服务拆分方案与边界定义

我最终确定的拆分方案如下：

除了上述业务服务，还有三个基础设施组件：Nacos（注册与配置中心）、Spring Cloud Gateway（统一入口网关）、Sentinel（限流熔断）。在微服务架构图里，用户请求先经过 Nginx，再到网关，网关根据路径前缀转发到对应服务。这种设计让前端只认一个域名，后端任意扩缩容对客户端无感。

边界定义是拆分中最容易出错的地方。我的原则是：一个服务不要同时依赖另外两个服务的数据库表，所有跨服务查询必须走 API 或事件。比如攻略详情页需要展示景点名称，guide-service 不直接查 scenic-service 的库，而是调用 scenic-service 的接口获取景点摘要，或者把景点名称冗余到攻略表里。这里我采用了冗余快照的方式：攻略发布时，前端会传入景点 ID，guide-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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='自驾路线规划表';

route_json 字段直接存 JSON，省去复杂的关联表。优点是一张表就能完整描述整条路线，读取快；缺点是如果要统计“哪些路线经过某景点”，就只能用 JSON 函数搜索，性能堪忧。针对这个问题，我另建了一张 route_scenic_rel 关联表，存储路线 ID 和景点 ID 的多对多关系，统计时走关联表，展示时读 JSON。这是反范式设计的典型案例，牺牲一些冗余换取了灵活性。

攻略表的核心是正文全文检索，我用了 ES，MySQL 里的 content 只是为了数据备份和后台管理界面展示。评论表则采用了“祖先路径”设计，每条评论记录 parent_id 和 ancestor_id，并用 depth 字段标记层级。查询某个攻略的整棵评论树时，只需要按 ancestor_id 一次查出来，在应用内存里组装成树，性能远好于递归查询。

3. SpringBoot 微服务基础设施落地实战

3.1 版本选型与依赖踩坑实录

做微服务项目，最让人头疼的就是版本兼容。我列出我用的一套稳定组合，照着配基本不会出错：

这里特别提醒：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 Mono<Void> 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/store：Pinia 状态管理，存储用户信息、权限标识
• 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，网关 256M，MySQL 2G，Redis 1G，Nacos 600M，Minio 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 版本冲突怎么破

版本冲突是微服务入门最阴暗的角落。我汇总了几个高频错误：

我踩得最惨的是 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.enabled=false。这个版本问题在官方文档里写得模棱两可，实操时必须反复验证。

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 src="http://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 全家桶、分布式事务、消息队列、容器化、监控告警这些复杂组件。希望这篇总结能帮你少踩一些我踩过的坑。