预约核销一体的小程序架构

预约加核销，一定要拆微服务吗？绝大多数门店和小机构用不着，一台云服务器就能把整套业务跑顺。这类项目的复杂度不在架构，在开抢瞬间和核销安全这两个点上。 业务链路有多简单 流程很短：用户选时段、填信息、提交预约，到店出示核销码，店员扫码完成核销。数据只有三张核心表：场次、预约记录、核销记录。单体应用加一个关系型数据库，前面挡一层反向代理，就够了。日志重点记录预约创建和核销动作，出了纠纷随时能对账。 开抢瞬间才是考验 热门场次放出时，并发会在几秒内冲上来：一千个名额，瞬间涌进几千次提交。扣减余量必须原子化，先查再扣不能拆成两步，用数据库的条件更新（余量大于 0 才减 1）或缓存里的原子递减都行，关键是不能先读后写。前端把按钮置灰、提交前加一道图形验证码，能把无效请求拦掉一大半，数据库的压力立刻小一截。 核销码的防伪与防重 核销码要满足三点：难猜、一次性、有时效。码值用随机数生成而不是自增序号，服务端校验签名和时间窗；核销动作加唯一约束，同一个码第二次扫码直接拒绝，防止店员手抖重复核销。状态流转（未使用、已核销、已过期）在库里留全记录，核销再带上操作员和时间，出了问题责任能落到人。 配置怎么定 日预约几千单的量，2 核 4G 起步就能支撑；周末场次靠抢的项目升到 4 核 8G，缓存单独部署更稳。顺云的高防云服务器 S4-8G 是这类有小峰值应用的合适选择，面向公网的小程序也确实需要基础的流量防御兜底。 预约核销类项目先用单机跑通，等单机真扛不住再考虑拆分，多数项目其实等不到那一天。