4、系统架构基础：宠物美容系统的常见架构（前端、后端、数据库、第三方服务）及集成点
宠物美容业务从门店前台接待、美容师排班、宠物档案管理，到耗材库存、会员营销、线上预约，涉及的角色和流程远比想象中复杂。一套可落地的宠物美容系统，并非简单“做个网页+存数据”，而是需要将前端交互、后端业务逻辑、数据持久化以及第三方生态服务（如微信支付、短信通知、电子发票）有机整合。本章将拆解宠物美容系统的分层架构，明确各层职责、关键集成点以及落地时的常见陷阱。
4.1 核心原理：分层架构的职责边界与数据流向
宠物美容系统的架构设计遵循“高内聚、低耦合”原则，通常划分为四层：前端展示层、后端服务层、数据存储层、第三方服务层。每一层只解决特定领域的问题，层与层之间通过标准接口（RESTful API / RPC / 消息队列）通信。
- 前端展示层：面向三类用户——门店收银员（Pad/PC）、顾客（小程序/H5）、店长/区域经理（管理后台）。核心职责是交互体验与数据可视化，不承载业务规则。
- 后端服务层：业务逻辑的核心，包含预约排班、美容师绩效、宠物档案、计次卡/会员卡、库存耗材、营销活动等模块。该层必须保证事务一致性，例如“扣减库存”与“创建订单”需在同一事务内完成。
- 数据存储层：MySQL存储结构化业务数据（订单、会员、商品）；Redis用于热点缓存（如当日预约看板）、分布式锁（防止并发开单）；MongoDB存储宠物图片、美容前后对比照等非结构化数据；Elasticsearch用于门店搜索、销售报表分析。
- 第三方服务层：支付（微信/支付宝）、短信通知、电子发票、地图定位、对象存储（OSS）、云推送等。这些服务通过API集成，但必须考虑网络异常、回调延迟、签名安全等问题。
数据流向遵循“前端发起 → 后端校验与业务处理 → 数据落库 → 异步通知第三方 → 回调更新状态”的链路。例如顾客在小程序预约美容服务，后端先校验美容师档期，创建预约记录（状态：待支付），调用支付API生成预支付单，顾客支付成功后微信回调通知后端，后端更新订单状态为“已支付”，并推送消息给门店PAD端。
4.2 判断方法：如何根据门店规模选择架构形态
并非所有宠物美容系统都需要微服务架构。架构选型应基于门店数量、并发峰值、团队维护能力三个维度判断。
| 门店规模 | 并发/日单量 | 推荐架构 | 关键理由 |
|---|---|---|---|
| 单店/夫妻店 | <50单/日 | 单体应用（前后端不分离） | 成本低，维护简单，一台云服务器即可 |
| 区域连锁（3-10家） | 200-500单/日 | 前后端分离 + 单体后端 + MySQL + Redis | 支持多门店数据隔离，缓存提升查询效率 |
| 跨区域大型连锁 | >1000单/日 | 微服务（用户/订单/排班/库存分拆）+ 消息队列 | 独立伸缩排班服务，应对节假日峰值 |
判断流程建议：先梳理核心业务流程（预约→支付→服务→评价），识别出强一致性的模块（订单与支付）和弱一致性的模块（消息通知、报表统计）。强一致性模块放在同一个服务内，弱一致性模块通过消息队列解耦。
4.3 案例拆解：某连锁品牌系统集成落地实战
背景与约束：某宠物美容连锁品牌拥有12家直营门店，日均订单约400单，高峰期（周末）可达800单。原有系统为Excel+微信群管理，经常出现预约冲突、会员卡余额对不上账、耗材库存缺失等问题。管理层决定上线一体化系统，要求：①顾客可微信小程序预约；②门店PAD端接单与开单；③总部实时查看各店营收与耗材消耗；④与微信支付、短信通知、电子发票集成。
初始现象与目标：上线前两周，系统频繁出现“预约成功但门店未收到通知”“支付成功但订单状态未更新”的问题。目标是将订单支付成功率提升至99.5%以上，预约冲突率降为0。
关键输入数据与日志分析：通过排查后端日志，发现两个核心问题：
- 支付回调丢失：微信支付回调超时后，后端未实现主动查询订单状态的补偿机制。日志显示大量“支付回调超时，订单状态仍为待支付”。
- 预约并发冲突：两个顾客同时预约同一美容师同一时段，后端由于未使用数据库行锁或Redis分布式锁，导致双写成功。
实际操作步骤：
- 针对支付回调：增加定时任务（每5分钟）主动调用微信支付“查单接口”，对比本地订单状态，若本地为“待支付”而微信侧为“已支付”，则自动更新状态并触发后续流程。
- 针对预约冲突：在数据库预约表中增加唯一索引（美容师ID+开始时间+美容台ID），并在服务层使用Redis分布式锁（key=预约时段+美容师ID）进行双重校验。
- 针对通知延迟：将短信/微信通知改为MQ异步发送，失败自动重试3次，并记录死信队列人工处理。
结果对比：上线修复后，支付订单状态更新延迟从平均3分钟降至10秒以内，预约冲突率降为0，顾客投诉量下降80%。
风险与代价：引入定时任务查单增加了微信API调用量（成本略有上升）；分布式锁需注意锁超时时间设置，避免因业务处理时间过长导致锁自动释放引发并发问题。
复盘经验：第三方集成必须设计“补偿机制”，不能只依赖回调；资源型业务（预约）必须使用数据库唯一约束+分布式锁双重保障。
4.4 常见误区与总结复盘
在宠物美容系统架构落地中，以下误区最为常见：
- 误区一：忽略美容师资源排班的复杂性。将美容师当作普通“商品SKU”处理，导致无法处理“服务时长不同”“美容师可同时服务多只宠物（如寄养）”等场景。应建立独立的排班服务，支持时间片、技能标签、并行服务能力配置。
- 误区二：第三方服务集成不做降级方案。短信服务宕机、支付接口超时是常态。必须为每个第三方依赖设置超时时间、熔断器（如Sentinel）和降级预案（如短信失败改用公众号模板消息）。
- 误区三：数据库表设计缺乏扩展性。宠物美容涉及“计次卡”“年卡”“次卡+商品组合”等复杂计费模型，若一开始就设计死字段，后续改造成本极高。建议采用“订单-明细-支付流水”三张核心表，配合扩展属性JSON字段。
- 误区四：忽视数据报表的实时性要求。店长需要实时看到今日营收、耗材余量，若直接查询MySQL主库，高峰期会拖垮业务。应使用读写分离，或通过 Canal 同步到 Elasticsearch/ClickHouse 进行报表查询。
总结复盘：一套成功的宠物美容系统架构，核心在于理清业务边界、识别强依赖、设计补偿机制。前端追求体验流畅，后端保证数据一致，数据库合理分型，第三方服务做好降级预案。架构师应深入理解“美容师排班”“计次卡核销”“耗材扣减”这三个业务痛点，在架构层面提前预留扩展点。下一阶段，我们将深入探讨数据库表结构设计，重点讲解如何用数据模型支撑复杂的计费与库存场景。