食堂就餐卡系统设计

一、设计概述

传统食堂由现金支付升级为就餐卡，会极大的提升食客的体验，食客不用再翻钱包找零钱，也不用纠结现金找零的一堆零钱该怎么处理，同时也能减少单个用户的等待时间。另外刷卡本来就是一件比较冲动的事情，会潜意识的提升单个用户的消费水平，增加营业额。更为重要的是，通过就餐卡为入口沉淀到系统的数据，能帮食堂优化菜品方案，提高利润率。同时有就餐卡这个媒介，运营也就有了土壤，例如多充多送之类的，能快速的把资本回流，减轻现金流的压力。这个业务模式粗看是可以走通的，只要最后系统沉淀的核心数据能够指导运营，以及以后外延出来能有低沉本的供应链基于这些系统的数据来支撑这些食堂，这套系统就会有很大的想象空间。最后，好吃很重要。



1.1 功能描述

• 系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记着消费者的身份、余额。

• 使用时将卡插入收款机则显示卡上金额，服务员按收款机上数字键，收款机自动计算并显示消费额及余额。

• 管理中心的管理员监视每一笔消费，可打印出消费情况的相关统计数据。



1.2 非功能性约束

• 资金模型安全，杜绝人为串改数据的可能

• 查询性能，平均响应时间<300ms, 95% <500, 单机的QPS>80,TPS>100

• 核心系统的高可用>99.98%

• 系统安全性 MD5,Https,散列加密，对称加密



二、系统部署图与整体设计

该系统上线的时候预计4台应用服务器，两个mysql实例，两个Nginx实例，一个运维系统实例，一个前端实例、一台打印机。当前LV0架构无独立子系统，不依赖外部系统（登陆不采用短信登陆或者邮件验证登陆，强密码即可）。



2.1 系统部署图





简要说明：

LBS部署2台Nnginx方便做基础的应用服务器负载，提高入口的稳定性。运维系统先提供部署能力，1台，支持python等脚本用于做一些发布状态的简单检测。外部使用阿里云的日志系统，方便对系统的业务运行情况做监测和分析。数据存储使用两台mysql，默认master-slave模式，非实时的数据查询和报表分析等走slave即可。核心系统目前部署在2台实例上，依赖数据存储系统，日志系统和打印机，可和其他子系统混合部署。



2.2 就餐卡系统内部子系统



简要说明：

虽然LV0的方案是单机部署，但是系统内部的基础边界还是需要的。上图中突出了内部子系统(子模块)之间的简单依赖关系，依赖的基础组件比如日志、异常、id生成器、网关、监控等基础组件并未列出。

api负责和发起端的交互，核心的功能主要依赖用户中心，交易中心，数据中心和账户中心提供的能力来实现。目前让api承担网关的一些工作，提供验签、ip名单、报警、熔断等部分能力。

用户中心提供用户的创建、状态管理、个人信息管理等能力。

账户(务)中心提供账户创建，状态管理，入账(充值、消费退款), 出账(消费、消卡)等基础能力。

交易中心提供用户消费创建交易，扣款的能力。依赖用户中心获取用户额外信息用于构建交易的必要元素，依赖账户中心，需要每次消费之后及时的扣减账户余额。

数据中心依赖于所有子系统(子模块)，用于生成各种运营需要的数据统计或报表，LV0暂时不提供业务事件上报能力。



2.3 核心场景序列图--开卡





简要说明：

客户把开卡需求（提供身份证或手机号作为唯一标识）提给服务员，服务员使用管理系统为客户开卡。开卡的核心逻辑包括两部分，一个是创建用户，一个是初始化账户。完成开卡逻辑之后，系统会产生用户的唯一标识userCode和当前绑定的账户accountCode.



2.4 核心场景序列图--消费





简要说明：

交易有状态迁转，有交易中心的系统往往交易就是整个系统的驱动者。用户消费分为两个阶段，一个是查询余额，余额充足就可以继续消费，不足则应该跳转到充值付费的场景上去。另外一个是余额充足的时候调用交易系统完成交易。交易内部会有一些交易规则做幂等性校验，防止因为网络抖动等原因造成的多笔相同消费的重复请求，也会有一些其他的风控规则,比如一张卡每天最多消费3比之类的。交易也会根据用户标识获取用户信息、校验用户状态（例如是否冻结），然后初始化订单。然后驱动账户系统扣减余额、记账。单机部署的时候不考虑分布式事务，依赖于mysql的情况下，将扣减余额和订单状态的迁转放在同一个mysql事务即可。



2.5 核心场景活动图--消费





简要说明:

活动图能比较清晰的描述业务处理流程、判断逻辑。消费的时候需要先判断用户的状态以及账户的余额等条件，这些条件都满足的时候就可以进入交易流程。交易内部会有幂等 判断和风控，用事务保证了交易的达成和余额的变动是原子性的。



三、账户系统的设计

账户系统的主要职责是对每一点资金的流转都有明确的记录，并且能保护余额的安全，有抵抗一定程度外部风险的能力。包含的组件有：账户的创建服务、账户的状态变更服务、冷冻及解冻资金服务、入账和入账服务，以及内部的任务中心以及风控组件。



3.1 账户系组件图





3.2 场景序列图-- 消费