食堂就餐卡系统架构设计

在传统就餐模式中，使用普通的票据就餐需要额外付出很高的运营成本，比如票据的防伪、财务的计算、实时交易情况监控，交易对账，都需要耗费很大时间成本和财务成本。
随着科技的发展使用计算机软件系统解决这一常见问题成为可能。本系统旨在解决传统模式中出现的一系列痛点。

食堂就餐卡系统是一个应用范围很广的系统，在政企食堂、院校食堂、商超、美食街，凡是有食堂的地方，都需要这么一套系统来解决传统模式的问题，实现快速充值缴费、消费、
结算，节约食堂承包商的财务成本与管理成本，流程方便快捷，简化客户与商户的交互流程，提升食堂客户服务吞吐量，实现企业的降本增效，具有很高的应用价值。

管理中心包括的功能：就餐卡管理（挂失、作废）、卡账户查询、卡交易记录（充值、消费），商户管理、商户账户查询、商户交易记录（收款、提现）、
统计报表（商户分时交易统计、商户日消费、月消费统计）、商户提现审批、消费订单管理、充值订单管理

交易子系统：卡信息校验、卡余额查询接口、订单创建接口、卡充值接口

充值缴费客户端：NFC读卡、查询展示餐卡余额、餐卡充值

商家消费客户端：NFC读卡、查询展示餐卡余额、创建订单

一所高校的学生一般3w人左右，假设全部在食堂就餐，吃饭时间点11:30-13:30，那么两个小时内的交易量三万单，假设每人发起两单，那么1个小时的订单量为3w,预估峰值为3倍，
得出1个小时需要性能要求10w单，假设余额不足有多次查询则查询为每个小时20w单，有三分之一的人需要充值，则充值量为3w每小时，总共13w单每小时，性能要求如下：

1.查询性能目标：平均响应时间 < 100 ms,95%的时间小于300ms,单机TPS > 60
2.下单性能目标: 平均响应时间 < 300 ms,95%的时间小于600ms,单机TPS > 30
3.充值性能目标：充值过程人工参与，此处邀请充值订单接口,在忽略人工时间，平均响应<300ms，95%的时间小于500ms
4.高可用要求：在就餐时间系统要求高可用，可用性 >99.99%;
5.系统安全性目标：存储卡号以及余额信息，为避免被人盗用，对卡号对称加密，使用https传输
6.设计到财务数据，因此要求数据持久化，并且1天1备

系统预计使用3台物理机，2台用于部署管理中心、交易子系统、nginx，1台用于数据库,外部接口与支付宝、微信对接，支持微信、支付缴费充值

1.管理中心与交易子系统部署其中一台机器，管理中心用于管理商户、卡的挂失、停用，商户的开通，定时同步我方超时
的充值订单的状态，
2.交易子系统与nginx部署在另外一台机器，nginx用作负载均衡器采用轮询的模式转发请求
2.交易子系统系统负责餐卡消费、餐卡充值、余额查询
3.商家客户端实现NFC读卡，通过https接口查询余额，创建消费订单,进行消费
4.充值考核端实现NFC读卡，通过https接口查询余额，创建充值订单,进行充值


1.发卡前先重新按规则生成卡号，然后写入卡号到磁卡中
2.选择充值的收款方式（微信、支付宝、现金），输入充值金额
3.点击充值按钮，调用充值接口
4.交易子系统生成订单，根据支付方式进行处理
5.如果是现金支付，直接更新餐卡账户，返回结果给客户端
6.如果是第三方支付，需要请求第三方支付接口，此时等待订单超时，或者第三方通知支付结果
7.根据第三方支付结果更新餐卡账户，然后返回
8.订单要求在5分钟内完成，5分钟后直接返回超时结果，需要重新下单
9.充值成功后流程结束
10.如果出现第三方支付成功，但是系统认定订单失败的情况下，可以刷新支付结果
11.通过订单号请求交易子系统，子系统调用第三方支付查询订单结果
12.如果支付状态发生变化则更新餐卡账号余额
13.如果还有问题，需要客户联系第三方支付确认


1.可读读取卡号，并发起请求查询卡账号余额
2.交易系统返回卡账户余额
3.客户人员操作输入要退款的金额，发起退款请求
4.交易子系统查询余额是否充足，扣除卡账户退款金额，返回扣款结果
5.客户人员在收到扣款成功的反馈后，支付现金给退款人



1.退款开始，充值子系统读取卡号
2.调用交易子系统接口查询余额
3.充值客户端展示余额
4.输入退款金额，发起退款请求到交易子系统
5.交易子系统判定余额是否充足，如果不足直接范围
6.如果余额充足，扣除账号响应的金额，返回成功结果
7.客户人员线下支付现金，交易完成


1.安全组件负责交易子系统安全工作，避免系统被他人恶意攻击，导致财务数据混乱造成损失，客户端与交易系统的交互
都需要安全组件进行签名验证，方可放行
2.订单组件，负责创建交易系统内的所有订单，已经订单状态变更引起的其他相关操作，订单组件依赖安全组件、数据库组件、账户组件、支付组件，它是整个系统运作的桥梁
3.支付组件负责与第三方支付进行交互的工作
4.账户组件，负责维护卡账号的收入和支出工作，已经记录账户变动的流水，他依赖数据库组件的持久化已经事务
5.持久化组件，负责数据可数据变更的持久化和事务控制
6.日志组件，负责记录交易系统关键操作的日志记录，用于在故障时，可以快速定位问题和恢复丢失的数据



1.消费者使用餐卡在商户客户端消费，商户输入金额
2.客户端生成订单号，并发起消费请求到消费子系统（安全组件）
3.消费子系统进行签名验证，请求是否合法
4.日志组件记录订单请求日志
5.订单请求转发到订单组件，订单组件生成平台订单号，并调用账号组件扣款，然后再调用持久化组件
插入订单并更新账户余额（同一事务）
6.返回订单支付的结果到订单组件
7.日志组件记录订单结果
8.将支付结果返回到商家客户端，完成交易



1.消费者在客户端发起消费请求
2.安全组件先校验合法性
3.日志组件记录订单日志
4.订单组件负责创建订单
5.账户组件负责扣款，并根据扣款结果更新订单状态（成功、失败）
6.日志组件记录订单返回后的日志
7.商家获取结果，交易结束



账户组件主要保证卡账户的正确性，以及在异常时，可以根据账户流水对账，找出账户异常的原因。 其中包含了BseModel,CardAccountModel,CardAccountFlowModel,CardAccountService,CardAccountServiceImpl
,BaseMapper、 CardAccountMapper、CardAccountFlowMapper类


    1.卡账户实体和账户流水实体继承BseModel，BseModel包含了实体中的功能属性
    2.卡账号、卡账户流水持久映射接口继承公共的数据库映射接口
    3.卡账号服务类继承卡服务接口，实现卡账户的查询、账户修改等业务操作
    


    
    1.更账号是先调用CardAccountServiceImpl的updateAccount方法
    2.CardAccountServiceImpl方法创建CardAccountFlowModel、CardAccountModel对象，并填充数据
    3.调用CardAccountFlowMapper更新账户流水
    4.调用CardAccountMapper更新账户余额
    
    


1.订单新建后，如果是现金支付，状态直接变更成支付成功
2.如果是第三方支付，则状态变更成待支付
3.如果等待5分钟后，仍然没有收到回调状态，则订单状态变更成支付超时
4.如果5分钟内收到回调，则变更状态为充值成功
5.刷新订单状态，如果结果是成功，则变更订单状态为充值成功