同城小程序开发第一次午高峰，监控告警往往同时亮：API 延迟高、数据库 CPU 打满。盲目整机升配贵，只加 CDN 又不解决写库瓶颈。可按链路分层决策。
一、先观测再扩
看 P99：下单 API、订单写入、商家列表、配置拉取。谁最先超 500ms，先扩谁。无数据勿升配。
二、典型顺序
第一步：无状态 API 水平加实例（负载均衡后挂），下单与读配置分离部署更佳。
第二步：读库只读副本或 Redis 缓存热商品与 config_version。
第三步：主库升配或优化慢 SQL（索引、连接池）。
第四步：订单分库或热点商家分区（日单量持续高位再考虑）。
三、不宜先做
整机内存翻倍却仍是单点 MySQL；只加前端 CDN 不解决写库；在 API 里同步跑大报表。
四、峰值前清单
压测目标 QPS；队列堆积告警；数据库连接池上限与实例数联动；配置接口带 ETag 减少重复拉取。
五、私有化与容器
源码交付客户侧时，API 容器化便于快速水平扩容；数据库仍建议托管 RDS 或独立 ECS，不宜与大量容器抢同一节点磁盘。
六、光合同城边界
光合同城支持常规云主机与容器部署；具体架构按客户环境定制；商务规则由客户确定；系统侧不抽成客户平台订单。
七、适合谁
适合小程序已上线、准备迎接第一次午高峰或节日促销的初创团队。
八、监控看板最小集
下单 API P99、订单库 CPU、Redis 命中率、502 次数。先这四项，比一上来堆满 Grafana 面板更易执行。告警短信发给值班和 DBA，午高峰前一小时人工看一次趋势，比事后复盘更有用。
九、常见误区
误区 1：只升数据库不扩 API
写库仍瓶颈，用户感觉「点不动」。
误区 2：连接池过大
实例多了把 DB 打满连接。
误区 3：无只读副本
列表查询拖慢写入。
误区 4：缓存不设 TTL
改价后仍显示旧价。
误区 5：压测只测首页
未测下单链路峰值。
十、小结
午高峰扩容按观测到的瓶颈来：先 API 水平扩、再读路径、最后动写库。连接池与实例数要联动；压测要覆盖下单而非只测首页。私有化小程序宜预留监控四指标与告警接收人，第一次高峰前人工复核趋势，比事后升配更可控。光合同城支持常规云部署与压测验收。第一次午高峰前，建议运营、运维、客服三方同看 30 分钟监控大屏，确认告警能触达值班手机，比只看压测报告更贴近真实协作。
十一、负责人检查表
监控四指标有告警接收人、压测覆盖下单、连接池与实例数联动、只读副本或缓存已启用。午高峰前齐，再对外承诺「稳定接单」。若预算有限，先扩 API 再动数据库，通常比反过来更划算；切忌只升数据库规格却不拆读写在同机抢资源。
十二、预算有限时的优先级
若只能做一件事，优先保证下单 API 水平扩容与连接池调优；第二优先只读副本或 Redis；第三才升数据库规格。很多「午高峰卡顿」其实是 API 单点或连接池打满，而不是数据库本身不够大。先用监控定位瓶颈再花钱，是县城、地级市团队最省预算的扩容方式。扩容决策宜写入运维月报，避免「感觉慢了」就盲目升配。月报应记录「瓶颈在哪一层、做了什么、P99 变化多少」，方便老板看投入产出，而不是只看账单金额。小程序团队人少时，这一条尤其能把扩容讨论从「感觉」拉到「数据」，避免盲目升配。
