打印代理初步方案.docxVIP

打印代理初步方案一、目的 目前，大部分商家采用收银静默模式，只用到收银估清、报表功能，其他功能并没有用到（如点菜、结算等）功能。造成部署上麻烦、参数配置多、升级投入大、桌台、菜品数据维护不便。 改造后去掉收银的功能（如客户端、配置、桌台、菜品维护等）从而简化，可大大提高运营安装效率及标准化，因此衍生出打印代理组件，主要负责接收打印数据并传递到相对应的打印机。二、改造后的优点及缺点优点：安装快速、长期免升级、远程支持简单缺点： 1、暂时失去线下点菜、结算（扫码枪）、扫码后买单等功能 2、本地收银无法统计3、打印机调测依赖云端提前配置4、打印机设置及各打印机关联菜品设置都移到云端，增加云端下发打印订单数据处理逻辑，导致云平台失去少逻辑原则，随着商家数量大量增加会造成这块成为性能瓶颈。5、打印机驱动会增大云端的消息量三、设计图1、订单消息处理时序图2、云平台监控和管理打印代理三、改造的关键点原收银的桌台、菜品设置功能移到商家PC里操作，商家PC需增加桌台设置、菜品属性改成收银方式增加修改原收银的打印机设置（小票打印机设置、厨房打印机设置）功能移到商家PC维护。云端下发订单时只下发各打印机的图片，需增加处理逻辑分解各菜品对应的打印机，通过打印配置生成打印图片云端需重发订单处理机制（有代理心跳时，间隔2分钟重发，无心跳时等到有心跳时启动重发）打印代理需去重处理机制，需将打印过的订单ID存起来，每次接收到订单消息处理前需进行判断是否已处理过打印代理能回传订单打印的状态云平台能管理打印代理的“订单处理进程”，通过打印代理的“心跳进程”业管理“订单处理进程”的启动、停止、重启，可解决 “订单处理进程”出现局部故障时导致进程死掉或功能失效，可以通过云平台进行监控并重启。四、关键非功能特性设计回顾近期现网出现的故障，mysql bug、漏单、商家网络问题、一条套餐消息导致“订单处理进程”终止、商家环境的物理干扰（线路板老化、老鼠咬断线），需提供紧急应对措施来保证系统稳定性。1、可靠性由于在店内扫码点菜下单到店内打印整个业务流程对系统的可靠性要求很高，要保证系统的稳定性，同时也要提供紧急应对措施来保证系统最大间断时间不超过5分钟。?告警：当打印代理出现异常情况时，应该发送告警信息。云平台监控订单状态超过1分钟未更新发出告警。店内监控及告警功能：将长期没网络情况告警通知到商家负责人。及出现异常情况应发送告警信息实时监控：监控打印代理（订单处理进程）的运行状态，采用目前已经实现的心跳方法来实现。紧急应对措施：当“业务线程”处理特定条件下数据发生致命错误，导致进程功能失效，这时就需要“心跳线程”自检及诊断“业务线程”的故障，并要求实现自行修复。“心跳线程”可管理“业务线程”进行重启、停止、检测。订单消息重发：为避免因网络原因导致数据丢失，采用该方式来保证。若等待响应超时或返回了错误信息，则重新发订单数据，重发间隔时间2分钟（可配置），重发N(可配置)次后，发出告警信息。订单去重处理：为避免订单重打印，采用去重处理机制来保证。所以需将打印过的订单号存起来，每次接收到订单消息处理前需进行判断是否已处理过。2、容错性?打印代理应具有一定的容错功能。如，在读写文件发生异常的情况下，或接收到非法数据时，不能引起“订单处理进程”死掉或功能不可用，会发出告警信息。至少要保证主进程“心跳进程”可用。?3、可维护性?完善的日志记录功能?? 对于消息接收，发送，要记录处理时间，以及结果。如果失败或者出现异常，则应该给出失败的原因和异常信息。??云平台能控制打印代理的“订单处理进程”重启、启动、停止、监控。4、性能??5、可扩展性打印代理采用组件化设计原则6、可快速部署性打印代理安装要求，实现“一键安装”，并向导输入相关配置（商家ID、商家key），尽可能不需要修改配置文件、配置项等操作。也尽可能不用升级。