企业官网建设流程全解析

朋友约我打羽毛球，组了三次局都黄了——不是场地订不到，是每次都有人临时鸽掉。我当时就在想，要是能有个平台，把附近想运动的人凑到一起，把活动信息、报名状态、费用分摊全部线上化，这事情是不是就成了。后来这个念头落地成了这个项目：一个基于微服务架构的运动健身活动招募平台，后端用SpringBoot+SpringCloud，管理后台用Vue，C端直接做成微信小程序。整条链路从需求分析到编码，从微服务拆分到小程序发布，前前后后踩了不少坑，也沉淀了不少经验。如果你正在做类似的全栈项目，或者想从单体向微服务过渡，这篇文章应该能给你一份可直接参考的路线图。

1. 项目背景与业务边界：运动招募平台到底解决什么问题

1.1 从“每次组局都鸽”到平台化的需求梳理

做这个平台之前，我先把身边的运动场景过了一遍。最常见的痛点是三类：第一，信息极度分散，今天在群里喊打球，明天在朋友圈发跑步，后天在小红书找搭子，没有一个统一的活动信息池；第二，报名流程全靠手动接龙，谁报了名、谁付了钱、谁临时退出，全靠群主一个人拿Excel记账，效率低还容易错；第三，缺少信用约束，鸽子成本为零，说好的局说散就散。

所以这个平台的业务定位非常明确：做一个连接活动发起者和参与者的撮合平台。发起者创建运动活动，设置时间、地点、人数上限、费用方式，发布后进入平台活动池；参与者按运动类型、位置、时间浏览活动，一键报名。平台在中间负责审核、通知、数据统计和信用记录。整个闭环是“发起—招募—报名—成局—签到—沉淀信用”。

这里有一个很关键的设计决策：业务闭环必须完整，但范围又必须克制。很多类似项目做着做着就会膨胀，加入社交动态、装备商城、在线课程，最后变成一个四不像。我最后把功能收敛为五块：活动管理、报名管理、消息通知、信用评分、运营审核。这五个模块撑起了一个可用的招募平台，也刚好对应后面微服务拆分时的业务域边界。

1.2 核心业务角色与功能清单

系统里一共有三类角色：普通用户、活动发起者、平台管理员。普通用户和发起者在小程序端操作，管理员在Vue管理后台操作。发起者本质上是用户的一个子角色，用户创建活动时就自动具备该活动发起者的权限。

功能矩阵定下来之后，再想一个事情：哪些功能应该做成高频入口。比如“附近运动”和“分类筛选”必须放在首页最显眼的位置，因为这是C端用户最核心的诉求；“我的报名记录”要放在个人中心第一位，因为用户最关心数据中台是否实时的状态。这个先想清楚，后面设计接口时就不容易乱。

1.3 非功能性需求决定了架构形态

有些人会问：一个活动招募平台，有必要上微服务吗？问这个问题的，通常是没经历过线上流量突发和多人协作开发的场景。我复盘这个项目时，确定了几条非功能性需求，每一条都在把架构往微服务方向推。

第一，C端流量不均匀。一场热门活动在发布后半小时内可能涌入大量请求，尤其是报名接口，存在明显的临界点并发。如果所有模块打包在一个单体里，一次发布活动引起的DB压力、Redis压力、日志压力，会无差别拖垮用户模块和消息模块。

第二，多端同时接入。小程序端是C端主入口，Vue后台是运营入口，下一步很可能还要接管理端的Web版本、未来还可能做支付宝小程序。如果共用一套单体代码，每一个端的小改动都要全量回归，这个成本很高。

第三，团队协作边界。我一个人开发还好，但项目一旦交付给团队维护，用户、活动、报名、消息应该是四条独立的开发线。微服务把一个系统从代码层面拆成四个可以独立开发、独立部署的应用，恰好对应了职责边界。

第四，故障隔离。活动服务出问题的时候，用户登录、消息推送不能跟着挂掉，这是平台型产品的基本修养。

所以结论不是“微服务听起来高级就上”，而是业务形态决定了它需要这种架构。如果你做的是一个纯后台管理系统，没有C端流量压力，那我强烈建议你老老实实用单体，别为了简历好看而上微服务。架构选型永远是被需求逼出来的，不是被技术名词拉过去的。

2. 技术选型与架构设计：从单体到SpringCloud微服务的拆分逻辑

2.1 SpringBoot与SpringCloud各自该干的事

