Day32-20｜13.7.2 基于物联网架构的电子小票服务：从终端采集到可信交付

一、教材定位与学习目标

13.7.2 是第 13 章层次式架构案例的第二个综合实践。与网上商店案例相比，电子小票服务增加了明显的物联网特征：数据产生在收银机、打印机、扫码设备或移动终端，网络连接质量不稳定，设备型号和协议不统一，服务既要实时接收交易，又要保证票据不丢失、不可随意篡改、可追溯和可重复查询。

本节要训练的不是某个具体厂商的接口，而是从“设备—接入—平台—业务—用户”全链路进行架构设计。考试中，题目往往会给出门店数量多、设备异构、网络波动大、峰值交易集中、需要离线运行或监管审计等条件，要求考生说明系统架构、数据流程、可靠性和安全措施。本案例可以作为回答这类题目的通用骨架。

学习完成后，应能够：

1. 解释电子小票系统与普通 Web 系统在架构约束上的差异。
2. 设计设备接入层、边缘网关、消息通道和业务平台的分层结构。
3. 说明小票生成、加密签名、发送、重试、查询和作废的完整流程。
4. 处理离线门店、重复上报、设备故障、消息积压和数据补偿问题。
5. 从可用性、可靠性、安全性、可追溯性和可维护性角度组织案例答案。

二、业务场景与核心矛盾

电子小票服务通常由收银系统产生交易数据，平台根据交易信息生成电子票据，并通过短信、邮件、应用内消息、二维码或会员账户交付给消费者。消费者可以在移动端查看、下载、转发或用于售后；商户可以按门店、时间、收银员和订单号查询；管理部门可能需要按规定留存和审计。

系统参与者包括消费者、收银员、门店管理者、总部运营人员、收银终端、打印设备、边缘网关、电子票据平台、消息服务和外部监管或存储服务。不同参与者关注的质量属性并不相同：消费者关注交付速度和可访问性，商户关注业务连续性，监管关注真实性与完整性，运维人员关注设备状态和问题定位。

这里有一个重要判断：电子小票服务不是“把收银数据保存到云端”这么简单。它是一个带有设备管理、事件接入、票据生成、可信存证和多渠道交付的分布式系统。只有把这些变化点和故障点显式写出来，答案才符合高级系统架构设计师的要求。

三、总体层次架构

可以采用“设备层、边缘接入层、网络传输层、平台服务层、业务应用层、交付与审计层”的逻辑结构。安全和运维能力横向贯穿所有层次。

逻辑调用关系可以表示为：

收银终端 → 门店网关 → 安全接入 → 消息队列 → 票据业务服务
                                     ↓              ↓
                              设备管理服务       数据库/对象存储
                                                    ↓
                              通知服务 → 短信、邮件、App、二维码

层次式架构并不要求所有组件都部署在同一台服务器上。门店网关可部署在本地，平台服务可部署在云端，数据和通知服务还可能由不同供应商提供。逻辑分层帮助我们明确职责，物理部署则根据网络、成本、可靠性和安全要求决定。

四、设备模型与接入设计

4.1 统一设备模型

平台应为设备建立统一的身份、能力和状态模型。设备身份至少包括设备编号、门店编号、设备类型、型号、固件版本、注册时间和证书或密钥引用；设备能力可以描述是否支持交易上报、打印、扫码、远程升级和状态上报；设备状态包括在线、离线、故障、维护和禁用。

统一模型的价值是把“设备是什么”和“设备采用什么协议”分开。业务服务只面向统一的交易事件和设备能力，不需要知道某型号收银机使用的是某种私有协议。新增设备时，只需增加或调整适配器，减少对核心业务的影响。

4.2 协议适配器

设备接入可能使用 HTTP、长连接、消息协议、串口或厂商 SDK。适配器负责连接建立、报文解析、字段映射、签名校验、错误码转换和版本兼容。适配器输出的应是平台标准事件，例如交易完成事件、设备状态事件和打印结果事件。

适配器不应该自行决定订单是否有效，也不应该直接修改票据状态。业务规则应由平台服务统一处理，否则同一业务会因设备来源不同而得到不同结果。

4.3 设备生命周期

设备从采购、注册、激活、在线运行、升级、维修到注销，应该有清晰的生命周期。注册时需要校验设备归属，激活时下发最小权限凭证，运行期间定期上报心跳和固件版本，注销后立即撤销访问能力。设备证书、密钥和升级包属于高敏感资源，应有轮换和审计机制。

五、边缘网关：物联网架构的关键缓冲层

边缘网关位于门店现场，是系统适应不稳定网络和异构设备的关键。它至少承担四类工作：协议转换、数据暂存、连接管理和本地策略执行。

5.1 离线缓存与恢复

