前言去年公司要做一场线上作品评选活动最初就是一整套单体应用后端 SpringBoot、前端 Vue2部署在一台 4C8G 的云服务器上。活动开始第一天2 万多人同时在线投票数据库连接池被打爆紧接着出现死锁页面直接白屏。那场面我到现在都记得很清楚。后来我们把整个系统用 SpringCloud 重新梳理了一遍前端顺手升级到 Vue3前后花了将近 40 天终于把这套基于 SpringCloud 的微服务作品投票系统稳定跑了下来。这篇文章就围绕这个项目把架构设计、核心代码、服务拆分、防刷方案以及前后端联调时踩过的坑全部复盘一遍。无论你是想用 SpringCloud Vue3 做投票类项目还是单纯想入门微服务都值得花几分钟看完很多坑是我翻了半天文档才解决的。1. 为什么一个投票系统要上 SpringCloud1.1 单体阶段的瓶颈一次活动就把系统打垮了先说单体应用为什么撑不住。当时的投票接口逻辑并不复杂用户点一下按钮后端校验用户登录态校验作品是否存在然后往投票记录表里插入一条数据再更新作品表的投票数字段。看起来没毛病但投票这个业务和普通 CRUD 不一样它的特点是短时间内的极端集中流量。活动开始前半小时大量用户同时涌进来每个请求都要做若干次数据库读写查用户信息1 次查询查作品信息2 次查询插入投票记录1 次写入更新作品票数1 次写入。一个请求就要产生 5 次数据库交互。假设单库连接池上限 100QPS 稍微上来一点线程就开始排队连接迟迟不释放死锁就会出现。我们当时的 MySQL 用的是默认的REPEATABLE READ隔离级别投票记录表和作品表高频读写时间隙锁冲突非常严重。把架构拆成微服务本质上不是为了用微服务而是为了把高频的投票操作和低频的作品管理、用户管理拆到不同的进程里让各自独立扩容、独立扛压。这也是我做这次重构的核心出发点哪个服务压力大就单独给它加资源而不是把整个单体应用一起放大。1.2 服务边界怎么划分我最终拆出来 5 个服务服务拆分我纠结了很久一开始拆了 8 个后来发现过度设计了比如积分服务和用户服务完全可以合并。最终沉淀下来的拆分逻辑是按业务域拆分 按流量特征拆分。我自己总结的边界划分标准有三个数据是否独立如果一个模块的数据表只会被自己的业务访问就可以拆出来。流量是否独立读写频率明显不同的模块必须拆。团队/职责是否独立这一点在这个小项目里可以适当放宽。最终的项目结构如下vote-system/ ├── auth-service # 认证鉴权服务 ├── user-service # 用户服务 ├── work-service # 作品服务 ├── vote-service # 投票服务核心高并发服务 ├── stat-service # 统计服务 └── gateway-service # 网关服务这 5 个服务的边界如下auth-service登录、注册、Token 签发与刷新。虽然操作的是用户表但它的调用频率极高而且只涉及账号密码和 token把它单独拆出来不会影响用户服务。user-service用户资料的查询和编辑包括头像、昵称、身份角色。用户在活动页查询自己的信息时主要走这个服务。work-service作品上传、审核、上下架、作品详情。这个服务是低频写、中频读和投票服务比压力小得多。vote-service投票接口、取消投票、查询我的投票记录。这是全系统压力最大的服务必须独立出来单独扩副本。stat-service榜单聚合、实时排名、每日统计报表。榜单数据由投票服务通过消息异步通知统计服务再聚合结果。额外要提醒的是不要把文件上传做成一个独立服务。头像和作品封面都属于低频上传放在 work-service 里足够独立拆出去反而要处理分布式文件存储的一致性问题纯属自找麻烦。1.3 技术栈清单与版本匹配这个项目的技术栈是根据团队熟悉度和社区活跃度选出来的。很多人上来就问 SpringCloud 用什么版本、Nacos 怎么和 SpringBoot 匹配确实这一块最容易踩坑。我用的版本组合表如下组件版本JDK1.8稳定主流云厂商镜像兼容好Spring Boot2.7.14Spring Cloud2021.0.5Spring Cloud Alibaba2021.0.5.0Nacos2.2.1Spring Cloud Gateway3.1.4OpenFeign3.1.4Sentinel1.8.6MyBatis-Plus3.5.3Vue3.3.4Vite4.4.9Pinia2.1.6Element Plus2.4.2关于版本匹配想多说两句SpringCloud 和 SpringBoot 是强绑定关系不能用2021.0.5去配 SpringBoot 3.0 以上的版本。SpringCloud Alibaba 也同理必须先去官网查对应的version mapping。我见过很多新手项目启动不了本质就是 nacos-client 和 micro-service 的版本号对不上启动时报各种ClassNotFoundException。2. 注册中心、网关与核心表设计2.1 注册中心选 Nacos 而不是 EurekaEureka 2.0 已经停止开发国内生态也更偏好 Nacos原因很实用Nacos 同时具备注册中心和配置中心两个功能一个组件干两件事省去额外部署 Config Server。Nacos 支持配置的动态刷新网关路由、数据源配置等改动不需要重启服务。控制台界面非常清晰可以直观看到每个服务的在线实例数、健康状态。我在项目里用的注册中心配置如下新同学可以直接抄spring: application: name: vote-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: prod-001 group: VOTE_GROUP注意namespace这个参数。我会把开发、测试、生产环境用不同的 namespace 隔离避免开发环境误连生产环境注册中心。很多人忽略这个一上线就出现服务路由到本地这种玄学问题其实就是 namespace 没隔离。2.2 网关路由和统一鉴权网关我用的是 Spring Cloud Gateway它有两个选择基于 Netty 的响应式版本以及传统的 WebMVC。默认就是响应式的如果误引入了spring-boot-starter-webGateway 启动时会直接报错。路由配置里最关键的是StripPrefix参数spring: cloud: gateway: routes: - id: vote-service uri: lb://vote-service predicates: - Path/api/vote/** filters: - StripPrefix2StripPrefix2的意思是删除请求路径前两段也就是删除api和vote最终转发到服务里的实际路径。如果你不配这个服务内部 requestMapping 的路径始终匹配不上所有请求都 404。网关层做统一鉴权是比较合理的做法。我写了一个全局过滤器从请求头里取 Token调用 auth-service 验证验证通过后把用户 ID 放进请求头转发给下游服务。核心逻辑如下Component public class AuthGlobalFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token exchange.getRequest().getHeaders().getFirst(Authorization); if (token null || !token.startsWith(Bearer )) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } ServerHttpRequest mutateRequest exchange.getRequest().mutate() .header(X-User-Id, parseUserId(token)) .build(); return chain.filter(exchange.mutate().request(mutateRequest).build()); } Override public int getOrder() { return -100; } }一个非常重要的经验网关不要做太重的逻辑。比如把用户信息查全量再放行这会让网关变成瓶颈。网关只负责校验 Token 合法性和透传用户 ID用户详细信息由下游服务自行查询 user-service 获取。2.3 三张核心表的 DDL 与设计思路数据库是整个系统最容易出问题的地方表结构设计得好不好直接影响能否扛住高并发。投票系统最核心的三张表如下。第一张作品表work_infoCREATE TABLE work_info ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 作者ID, title varchar(255) NOT NULL COMMENT 作品标题, cover_url varchar(500) NOT NULL COMMENT 封面图, video_url varchar(500) DEFAULT NULL COMMENT 视频地址, audit_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待审 2通过 3驳回, total_vote bigint(20) NOT NULL DEFAULT 0 COMMENT 冗余票数字段, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_audit_status (audit_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有一个设计技巧total_vote字段。冗余票数到作品表查询列表页时免去left join统计表性能提升非常明显。但这个字段也是分布式事务的痛点后面会详细讲。第二张投票记录表vote_recordCREATE TABLE vote_record ( id bigint(20) NOT NULL AUTO_INCREMENT, biz_id varchar(64) NOT NULL COMMENT 幂等业务ID, user_id bigint(20) NOT NULL, work_id bigint(20) NOT NULL, vote_date date NOT NULL COMMENT 投票日期用于按天统计, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_work_date (user_id, work_id, vote_date), UNIQUE KEY uk_biz_id (biz_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;biz_id是幂等关键最前面加这个唯一键是为了防止用户点了一次投票按钮前端超时后重试导致插了两条记录。这里后面会展开讲。第三张投票汇总表vote_statCREATE TABLE vote_stat ( id bigint(20) NOT NULL AUTO_INCREMENT, work_id bigint(20) NOT NULL, stat_date date NOT NULL COMMENT 统计日期, vote_count int(11) NOT NULL DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_work_date (work_id, stat_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;需要注意的是作品表里的total_vote和统计表里的vote_count并不是实时强一致的。列表页展示的票数来自total_vote历史趋势图来自vote_stat。二者天然有一个短暂的不一致窗口我后面会给出最终一致性的处理方案这里按下不表。3. Vue3 前端投票交互与实时榜单的实现3.1 Composition API 还是 Options API前端从 Vue2 迁到 Vue3 之后团队内部刚开始争论一个问题新代码到底用 Composition API 还是 Options API我的结论是投票系统这种交互重、逻辑复用多的项目统一用 Composition API script setup语法。原因很简单投票页有轮次信息作品列表当前选中作品剩余票数投票状态这一大堆状态它们分散在data、computed、methods、watch里用 Options API 写业务逻辑会被打散特别难维护。script setup把逻辑全部写在顶层Mixin 那套让人头大的隐性命名冲突问题也彻底消失了。一个页面的核心业务函数可以按功能拆分到composables目录里逻辑复用非常顺手。看一个简单对比。投票按钮的禁用状态用 Options API 你得同时维护data和watch用 Composition API 只需要一个computedconst props defineProps({ workId: { type: Number, required: true } }); // 我投过哪些作品 const myVotes ref([]); // 当前轮次还能投几票 const remainCount computed(() totalVoteLimit.value - myVotes.value.length); const canVote computed(() { if (!isLogin.value) return false; if (props.workId selectedWorkId.value) return false; return remainCount.value 0; });这样的代码读起来非常直接canVote就是没登录不能投自己不能投自己票数用完不能投三个规则的集合。3.2 投票提交与响应式状态管理投票页最核心的交互就是点投票按钮。我强烈建议前端只做两件事乐观更新 UI 异步提交补偿。所谓乐观更新就是用户点了投票按钮我先不等待后端返回直接把按钮变成已投票同时把列表里的票数1。等后端返回成功就保持现状后端返回失败再回滚。状态管理用的 Pinia这是我个人非常推荐的方式——相比 Vuex 而言Pinia 的setup风格写法天然适配 Composition API而且没有 Mutation直接actions里改数据。// stores/vote.js import { defineStore } from pinia; import { voteApi } from /api/vote; export const useVoteStore defineStore(vote, { state: () ({ voteRecords: [], workList: [], loading: false }), actions: { async submitVote(workId, callbacks) { const rollbackData { ...this.workList }; // 乐观更新 this.workList[workId].totalVote; this.voteRecords.push(workId); try { const { data } await voteApi.submit(workId); // 后端可能返回新的票数和一键防刷校验结果 this.workList[workId].totalVote data.totalVote; callbacks?.onSuccess(data); } catch (error) { // 失败回滚 this.workList rollbackData; this.voteRecords this.voteRecords.filter(id id ! workId); callbacks?.onFail(error); } } } });这个设计里有几个细节要注意乐观更新必须保存在一个临时快照里失败时才能准确回滚。后端返回的totalVote才是权威值UI 上的显示必须同步成后端返回的数字不然并发投票时前端算出来的票数会漂移。投票按钮点击后一定要禁用 2 秒左右这不是后端限制纯属防用户手抖也能减轻接口压力。3.3 实时榜单与 WebSocket 推送榜单是本系统里最有视觉冲击力的模块用户看了自己的作品排名会一直刷新。最开始我用了setInterval每 5 秒轮询一次榜单接口后来发现两个问题每次轮询都要查最新票数榜单接口 QPS 被刷得很高实时性不够用户看到票数变化的延迟感明显。后来改成 WebSocket 推送后端在投票落库后向stat-service发消息由stat-service聚合后推送到前端。前端连接 WebSocket 并订阅轮次主题的代码如下import { ref, onMounted, onUnmounted } from vue; import { useVoteStore } from /stores/vote; const socket ref(null); const store useVoteStore(); function connectRankSocket() { const wsUrl ws://${location.host}/api/stat/ws/rank; socket.value new WebSocket(wsUrl); socket.value.onopen () { // 发送订阅消息告诉后端我关心哪个轮次的榜单 socket.value.send(JSON.stringify({ type: SUBSCRIBE, roundId: currentRoundId })); }; socket.value.onmessage ({ data }) { const message JSON.parse(data); if (message.type RANK_UPDATE) { store.updateRank(message.payload); } }; socket.value.onclose () { // 断线重连 setTimeout(connectRankSocket, 3000); }; } onMounted(connectRankSocket); onUnmounted(() socket.value?.close());这里要强调一个经验WebSocket 的后端前面必须走网关注意 URL 是/api/stat/ws/rank这样网关可以统一做 Token 鉴权。Gateway 天然支持 WebSocket 转发只要路由配置和普通 HTTP 一样即可。还有一个易踩的坑WebSocket 的onclose不等于连接成功断开网络抖动也会触发。重连时要加退避策略否则页面一多服务端会被重连风暴打垮。4. 高并发投票防刷、幂等与最终一致性4.1 投票接口的幂等设计投票系统的核心痛点就是防重复投票。前面表设计里我预留了biz_id这就是幂等键。前端在发起投票请求时生成一个全局唯一的clientRequestId后端在vote_record表里用这个字段做唯一约束。整个投票接口的处理流程是前端生成clientRequestIdUUID携带 Token 发请求。网关鉴权通过后把用户 ID 透传到 vote-service。vote-service 先校验 Redis 里是否已有该clientRequestId如果有直接返回之前的结果幂等。没有则开启事务插入vote_record更新作品的total_vote。提交事务后把clientRequestId写入 Redis 并设置过期时间。对应的 Service 伪代码如下Override Transactional(rollbackFor Exception.class) public VoteResult submitVote(VoteRequest request, Long userId) { // 幂等校验 String key VOTE:IDEMPOTENT: request.getClientRequestId(); if (redisTemplate.hasKey(key)) { return new VoteResult(SUCCESS, 重复请求不作处理); } // 业务校验作品是否存在、是否在投票期、是否重复投 WorkInfo work workClient.getById(request.getWorkId()); if (work null) { throw new BizException(作品不存在); } int rows voteRecordMapper.insert( new VoteRecord() .setBizId(request.getClientRequestId()) .setUserId(userId) .setWorkId(request.getWorkId()) .setVoteDate(LocalDate.now()) ); if (rows 0) { workService.incrTotalVote(request.getWorkId(), 1); // 记录这个请求已处理有效期1小时 redisTemplate.opsForValue().set(key, 1, Duration.ofHours(1)); // 发送消息到统计服务 rocketMQTemplate.convertAndSend(VOTE_TOPIC, new VoteMsg(userId, request.getWorkId())); } return new VoteResult(SUCCESS, 投票成功); }关于幂等我最先踩过的坑是只在应用层做判断没在数据库层面加唯一键。后来发现分布式环境下多个线程同时处理同一个clientRequestId时应用层的hasKey可能同时返回 false导致两条重复记录。加上unique key才能在数据库层面兜底。幂等方案必须是数据库唯一键 Redis 标记双保险。4.2 缓存 异步削峰策略投票场景比普通社交场景更极端的一点是票数需要即时展示但数据库不可能撑住每一票的实时写入。这里我的方案是把写入流程分成了同步和异步两条链路。同步链路处理的是强实时数据——也就是 Redis 里的缓存票数。用户投一票主要操作是INCR voted:work:{workId}将票数加一。Redis 的INCR是原子操作天然支持并发。异步链路做的是最终一致的 DB 落库——用一个定时任务每隔 2 秒把 Redis 中的增量票数同步到 MySQL 里。具体实现思路是// 定时任务每2秒执行一次 Scheduled(fixedDelay 2000) public void syncVoteCountToDb() { // 从Redis的SortedSet中取出有变动的作品 SetString keys redisTemplate.keys(VOTE:COUNT:*); for (String key : keys) { Long workId parseWorkId(key); Integer increment getAndResetIncrement(key); if (increment ! null increment 0) { workInfoMapper.increaseTotalVote(workId, increment); statServiceMapper.increaseDayCount(workId, today, increment); } } }这里有一个重要的取舍投票接口的实时性由 Redis 保证榜单展示也从 Redis 读但用户是否已投过这一类的强一致性判断仍然需要查数据库。如果这个判断也放到缓存里用户投票后立刻取消再投一次缓存和数据库就可能不一致。最终我的实现是用户查询我投过哪些作品时读 Redis 缓存缓存过期后再查库。投票接口处理时校验库里有没有投票记录这是强一致。这种做法的代价是投票接口多了一次数据库查询收益是彻底避免了明明投过还能再投的严重逻辑错误。对于投票系统来说投错比慢一点更致命。4.3 分布式事务千万不要追求强一致这个系统里真正需要事务保障的只有一步投票时插入vote_record和更新work_info.total_vote。在单体架构里这两步用数据库事务就搞定了但拆成微服务后work-service 和 vote-service 是不同的服务跨服务事务就成了难题。一开始我想用 Seata 做分布式事务后来想了想还是放弃。原因很简单投票接口是超高 QPS 场景强一致事务导致的锁等待会直接拖垮数据库。业务上用户投完票后作品表里的total_vote数据延迟几秒钟显示完全可接受。如果正要更新票数的那瞬间服务宕机最多就是丢了这一次增量下次从 Redis 的 INCR 增量里还能补偿。所以我最终选择了消息异步补偿 定时对齐任务的方案投票事务提交成功后发一条 MQ 消息到VOTE_TOPIC。stat-service 消费消息异步更新vote_stat统计表和缓存榜单。定时任务每晚跑一次比对vote_record表里当天的投票数和vote_stat表里的统计值发现不一致就补齐。这个方案绕开了分布式事务的复杂性和性能损失换来的是最终一致性。我在项目文档里明确标注了榜单数据最多延迟 2 秒票数统计次日凌晨对齐。结论是小团队做微服务不要轻易上分布式事务框架那带来的复杂度比你省掉的代码多得多。5. 前后端联调与部署真正让人掉发的细节5.1 跨域问题和网关的正确配置前后端联调阶段最经典的问题是跨域。很多人上来就在 Vue 的 devServer 里配一个代理这在开发环境好使但生产环境一旦前端是纯静态部署、后端在网关后面跨域问题依然绕不过去。我的做法是所有跨域处理统一放在网关层。前端只用一个location.host相对路径拼接口地址不写死 IP 和端口。开发环境用 Vite 的 proxy 把/api代理到网关生产环境则由 Nginx 反向代理。Gateway 里的跨域配置spring: cloud: gateway: globalcors: cors-configurations: [/**]: allowedOrigins: - http://vote.example.com allowedMethods: - GET - POST - PUT - DELETE - OPTIONS allowedHeaders: * allowCredentials: true maxAge: 3600千万要注意allowCredentials: true时allowedOrigins不能写*必须写具体域名。这是浏览器的安全策略踩过这个坑的人非常多。另外前端如果自己又配了一层代理就会造成双重重写路径网关的路由规则怎么调都不对。5.2 OpenFeign 超时、负载均衡和重试的坑微服务之间调用我用的 OpenFeign看起来简单但默认配置坑很多。我遇到最诡异的一个现象是投票高峰期服务间调用大量超时。排查了半天才发现OpenFeign 默认的超时时间是 1 秒而投票服务内部需要同步调用 work-service 做数据校验这个校验有时候要查库1 秒根本不够。调大超时的配置如下ribbon: ReadTimeout: 5000 ConnectTimeout: 3000 MaxAutoRetries: 0 MaxAutoRetriesNextServer: 0这里有一个非常重要的经验在投票这种写接口的场景OpenFeign 的自动重试必须关闭也就是MaxAutoRetries和MaxAutoRetriesNextServer都设为 0。为什么因为一旦 vote-service 调用 work-service 超时后自动重试而第一次请求其实已经成功执行了只是响应超时第二次重试就会导致重复扣减票数。我当初就是没关重试上线后一堆人反馈票数不对。如果业务确实需要重试必须配合幂等。你可以在请求头里带一个requestId在 work-service 里按这个 ID 去重。5.3 Docker Compose 一键部署的经验总结整个项目的部署我写成了 Docker Compose 编排一个命令就能启动全部环境。先看完整文件version: 3.8 services: mysql: image: mysql:8.0.32 environment: MYSQL_ROOT_PASSWORD: vote_root_2024 MYSQL_DATABASE: vote_system ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql redis: image: redis:7.0.10 ports: - 6379:6379 command: redis-server --appendonly yes nacos: image: nacos/nacos-server:v2.2.1 environment: MODE: standalone NACOS_AUTH_ENABLE: true NACOS_AUTH_TOKEN: secret-token ports: - 8848:8848 - 9848:9848 rocketmq: image: apache/rocketmq:5.1.3 ... gateway-service: build: context: ./gateway-service dockerfile: Dockerfile ports: - 8080:8080 depends_on: - nacos - mysql - redis部署上的几个体会Nacos 必须固定 IP 或者使用服务名注册。微服务容器里注册到 Nacos 的地址如果是容器 IP客户端连不上就会调用失败。我最后给所有微服务配了spring.cloud.nacos.discovery.ip指定宿主机内网 IP 或者容器固定网络别名才彻底解决这个问题。前端 Dockerfile 用多阶段构建第一阶段用 Node 构建 Vite 产物第二阶段用 Nginx 跑静态文件镜像体积从 1.2G 降到 80M 左右部署速度快了很多。数据库的max_connections一定要调大并且要在连接池层限制。我踩过一次最严重的坑就是 Nacos 的初始化连接和业务服务抢连接最后数据库连接池直接达到上限。解决方案是所有微服务连接 MySQL 的最大连接数限制在 20不要超过 50。前端 Nginx 配置里最需要注意的是静态资源缓存以及 SPA 路由的回退location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://gateway-service:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }try_files这条指令是 Vue Router 的 history 模式必须配置的少了它刷新页面就 404。6. 复盘体会这次用 SpringCloud Vue3 重构作品投票系统整个过程给我最深的一个感受是微服务不是银弹但当你遇到真实的并发瓶颈时它提供的独立扩缩容能力确实很解决问题。投票服务高峰期可以快速从 2 个副本扩到 8 个而无缝扩容正是单体应用做不到的。另外一点任何架构方案都要结合业务特性做取舍。比如这个项目里我放弃了分布式事务、放弃了 OpenFeign 的重试、放弃了实时榜单的强一致换来的是投票接口的高吞吐和整体系统的稳定。系统上线后压测时单机 QPS 跑到 800 多整个活动期间没有再出现一次白屏和死锁。如果你准备抄这个项目我的建议很直接先把单体版跑通再按文章里的拆分思路把服务切出来最后再逐步加上网关、Nacos、OpenFeign。一步到位容易同时踩好几个坑到时候都不知道问题到底出在哪一环。最后补一个小技巧整个系统调试时记得在网关层加一个/actuator/health透传这样前端、运维、测试三方共享一个健康检查接口排查谁的机器挂了会快很多。祝你的投票系统能扛住下一次活动流量峰。