很多初学者会把SpringBoot和SpringCloud混为一谈，其实这两者分工完全不同。SpringBoot是“造车轮的”，用来快速构建一个可独立运行的Spring应用；SpringCloud是“管车队的”，解决的是多个应用之间的服务发现、配置管理、网关路由、负载均衡、熔断降级这些分布式治理问题。

具体到我的项目：每个微服务本体都是用SpringBoot构建的，一个服务就是一个SpringBoot应用；服务之间的协调则由SpringCloud组件完成，包括注册中心Nacos、网关Gateway、声明式调用OpenFeign。SpringBoot保证单个服务“麻雀虽小五脏俱全”，SpringCloud保证多个服务“聚是一团火，散是满天星”。

如果用生活类比来理解：SpringBoot是每位运动员，能力独立，能自训自赛；SpringCloud是教练组和赛事组织方，负责把运动员编排成队、安排赛程、处理突发状况。两者缺一不可，但职责不能互换。

2.2 微服务拆分策略：按业务域拆的决策过程

微服务拆分有很多种思路，我见过最不合理的拆法是把一个单体按技术层拆——controller服务、service服务、dao服务各拆一个，这种拆法等于把一辆车的发动机拆开分三个房间装，车反而跑不了。我采用的是按业务域拆分，每一条业务线都有完整的表现层、业务层、数据访问层。

最终拆成了四个基础服务加一个网关：

• user-service：用户注册、微信登录、信用分、个人资料。
• activity-service：活动的创建、审核、上下架、分类、搜索、详情。
• order-service：报名单生成、取消、支付占位、签到状态。
• message-service：站内信、微信订阅消息的发送任务、阅读记录。
• gateway：统一入口，负责鉴权和路由转发。

每个服务对应自己独立的数据库，表和表之间不直接做外键关联。比如order-service里需要活动标题，会在报名单表冗余一份title字段；需要用户昵称，就冗余一份nickname字段。跨服务的数据查询一律通过OpenFeign调用对方接口获取，而不是直接查别人的库。这个约定写进项目规范里，后面开发时几乎没发生“数据从哪个服务出”的扯皮。

2.3 双端交互的架构链条

架构定下来之后，最难向非技术同事解释的就是“小程序、Vue后台、微服务之间到底怎么串”。我画图的时候习惯用文字链条来说明，逻辑非常直白：

微信小程序发起请求 -> 直达Gateway网关（域名统一） -> Gateway根据路径前缀转发到对应微服务 -> 微服务处理完返回统一响应体 -> 小程序渲染数据。

Vue管理后台的链路一样，也是先到Gateway，只不过请求路径带的是/admin前缀，网关内的过滤器会额外校验管理员的权限角色。两条链路共享同一套JWT校验机制，所以网关里的全局过滤器只写一份，双端同时生效。

这样设计的好处是，小程序端永远只需要知道一个域名，后台也只配置一个接口地址。前端完全感知不到后端的微服务拆分，这对不带业务压力地做前端开发非常重要。后续无论哪个服务重构，只要对外接口协议不变，前端零改动。

3. 后端微服务核心模块：活动、用户、报名与消息

3.1 活动服务：从创建到结束的状态机设计

活动服务是整个平台的业务核心，它管理的数据模型是“活动”，而活动从创建到消亡，经历的状态远不止“有”和“无”两种。我设计了一个活动状态机，这是整个服务里最重要的部分：

DRAFT（草稿）→ REVIEWING（待审核）→ PUBLISHED（招募中）→ FULL（已满员）→ FINISHED（已结束）

这个状态机里有两个重要分支：一个是PUBLISHED状态下若发起者主动取消活动，则直接跳到CANCELLED；另一个是FINISHED之后不允许任何状态修改，保证数据可归档、可审计。

为什么状态机这么关键？因为在多服务环境下，活动状态不是一个前端按钮能随便改的。比如活动从PUBLISHED变为FULL，可能是报名服务那边人数满了然后调用活动服务接口来调整的，也可能活动过期被定时任务触达的。如果状态更新逻辑分散在各处，后续排查数据异常时根本无从下手。统一收敛到activity-service里，用一张状态流转表map维护“谁可以触发什么流转”，开发时只需要调用对应方法，不用到处打补丁。

3.2 用户服务：微信登录态与JWT的双层鉴权