当门店无法访问云端时，网关应将交易事件和必要的小票数据持久化到本地队列，而不是只放在内存中。每条记录应包含事件编号、设备编号、产生时间、数据摘要、重试次数和当前状态。网络恢复后按照顺序或优先级上传，并在平台确认后标记已提交。

离线能力必须明确边界。例如，平台可以允许门店先完成本地交易和打印，但某些需要在线核验的优惠或支付确认仍不能离线完成。架构答案要写清“哪些能力可降级、哪些能力必须阻断”，否则“支持离线”会变成无条件承诺。

5.2 重复上传与顺序问题

网关在没有收到平台确认时可能重试，平台因此可能接收到同一事件多次。事件编号应由设备或网关生成，并在平台建立唯一约束；处理逻辑需要区分“首次创建”“重复到达但已成功”和“重复到达但前次处理中”等状态。

如果同一设备的事件有顺序要求，应使用设备序列号或单调递增版本进行检查。对于不要求严格顺序的事件，可以采用分区消息和并行消费提高吞吐。不要为了所有事件都使用全局顺序，这会牺牲扩展性。

5.3 边缘安全

网关应使用设备身份认证和加密通道访问平台；本地缓存需要加密或采取访问控制，避免门店设备被拆走后泄露交易信息；远程运维应记录操作者、命令、时间和结果。涉及远程打印、删除或升级的命令，必须进行授权、签名和防重放校验。

六、电子小票业务流程设计

6.1 小票生成流程

交易完成后，收银终端产生标准交易事件。平台接收事件后，先验证来源身份、事件签名、字段完整性和业务幂等键；随后根据门店、票据类型和版本选择模板，生成结构化票据数据和可展示的内容；系统将票据元数据、内容摘要和存储地址写入票据库，再发布交付事件。

生成小票时要区分原始交易数据与展示模板。模板可以变化，但历史票据的核心交易内容应可复原，必要时还应保存当时使用的模板版本。票据金额、税额、商品明细和交易时间应由可信业务数据生成，不能由客户端自行拼接。

6.2 可信性与防篡改

可以对票据规范化内容计算摘要，并使用平台私钥签名。消费者查询或监管导出时，验证方根据内容重新计算摘要，再用公钥验证签名。签名不能替代访问控制，也不能解决所有数据泄露问题，但可以为“内容是否被修改、由谁生成”提供证据。

审计记录应包含票据创建、修改、作废、重发、下载和授权查询等事件。对于允许更正的场景，不应直接覆盖原记录，而应生成更正事件并保留原始版本，从而形成可追踪的历史链。

6.3 多渠道交付

交付服务可以向消费者发送短信链接、邮件附件、App 消息或二维码。票据核心状态与通知状态要分开：小票已经生成，不代表短信已经送达；短信失败也不应回滚已落库的票据。通知任务应包含业务幂等键、渠道、模板版本、重试次数和最后错误。

重试需要区分临时失败和永久失败。网络超时、供应商繁忙适合延迟重试；手机号格式错误、用户拒收等问题应转入人工或替代渠道。为了避免通知风暴，应设置退避策略、最大次数和死信队列。

七、数据设计与一致性策略

电子小票系统可以将数据分为交易主数据、票据数据、交付数据、设备数据和审计数据。交易主数据强调准确性；票据内容强调长期保存和不可篡改；交付数据强调状态可重试；设备数据强调时序和实时性；审计数据强调完整性和查询能力。不同数据不一定使用同一种数据库。

票据创建和消息发送通常不应绑定在一个远程分布式事务中。较稳妥的方式是：先在本地事务中保存票据和待发布事件，之后由可靠消息机制投递通知；消费者处理成功后写入交付结果。若消息发送失败，可依靠重试和补偿恢复。对于高可靠要求，可以采用事务消息、发件箱模式或定时扫描未发送事件。

八、质量属性分析

8.1 可靠性与可用性

可靠性强调数据和业务结果不丢失、不重复、可恢复；可用性强调服务在故障时仍能提供约定的功能。门店网关的离线缓存、平台的消息持久化、数据库备份、对象存储多副本和通知补偿共同构成可靠性方案。不能只写“集群部署”，还要说明故障发生时数据如何继续流转以及恢复后如何补偿。

8.2 性能与容量

交易高峰可能集中在打烊前、节假日或促销时段。接入层应无状态化并水平扩展，消息队列用于削峰，票据生成和通知可以异步化，查询服务与写入服务可以分离。容量估算应考虑设备数量、每台设备每分钟交易数、票据平均大小、保留年限和通知峰值。

8.3 安全性

需要覆盖设备身份、传输安全、密钥管理、数据访问、票据签名、管理后台权限和审计。消费者只能查询本人或持有合法访问凭证的票据；商户用户按门店和角色隔离；平台运维不能默认读取全部票据内容。敏感字段应脱敏显示，并根据留存要求设置访问和删除策略。

