这两年把业务入口放进微信小程序的企业越来越多。用户不用下载 App，扫码或搜一下就能用，获客成本低，从看到商品到下单的路径也短。但小程序一上线，后端能不能扛住、图片和文件怎么分发、支付回调怎么处理、备案和合规卡在哪一步，很快就会落到开发团队头上。这里以一个本地零售项目为例，讲讲阿里云微信小程序开发中几个绕不开的环节。
一、项目背景与需求拆解
某连锁生鲜品牌要上线会员小程序，功能包括商品浏览、在线下单、优惠券发放和门店自提。初期预估日活约 3 万，大促时瞬时并发可能到平日的十倍。团队只有四个开发，既要保证稳定，又不想在基础设施上耗掉太多精力。
拆需求时，我们把系统分成三层：小程序前端负责交互和调用微信能力，业务服务层处理订单、库存和营销规则，数据与资源层管存储、缓存和分发。每一层都需要一批对应的阿里云产品来撑。
二、架构选型怎么定
在阿里云上搭小程序后端，常见有两条路。一条是在 ECS 云服务器上自己部署 Node.js 或 Java 服务，前面挂负载均衡 SLB 做横向扩展；另一条是用函数计算 FC 或容器服务 ACK，按请求量弹性伸缩。前者可控性强，适合业务逻辑重、长连接多的场景；后者运维轻，更适合流量起伏大的活动型业务。
这个项目最后选了 ECS 加 SLB。订单和库存的事务逻辑比较重，团队对 Java 生态也更熟。大促峰值虽然高，但持续时间短，提前扩容 ECS 实例就够用。图片、视频这类静态资源统一放到对象存储 OSS，经 CDN 分发，源站压力能明显降下来。
关键组件清单
- 云服务器 ECS：部署业务接口。建议至少两台，放在不同可用区。
- 负载均衡 SLB：统一入口，靠健康检查把异常节点摘掉。
- 云数据库 RDS for MySQL：存订单、用户和商品数据。查询压力大时，可以开只读实例分担。
- 缓存 Redis：缓存商品详情和会话信息。库存扣减走原子操作，避免数据对不上。
- 对象存储 OSS 与 CDN：放商品图和活动素材，小程序直接读加速域名。
- API 网关：对外接口统一做签名校验、限流和访问日志。
三、微信侧的对接要点
资源层在阿里云上配好了，小程序能不能跑通，还要看微信后台的设置。这块常被忽略，却最容易在上线前卡住。
先说域名。服务器域名要在微信公众平台的开发设置里配置，请求只能走 HTTPS，域名还得完成 ICP 备案。我们一开始用了一个没备案的测试域名，真机预览时接口全部失败，查了半天才发现问题出在这里。
登录流程里，小程序用 wx.login 拿临时 code，再由后端调微信接口换取 openid 和 session_key。session_key 只能留在服务端，不能下发到前端，过期策略也要提前定清楚。
如果要接微信支付，得先申请商户号，再在服务端配好 API v3 密钥和证书。支付回调必须做验签和幂等处理，重复通知没处理好，订单状态很容易错乱。
四、一次秒杀暴露的问题
上线第二周，运营组织了一场限时秒杀。活动开始五分钟内，数据库 CPU 就冲到 95%，部分接口超时。翻日志后发现两个问题：库存的查询和扣减是分两步做的，高并发下出现大量重复扣减；商品列表接口每次都直接查库，完全没走缓存。
我们做了三处调整。第一，库存扣减改用 Redis 的 Lua 脚本，把判断和扣减合成一次原子操作，扣减成功后再异步写入数据库。第二，商品列表加本地缓存加 Redis 二级缓存，过期时间设为 60 秒，并加入随机抖动，防止大量缓存同时失效。第三，在 API 网关层给秒杀接口限流，超过阈值的请求直接返回排队提示。
调整后，同等规模的活动里数据库 CPU 峰值降到 40% 左右，接口平均响应时间从 800 毫秒降到 120 毫秒。小程序卡不卡，很多时候不在前端，而在后端怎么设计高频读写。
五、上线前的检查清单
- 确认所有接口域名都已备案、走 HTTPS，并在微信后台配置完成。
- 在日志服务 SLS 里确认访问日志和错误日志已采集，告警规则也已设置。
- 数据库定期备份，备份文件存在不算数，要实际演练一次恢复流程。
- 手机号、地址等敏感信息加密存储，接口返回时做脱敏。
- 用户上传的文本和图片过一遍内容安全服务审核，满足平台合规要求。
- 压测核心链路并记下容量上限，大促前的扩容就按这个数字来。
对中小团队来说，选型的重点是和业务节奏对得上。能用托管服务省下的运维精力，就放到业务逻辑上。微信侧的约束和高并发下的数据一致性，是这类项目最容易出问题的两处，上线前多花点时间确认，后面返工会少很多。