微信小程序的登录流程是固定套路，但真正做微服务化时有几个细节得注意。小程序端调用wx.login拿到临时code，然后请求后端登录接口。user-service拿着code调微信的code2Session接口，拿到openid和session_key。这里有个容易踩的坑：code是五分钟有效且只能用一次，所以user-service里不能做缓存，必须每次实时换取。

拿到openid后，我封装了一个自定义JWT，登录成功时返回给小程序端，token里包含userId、openid、role三个字段。JWT的有效期设置成7天，小程序端每次请求在headers里带上token，gateway拦截器解析后把userId放到请求头里传给下游服务。后续所有服务从请求头取userId，而不是从JWT里反复解析。

有一个经验值得分享：JWT里的信息千万不要塞太多。我一开始图方便把用户昵称、头像、信用分都塞进去了，后来发现每次用户改昵称都会导致旧token里信息过期，处理起来非常麻烦。最后只留userId、openid、role这三个不变属性，其他动态数据一律通过接口查询。这是很典型的“最少字段原则”，做认证设计时越早想明白越好。

3.3 报名服务：分布式场景下的库存扣减设计

报名服务是“并发压力最集中”的模块，核心问题是怎么在人多的时候保证不多卖一个名额。最初我直接在MySQL里用update语句扣库存：

update activity set current_count = current_count + 1 where id = ? and current_count < max_count

这种方式依赖数据库行级锁，小流量下没问题，但一旦活动热门，同一时刻几千个请求打过来，数据库连接会被阻塞，性能立刻恶化。而且它无法解决“用户稍后取消报名再重新报名”时的事务复杂度。

我在项目里采用的方案是Redis预占 + 异步落库。用户点击报名时，请求先打到order-service，服务先在Redis里用Lua脚本原子扣减活动剩余名额，扣减成功则生成报名单并返回“报名成功”，同时把一条落库消息发到MQ；扣减失败则直接返回“名额已满”。数据库表的报名记录由消费者异步写入，保证C端响应速度和最终一致性。

这套设计真正回答了“微服务里要不要强事务”这个问题。如果了报名、扣库存、发消息全都要求同步强一致，那就要引入Seata分布式事务，链路复杂度和失败重试成本会成倍上涨。对于运动活动这种业务场景，极端情况下丢失一条报名消息的损失远比系统崩溃要低，所以选择最终一致性是划算的。如果做的是库存扣减和支付强关联的业务，就别学这个方案，老老实实引入分布式事务框架。

3.4 消息服务：通知推送的数据流转

消息服务在架构上常常被忽略，但它往往决定用户留存。这个项目里消息分为两类：站内信和微信订阅消息。

站内信的数据结构很简单：senderId、receiverId、contentType、content、isRead、createTime。当活动状态变化时，activity-service会调用message-service的OpenFeign接口，传入用户维度的消息内容。为了让调用方不被慢接口拖累，所有消息发送都采用了异步：服务间不直接同步等待消息入库结果，而是发到MQ，由message-service消费后走自己的逻辑。

这里有一个跨服务调用的反模式值得警惕：一开始我是让order-service直接连消息服务数据库来插记录，因为“图省事”。结果一次数据库字段调整让对方服务全部报错。后来强制改成“服务间禁止查库，只许调接口”，数据异常情况立刻清零。这个约束看起来死板，但就是微服务架构下最省心的规约。

4. 微信小程序端的关键实现与适配细节

4.1 页面架构与底部Tab导航

小程序端我用的是原生微信框架，没有引入uni-app。原因是这个平台的核心页面都是列表和表单，没有跨端复用的强需求，原生框架的调试和性能更可控。整个小程序一共有四个Tab：首页（活动推荐流）、发现（运动分类筛选）、消息（站内信列表）、我的（个人中心）。

首页的定位是“能不能让我一眼看到今天可以报什么局”，所以采用信息流卡片布局，每一张卡片展示活动封面、标题、运动类型、时间地点、剩余名额和距离。发现页标题栏上方放置了横滑分类tab，包括篮球、足球、羽毛球、跑步、健身、瑜伽、骑行等，点进去按分类过滤活动列表。消息页只做一个会话式的站内信列表，点击进详情。我的页面集中处理个人资料、我发起的活动、我报名的活动、信用分和设置。

4.2 分页加载的经典落地：onReachBottom与数据协议设计

小程序列表页最容易被做成“一次性渲染全部数据”，数据量一上去页面直接卡死。这个项目里我用的是经典的onReachBottom触底加载方案。

