去年下半年我们团队接到一个需求某三甲医院的后勤科希望把院内的线下零售店、职工福利采购、病房外卖配送三条业务线整合到一个系统里同时还要求这套系统能和现有的食堂消费系统打通——职工的餐补余额能在商超扫码消费线上线下库存要实时同步外卖订单要从手机端直接配送到病房床头。起初这听起来像是一个京东到家的院内复刻版但真正扎进去做技术方案时才发现医院场景下的约束条件远比我们预期的复杂。这篇文章从信息科技术负责人的视角把我们在数字商超系统落地过程中踩过的坑和最终跑通的架构方案梳理出来重点讲三个板块系统架构设计、库存实时同步的技术实现以及与食堂消费系统的数据互通方案。如果你们单位也正在考虑类似的院内消费数字化项目这些经验或许能提供一些参考。一、业务场景决定了架构的复杂度先梳理业务边界。数字商超在院内场景下需要同时支撑四个消费终端线下门店POS收银、手机端线上商城、病房外卖配送小程序以及职工专属的福利商城入口。这四个终端的背后共享同一套商品库、同一个库存池、同一套会员账户体系同时还要对接食堂系统的用户账户和餐补余额。初步的需求拆解之后我们面临的核心技术矛盾就很清晰了多终端高并发下的库存一致性保证、跨系统的账户互通与事务管理、以及院内局域网环境对云端部署的约束。这三个矛盾点直接决定了后续的架构选型。二、系统架构设计我们最终采用的是微服务加统一网关的架构模式按业务域拆分了六个核心服务模块商品中心——负责商品基础信息、价格策略、上下架状态的统一管理所有终端从商品中心拉取数据确保同一SPU在各渠道的展示信息一致。价格策略上支持差异化定价比如福利商城的价格可以低于门店零售价但这个差异在商品中心统一配置各终端只做展示不做计算。库存中心——这是整个系统对并发和一致性要求最高的模块。后面单独展开讲。订单中心——统一管理各渠道的订单生命周期包括创建、支付、拣货、配送、签收、售后。外卖订单和自提订单走不同的履约状态机外卖多出分配配送员—配送中—已送达三个状态节点。支付中心——对接微信支付、支付宝、院内卡支付同时承担餐补余额扣减的逻辑。这是与食堂系统接口的核心对接点。会员中心——维护职工和患者两类用户画像。职工账户关联工号、部门、餐补账户患者账户关联住院号、病区床位号用于外卖配送地址的自动填充。配送中心——管理院内配送员的排班、接单、路线规划。配送范围限定在院内所以不需要第三方地图API直接使用院区建筑和楼层数据构建了一个轻量的网格路线模型。微服务之间通过消息队列解耦订单创建后异步通知库存扣减、配送指派和统计埋点避免同步调用链路过长导致响应超时。网关层做统一的鉴权、限流和请求路由前端各终端通过统一的API网关接入。三、库存实时同步的技术实现多终端共享库存最大的挑战在于并发写冲突。典型场景是一个顾客在门店POS结账的同时另一个顾客在小程序上把同一件商品加入了购物车而库存只剩一件。如果处理不当就会出现超卖。我们的方案分三层第一层Redis缓存层。所有终端的库存查询走Redis不直接打MySQL。Redis中以SKU为key存储可用库存数量过期时间设置为永久由更新操作主动刷新。这一层解决的是读多写少场景下的查询性能问题——即便四五个终端同时打开商品详情页也不会对数据库产生压力。第二层分布式锁加预占机制。当用户进入结算流程时系统不是直接扣库存而是先通过Redis的SETNX对一个SKU的预占key加锁然后在缓存中执行库存预占——将预占数量从可用库存中减去并计入预占池。预占有效期设置为十五分钟超时自动释放回可用库存。只要预占成功的订单在支付完成后执行真正的库存扣减落库预占失败的订单在前端友好提示库存不足。第三层MySQL兜底校验。最终扣减时在数据库层面使用UPDATE ... SET stock stock - ? WHERE stock ?和乐观锁版本号双重校验作为最后一道防线。即便极端情况下有并发穿透Redis预占锁数据库的行级锁也能确保账面一致性。入库同步走的是异步消息。门店采购入库后PDA扫码触发入库单入库单落库后发送MQ消息库存中心消费消息后同时更新MySQL和Redis。线上商城、外卖端和小程序的商品库存字段通过库存中心提供的统一接口获取实时数据不需要各终端各自维护一份库存副本。这套方案的实测表现是从门店POS扫码卖出商品到小程序端库存数字归零延迟控制在两百毫秒以内在日均数百单的院内消费量级下完全够用。四、与食堂系统的数据互通方案这是整个项目中最容易出沟通事故的环节。食堂系统和商超系统分属不同服务商的情况很常见如果两边的数据库直接互相暴露接口、甚至试图做跨库联表查询后续的维护成本和故障排查难度会呈几何级上升。我们的原则很明确只通过API对接不做数据库层面的耦合。接口对接的定义中食堂系统提供三个核心API账户余额查询、余额扣减、扣减退款。商超系统在支付中心中封装了一个餐补支付通道——当用户选择餐补支付时支付中心先调用食堂系统的余额查询接口判断可用余额是否充足然后调用余额扣减接口执行扣款。扣款成功后在商超订单中记录扣款流水号若后续产生退款支付中心通过扣减退款接口退回餐补余额。在接口协议层面我们要求食堂系统采用HTTPS加签名校验的方式提供接口签名算法使用HMAC-SHA256请求参数拼接后加时间戳和随机nonce防重放。商超侧的支付中心对接食堂账户时增加了一层本地状态机的保护——每次扣款请求前先在本地记录一个待扣款状态扣款成功后流转为已扣款扣款超时或返回异常则流转为扣款失败并触发自动冲正。这样做的好处是即便食堂系统的接口偶发抖动也不会导致商超侧出现用户付了钱但餐补已扣、订单却显示支付失败的诡异状态。消费记录的归集也是个需要注意的点。食堂系统的消费流水和商超系统的消费流水在两套数据库中但财务对账时需要看到一份完整的消费汇总。我们的做法是在数据中台层建了一张消费明细宽表食堂和商超两端的流水通过定时任务以相同的字段格式同步到这张宽表中财务侧只需查询这一张表即可完成全院消费的对账。五、几个踩坑记录坑一不要低估院内网络的复杂性。很多医院的内部网络是有物理隔离的商超的POS终端、扫码枪和店内Wi-Fi可能分属不同的VLAN部署初期遇到过一个Wi-Fi网段能访问外网、有线POS却只能走内网的情况。解决方案是在门店部署一台边缘计算网关本地缓存库存数据并提供局域网内的库存查询接口POS终端通过局域网访问网关网关再通过唯一一个出网IP与云端服务通信。坑二职工身份校验的粒度问题。医院职工有正式在编、合同制、规培生、实习生、第三方外包等多种身份类型食堂系统和HR系统的职工主数据如果不同步就会出现食堂系统里能查到这个人、但商超系统里没有的尴尬。我们的处理方式是在会员中心中做一个职工身份映射表以工号为唯一key无论哪个来源的职工数据都通过工号对齐兜底策略是如果工号在任一系统中存在有效记录则放行。坑三外卖配送的地址映射。病房外卖需要把订单精确配送到床号这个需求看似简单背后却需要一份准确的病区-楼层-房间-床位映射表。如果医院的HIS或后勤系统没有维护这份数据就需要人工构建和维护。我们的做法是先基于护士站提供的表格建立初始数据再通过配送员接单后的GPS签到和异常反馈持续校正。六、写在最后回头看这个项目技术上的难点其实不在单一模块的复杂度而在于多系统、多终端、多身份交织下的系统工程能力。库存同步考验的是对并发一致性的理解深度数据互通考验的是接口设计的前瞻性和异常处理的完备性而配送、支付、账户这些模块的打磨考验的则是对业务场景中每一个细节的耐心。好伙狮数字食堂提供的数字商超系统在架构理念和技术策略层面都采用了与上述方案相似的思路微服务化拆分、库存预热占、接口级对接、边缘网关兜底。如果你们单位的信息科正在评估类似的院内消费数字化方案建议把验证重点放在库存高并发场景的压测表现、与现有食堂系统的接口兼容性以及弱网环境下的离线可用性这三个维度上——前两个决定了系统上线后的体验平滑度最后一个往往决定了系统在真实院内网络环境下的可用性下限。