8.4 可维护性与可演化性

统一设备模型、协议适配器、版本化模板和标准事件让系统能够接入新设备和新渠道。接口应明确版本兼容策略，消息事件应保留向后兼容字段。对于设备固件和网关软件升级，要支持灰度、回滚和升级结果上报，避免一次性升级导致全量门店瘫痪。

九、案例题答题模板

面对“为连锁门店设计电子小票服务”类题目，可以按以下结构作答：

1. 背景与目标：说明设备异构、网络不稳定、峰值交易、可信存证和多渠道交付需求。
2. 总体架构：画出设备、边缘、接入、消息、平台、数据、应用和交付层，并标明安全与运维横向能力。
3. 数据流程：描述交易上报、身份校验、幂等处理、票据生成、签名存储和通知发布。
4. 异常处理：说明离线缓存、重连补传、重复事件、消息重试、死信、人工补偿和对账。
5. 质量属性：分别回答可靠性、可用性、性能、安全性和可维护性的设计措施。
6. 权衡说明：解释实时性与一致性、离线能力与在线校验、中心化管理与门店自治之间的取舍。

十、课后练习

练习一：选择题

门店网关向云端重复上报同一笔交易，最合理的处理方式是（ ）。

A. 每次上报都生成一张新小票

B. 只依赖网络层 TCP 保证不重复

C. 使用业务事件编号建立幂等处理和唯一约束

D. 关闭所有重试，避免重复

答案：C。 网络重试和确认丢失是分布式系统的常见现象，必须在业务层设计幂等。关闭重试会增加数据丢失风险，TCP 也不能保证业务消息只被处理一次。

练习二：简答题

为什么电子小票生成成功后，短信发送失败不能回滚票据创建？

参考答案： 票据生成和短信发送通常属于不同服务、不同资源和不同故障域，无法依赖一个本地事务完成原子回滚。若短信供应商暂时不可用，回滚票据会造成交易结果丢失。应将票据状态和通知状态分离，先可靠保存票据及待发送事件，再通过消息、重试、替代渠道和人工补偿完成最终一致性。

练习三：案例题

某连锁商超共有 5000 家门店，部分门店每天有 2 小时网络不稳定。要求交易不能因电子小票服务不可用而停止，且消费者最终能够查询票据。请给出架构方案。

参考答案： 门店部署边缘网关，收银终端通过统一适配器向网关提交标准交易事件；网关将事件和必要票据数据持久化到本地加密队列，并记录事件编号、顺序和重试状态。网络恢复后按策略补传，云端用事件编号和交易单号实现幂等。平台接入层无状态集群化，消息队列持久化削峰，票据服务在本地事务中保存票据元数据和待发布事件，再异步生成交付任务。票据内容保存到对象存储并计算摘要，平台对关键字段签名；消费者通过授权链接或账户查询。对重复事件、消息超时和供应商失败使用退避重试与死信队列，定时任务扫描未完成记录，必要时人工补偿。门店离线时允许本地完成交易和打印，但对必须在线确认的支付或优惠能力设置明确限制；云端恢复后通过对账确保本地和中心数据一致。安全上使用设备证书、加密缓存、最小权限和审计日志。

十一、论文素材与综合知识迁移

本案例适合用于“论物联网场景下的分层架构设计”“论分布式系统中的可靠消息与最终一致性”“论边缘计算在零售系统中的应用”等论文。摘要可概括门店规模、网络问题和电子票据目标；正文可以依次写边缘接入设计、统一设备模型、消息与离线缓存、票据签名及多渠道交付；结尾写上线后的补传成功率、通知时延、故障恢复时间和运营收益。

论文中要注意把技术与业务结果对应起来。例如，“采用边缘持久化队列”解决的是网络中断时交易事件不丢失；“采用业务幂等键”解决的是重试导致重复票据；“采用签名与审计链”解决的是票据可信和责任追踪；“采用适配器和统一设备模型”解决的是设备扩展成本。每一项方案都要回答问题、措施、质量属性和验证结果四个要素。

十二、今日复盘清单

• 我能否画出电子小票的设备—边缘—平台—应用全链路？
• 我能否说明边缘网关为什么不仅是协议转换器？
• 我能否区分票据生成状态与通知交付状态？
• 我能否解释离线缓存、幂等、重试、死信和补偿之间的关系？
• 我能否针对安全、可靠性和可维护性分别给出可验证的设计措施？

本节的核心结论是：物联网层次架构的重点在于把设备不确定性和网络不稳定性隔离在接入与边缘层，把交易、票据和交付规则集中在平台业务层，再通过消息、存储、签名、审计和补偿机制构建可信且可恢复的业务闭环。