列表页在onShow时请求第一页数据，接口参数为pageNum和pageSize，固定pageSize=10。响应体设计成标准的分页结构：

{ "code": 0, "data": { "records": [], "total": 57, "pageNum": 1, "pageSize": 10, "hasMore": true } }

hasMore字段由后端计算并返回，前端只需要维护一个currentPage变量。onReachBottom触发时判断hasMore为true才发起下一页请求，为false则提示“没有更多了”并停止请求。这个实现很简单，但有两个细节值得敲黑板：在请求下一页时必须先加一个标志位loadingPage，防止用户手滑连续触发多次请求；在分页请求返回前，列表末尾需要显示一个加载中占位组件，由wx.showLoading或组件内的loading状态控制，避免用户以为页面卡死了。

我的实际操作中，第一次上线时没有处理loadingPage问题，快速上滑时会出现同一页数据重复插入，页面数据一度乱了套。加上标志位之后这类问题再没出现过。

4.3 顶部导航栏高度适配：自定义导航的兼容处理

小程序如果是用系统原生导航栏，标题位置和胶囊按钮位置是系统自动布局的，但一旦需要自定义导航栏，通常会遇到两个问题：顶部安全区高度在iPhone X和有刘海机型上不太一样；自定义按钮和胶囊按钮右侧挨着太近会重叠。

我的处理方式是，在app.js的globalData里异步读取胶囊按钮信息，同时通过wx.getSystemInfoSync读取statusBarHeight，然后动态计算导航栏高度。具体公式是：胶囊按钮顶部到屏幕顶部的距离 = statusBarHeight，胶囊按钮高度约32px，所以导航栏的自定义高度 = statusBarHeight + 4px（上边距）+ 32px + 4px（下边距）。通过style绑定动态设置占位View的高度，再把内容渲染在这个高度之下，就不会发生遮挡或挤位。

这个细节看起来是小问题，但在真实使用中有刘海屏机型占了很大比例，不做适配的话标题会顶到状态栏里，观感非常差。

4.4 登录态管理：wx.login与本地存储的配合

小程序登录的经典流程是先调wx.login拿code，再通过后端接口换token。我在根目录封装了一个request.js工具函数，内部统一做三件事：每次请求前从本地缓存读取token并注入header；如果接口返回401，自动清掉本地token并跳转到登录页面；如果接口返回其他错误码，统一弹出wx.showToast提示。

有一个必须提醒的坑：wx.login必须放在用户点击行为回调里调用，不能放app.onLaunch里无脑调，否则部分iOS版本会出现获取不到code的诡异情况。另外token过期后不要直接让用户退出登录，而是静默重新wx.login换新token，然后重放刚才失败的请求，这样用户的体验是“仿佛没有登录这件事发生过”。实测这个小细节对用户体验提升非常明显。

5. Vue管理后台的实现与打包部署

5.1 后台技术栈与权限控制要点

管理后台选用的是Vue3 + Element Plus + Pinia + Vue Router + Axios这套组合。相比Vue2，Vue3的组合式API在处理复杂的权限逻辑时清爽很多，Pinia也比Vuex轻量。

后台的权限控制是整个前端最核心的部分。我没有用纯前端路由守卫控制页面跳转，而是采取“登录后拉取角色权限 → 动态注册路由 → 渲染菜单”的方案。用户登录后，后端返回当前管理员拥有的一组权限标识符，比如activity:audit、user:ban、statistics:view，前端把这些标识符存进Pinia，然后根据标识符动态生成对应的路由记录，用router.addRoute逐个注册。

这套方案比一次性注册全部路由再通过v-if隐藏菜单更安全，因为未授权的页面在路由表里根本不存在，访问会被直接拦截到404页。

5.2 动态路由与菜单权限的角色联动

具体到实现，我在src/router里维护了两类路由：constantRoutes和asyncRoutes。constantRoutes是登录页、404页等无需权限的基础路由；asyncRoutes是一份映射了权限标识的完整业务路由表，每个路由定义里带meta.roles或meta.permissions字段，表示哪个权限可以访问。

登录成功后，前端调用permissionStore生成用户可访问路由列表，再通过addRoute动态添加。侧边栏菜单不是写死的，而是根据动态路由表递归生成，所以“权限控制”和“菜单显示”天然绑定，不会出现用户没有某个权限却看到对应菜单的丑陋场景。

