3月18日 签约当天定下一条硬规矩

APP开发公司在合同评审时拦下了“先上线再扩容”的设想。医美咨询和项目预约的流量分布极不均匀——日常咨询零散，但每逢直播放号和院庆活动，预约接口会在几分钟内被集中冲击。更麻烦的是医生时段是稀缺库存：一名主诊医生下午两小时只有六个预约档，超卖一次就意味着到店客人和咨询师当场撞车。双方把号源当成秒杀商品来对待，在需求文档里写死一条：上线前必须按放号峰值做全链路压测，不能拿生产环境试错。这条规矩后来在大促里救了两次场。

3月25日 第一周靠压测基线推翻拍脑袋

APP开发公司没有急着买机器，先用历史咨询数据反推峰值。机构过往线下高峰期约每天放号一千二百个，但搬到线上后，一场三小时的直播能引来八千多次观看，放号集中在晚上八点整和上午十点整两个整点，同一时段抢号人数被放大到三到四倍。压测团队按五千 QPS 设了基线目标，并且区分了读多写少的浏览模型和写集中的抢号模型：单台四核八 G 的应用服务器在八百 QPS 时就出现接口超时，数据库两核四 G 的连接池在一千五并发时直接打满。结论很清楚：原计划的两台应用加一台库撑不住放号瞬间。

4月8日 第三周把选型钉死在三层

APP开发公司给出分层方案并写进技术确认单。接入层用 Nginx 做限流和排队，单 IP 每秒放行二十次请求，再叠一层滑块验证挡掉机器刷号；应用层从两台扩到四台四核八 G，无状态容器化部署，方便横向加机器，发布走蓝绿切换不影响预约；数据层最关键——号源库存放进 Redis，用分布式锁防超卖，云数据库升到四核八 G 且开读写分离，连接池拉到两百。月云成本从预估的一千八涨到四千二，拆开看是四台 ECS 约两千四、RDS 约一千二、Redis 加 CDN 约六百；机构算过账：一次超卖引发的客诉赔偿远高于这差价。

4月22日 第五周灰度时撞见一个隐蔽坑

架构落地后做灰度，APP开发公司发现预约成功页的图片和证书资质走的是动态接口，放号时这些静态资源把带宽吃满。机构有二百多张咨询师资质图、五十多张项目对比图，单张原图接近两兆，全部迁到 CDN 并转成 WebP 压到一百二十 KB 后，动态接口只留预约和咨询两件事。灰度按百分之五、二十、五十三档放量，盯 P99 延迟和错误率；两天模拟跑出四千六 QPS，平均响应二百四十毫秒，预约写入成功率百分之九十九点一，剩下那零点九是限流主动拒绝的刷号请求，属于预期内。

5月6日 第七周正式上线，首周只开半量

APP开发公司坚持上线首周只放六成号源，留四成当缓冲。医美咨询侧接入智能分诊，用户上传素颜照后按皮肤、整形、植发等标签进不同咨询师队列，避免热门医生被无效咨询占线；预约锁单设十分钟 TTL，超时未支付自动释放，排队超过十五分钟也自动让位。首周注册一千二，日均咨询两千三，峰值 QPS 稳定在三千一，库存锁零超卖，预约转化做到百分之三十八。运营团队这才把剩余号源在次周放开。

5月20日 上线两周迎首场直播放号

主播喊出“点击下方预约”的瞬间，系统涌入四千八 QPS。APP开发公司提前把 Redis 号源预热到内存，用令牌桶限流，阈值临时调到单 IP 每秒三十次，排队页用长轮询显示实时剩余号数，倒计时三分钟就做预热铺垫。整场二十五分钟放完三千二预约名额，没有一例重复下单；下单后三十分钟未支付自动回库。事后复盘，瓶颈不在应用服务器，而在支付回调的第三方通道偶发慢响应，已加异步重试兜底。

6月10日 院庆大促把承载顶到天花板

运营满月的这天，机构做全年最大促。APP开发公司把应用扩到六台八核十六 G，数据库只读节点加到两个分担咨询历史查询，并把放号错峰成二十点、二十点十分、二十点二十分三批，瞬时峰值比单批直放降了约四成。晚八点峰值冲到五千二 QPS，平均响应二百二十毫秒，预约成功率百分之九十九点三。这一刻系统的状态是：号源库存缓存命中率百分之九十八点七，限流拦截了约百分之六的异常刷号，六台应用服务器 CPU 峰值七成二还有余量，短信通知兜底通道就绪。三月前那张“先上线再扩容”的草图，被钉在了复盘白板的角落。