在郑州承接大型活动报名系统时，我一开始就被并发和错峰报名折磨过：同一时刻数万用户涌入，表单重复提交、座位超卖、短信验证码延迟，问题一项接一项。那次项目迫使我把“稳定性优先”落到每个技术决策上，不是口号，而是代码与运维的连带责任。

      架构上我倾向于用微服务：核心用Go做后端，gRPC内部通信，REST/GraphQL对外，前端用React+TypeScript，移动端用Flutter打包单一代码库。选择Go并非情绪化——它的协程模型和连接池让高并发场景下延迟更可控；gRPC减少序列化开销，有利于服务间大量短连接。数据库主选MySQL，读写分离，分库分表按活动维度拆分，同时用Redis做热点计数和缓存。

      关于“名额抢占”我有一套实操：把名额逻辑下沉到Redis，使用Lua脚本做原子扣减，结合唯一幂等键避免重复下单。实时显示余票靠WebSocket推送；遇到老旧网络，退回短轮询。曾经因为不恰当的锁策略导致P99激增，后来改用轻量级乐观锁+后端补偿，延迟反而下降了。

      压测与故障演练不能省。我们用k6做并发压测，Kafka回放异步事件，Prometheus抓指标，Grafana看仪表板。遇到连接泄漏，定位流程是：先看trace（Jaeger），再看堆栈与连接数，最后回溯到第三方SDK版本。经验告诉我，短周期小范围混沌测试，比年终大演习更有效。

      集成层面关注点很多：短信网关有丢包，接入时加重试与幂等；支付回调要幂等校验并做好二次确认。日志按结构化JSON输出，按trace_id聚合，便于在问题发生后把前端请求、后端处理、消息队列流转串成一条链。数据治理上做脱敏与最小化存储，满足合规需求。

      实操中常碰到意外：时钟漂移导致JWT提前过期；Kubernetes节点资源争用使Pod被驱逐。解决办法往往是细节上的坚持：NTP同步、开启readiness/liveness探针、用HPA结合自定义指标。我的习惯是“先看链路，再看代码”，这条经验救过无数紧急票。

      展望部分：对突发流量，可考虑将热点逻辑迁移到边缘函数或WASM，减轻中心后端压力，但要注意冷启动与调试成本。我的建议是分阶段迭代：先用成熟稳定方案兜住业务，再逐步引入边缘与无服务器优化，边测边改，风险更可控。