这里要特别提醒的是刷新页面时vite-pinia里存的权限数据会丢失。解决方法是把权限标识持久化到localStorage，刷新后重新根据本地权限标识重建路由表。如果只存内存不落盘，每次刷新都会跳回登录页，这个坑我经历了三次才彻底修好。

5.3 Vue构建产物整合进SpringBoot的两种方式

管理后台的前后端是分离开发的，但部署时有两条路径可选。第一种是把Vue构建产物放在后端服务的static目录下，让SpringBoot直接托管静态资源；第二种是单独用Nginx托管前端，通过反向代理把/api请求转发到网关。

我的选择是第一个：Vue构建后把dist目录的内容拷贝到gateway服务的src/main/resources/static里，然后设置一条不存在的后端接口与前端history路由的兼容规则，即遇到404请求时forward到index.html。这种方式对中小型项目最友好，一台服务器搞定环境，不需要单独部署Nginx，也避免前端跨域问题。构建后唯一需要改的是Axios的baseURL，因为前端和后端同源，直接写/api前缀就行。实测下来这套方案跑得很稳。

5.4 活动审核与数据统计面板的核心逻辑

管理后台最核心的两个页面是活动审核和统计面板。活动审核页本质上是一个条件列表加一个审核弹窗，列表接口走activity-service的/admin/activity/list，审核通过或驳回时调用审核接口，后端通过状态机事件把活动状态从REVIEWING流转到PUBLISHED或REJECTED。

统计面板我用了ECharts，图表有三个：按周统计活动发布趋势、按运动类型统计参与人数、按城市统计热门区域。数据来源不能直接查活动库，因为涉及用户维度的报名数据，所以统计接口由activity-service通过OpenFeign调用order-service聚合数据，再返回给前端。这里前端只需要关心一个统一聚合接口的返回结构，不需要感知后端数据从哪几个服务拼起来的。

6. 微服务工程化落地：Maven多模块与配置管理

6.1 多模块Maven项目结构与依赖管理

从单体切到多服务后，工程结构是第一道槛。我采用标准的Maven多模块结构，父pom的packaging声明为pom，下面按顺序放common、gateway、user-service、activity-service、order-service、message-service。

父pom里只做两件事：统一版本管理和公共依赖声明。特别是Spring Cloud与Spring Boot的版本兼容性，必须有对应关系表约束，不能随意升级。我吃过一次大亏：SpringBoot从2.3升到2.5后，Nacos客户端的版本不兼容，服务注册失败，排查了一整天才发现是版本配对问题。后续项目彻底改用BOM（Bill of Materials）管理版本，也就是父pom引入spring-cloud-dependencies和spring-cloud-alibaba-dependencies的BOM，子模块只声明需要的依赖groupId和artifactId，版本号全部交给BOM托管，闭眼升级不再出兼容问题。

6.2 Nacos注册中心与配置中心的实际用法

注册中心我选的是Nacos，理由有两点：一是它同时提供注册中心和配置中心两个能力，省去了引入Eureka加SpringCloudConfig两套组件的复杂度；二是Nacos控制台自带服务健康检查，开发期排错直观。

每个服务启动时都会自动注册到Nacos，服务名由spring.application.name指定。order-service里要调用activity-service的接口时，用OpenFeign的@FeignClient(name = "activity-service")声明，底层由负载均衡去Nacos拉取可用实例列表，然后随机或轮询选择目标地址。这种服务间调用对我们的开发体验影响最大——再也不用在配置文件里写死各个服务的IP和端口，而是只通过名字互相定位。

配置中心的使用有一个性能注意事项：Nacos的配置变更虽然是实时推送的，但数据源连接、Redis连接池这类资源型Bean不会因为配置刷新而自动重建，需要添加@RefreshScope或手动监听。我在项目里只把活动的推送阈值、积分规则这类非资源型配置放在Nacos动态刷新，数据库连接等由启动时加载，避免刷新导致连接池被意外销毁。

6.3 服务网关鉴权：把JWT校验收口到一处

网关是整个微服务集群的“大门”，鉴权必须在门口做，而不是在每个服务里各做一遍。我的gateway里实现了一个全局过滤器，逻辑很简单：拦截所有请求，根据请求路径判断是否为白名单（登录、活动列表、分类列表、活动详情），白名单直接放行；非白名单请求提取Authorization头，校验JWT签名，校验通过后把解析出来的userId和role放入请求头，传递给下游；校验失败则返回401。

这里有个细节：JWT校验需要引入一个jackson解析工具来解码token里的Payload，但gateway是基于WebFlux的响应式框架，跟Servlet环境下的工具类有些兼容性问题。解决方案是用jjwt这个只依赖java-jwt协议的库来做校验，不要引入Servlet相关的内容。我在集成过程中踩过一次ClassNotFoundException，最后把依赖收敛成jjwt的相关库后问题解决。

网关收口鉴权的最大好处是，后续新增微服务时不需要重复实现认证逻辑，新服务只管业务。这一点在团队协作中的价值会放大得非常明显。

7. 部署实战与环境配置清单

7.1 安装清单与规划：MySQL、Redis、Nacos的服务分配

部署这块我整理了一份标准的安装规划，方便直接照做：

我实测下来，一台4核8G的云服务器足够支撑这个平台的小规模线上运行。两个Nacos实例、四个业务服务、一个网关全部部署在同一台机器上，注意预留足够的内存空间，避免OOM。如果预算允许，推荐把Redis单独放一台，因为报名高峰期Redis的CPU和内存压力最大。

7.2 微信小程序正式发布前要过的几道关

小程序发布前有几道关卡，每一关漏掉都会导致线上体验断裂。第一关是域名白名单：小程序生产环境请求的接口域名必须在微信公众平台后台配置为合法域名，且必须为HTTPS协议。如果你是用IP地址访问后端，小程序直接连域名校验都过不了，必须给后端配置一个备案域名并申请SSL证书。

第二关是业务域名和服务器域名是分开的：如果你要跳转某个H5页面或是下载文件，需要单独配置业务域名，并上传校验文件到对应服务器。一般简单项目不涉及，但如果你做了活动详情里的外部跳转，一定要提前申请，微信审核流程比较长。

第三关是审核类目：运动健身活动招募平台在微信的类目划分里属于“生活服务>运动健身”或“工具>信息查询”，上传审核时要选对。首次提交审核还会要求提供营业执照或相关资质，个人主体的开发者有时会被卡在类目上，建议提前在微信公众平台查看要求。

7.3 分布式环境下的问题排查链路

多服务环境一旦出问题，排查链路清晰能省一半时间。我在项目中总结了一套“从外到内”的排查顺序：

先看用户请求到达哪个环节。打开小程序开发者工具的Network面板，看接口请求是否发出、是否返回401或504。401说明网关鉴权没过；504说明网关服务或者下游服务根本没起来。

再看服务注册情况。打开Nacos控制台，确认gateway和四个业务服务是否全部处于健康状态。如果某个服务没注册上，大概率是配置文件里的Nacos地址写错，或者服务启动时没有成功连接到Nacos，翻服务日志能看到连接异常的堆栈。

再看日志。四个服务分别输出到独立的log目录，排查跨服务问题时用traceId串联请求链路。我在common模块里定义了一个全局过滤器，为每个请求生成UUID作为traceId，打印在响应头里，前端报错时把traceId发过来，直接搜日志就能定位问题出在哪一段。这个习惯在单体时代不必要，但微服务时代没有traceId几乎没法排查问题。

最后看数据库和缓存。报名接口异常时，先看Redis里剩余名额是否被扣减但数据库没有对应记录，这种情境大概率是MQ消费者没消费或消费失败。我的处理方式是把消费失败的消息重试三次，三次仍失败写入失败日志表，运营后台能看到并对这些消息做人工补偿。

7.4 一次真实的线上排查复盘

最后分享一个我在项目中真实踩过的坑。上线第三天，有用户反馈“活动列表能打开但报名一直转圈”。我打开Nacos发现order-service还在，但日志里疯狂报Redis连接超时。排查后发现是报名量激增导致Redis连接池耗尽，后续的报名请求全部排队等待获取连接，看起来就跟卡死了一样。解决方案是两步：把Redis连接池的最大连接数从默认值调大，并对报名接口增加前置限流；更关键的是把“生产端报名请求同步扣减Redis”和“消费端异步落库”的操作拆得更彻底，不要让请求线程长时间占用Redis连接。

经过这次之后，我把Redis、MySQL连接池的参数全部纳入了配置中心管理，并在压测环境里用JMeter模拟了20倍日常流量的请求，确认连接池大小、线程池队列、MQ消费速率三者的关系是匹配的。这个经历给我的体会是：微服务架构里基础设施的性能参数，重要性一点不比业务逻辑低，提前压测和预留容量才是保命的操作。