Day09-04｜3.2.4 业务处理系统的组成：从输入终端到控制与运维闭环

教材定位：系统架构设计师教程（第 2 版）第 3 章“信息系统基础知识”第 3.2.4 节。

学习目标：掌握业务处理系统（TPS）的基本组成；理解输入设备与采集、业务处理程序、数据库、输出与通信、控制审计以及系统运维等组成部分的职责；能够将组成映射到架构视图、接口边界、质量属性和案例解决方案。

一、组成结构决定业务处理能力

TPS 是一个完整的信息处理系统，不是某个页面、服务或数据库。它通常由输入部分、处理部分、数据存储部分、输出部分、通信部分、控制与安全部分以及运行维护部分构成。不同系统的物理部署可能不同，但这些职责都必须被覆盖。

架构设计应明确每个组成的边界和责任。输入层不应承担核心业务判断，数据库不应被所有模块随意直接访问，输出层不应绕过权限，通信层不应隐藏重复和错误语义，运维能力不应在上线后临时补建。

二、输入与数据采集部分

输入来源包括人工终端、移动端、条码和 RFID 设备、传感器、文件、外部 API、消息和批量作业。输入部分负责接入、初步校验、身份识别、格式转换和业务号生成。

输入接入要考虑重复、乱序、延迟、离线、恶意数据和版本差异。移动端可能重复点击，设备可能重复上报，外部系统可能重试回调，文件可能重复导入。系统应为关键事件生成唯一标识，并在服务端保留接收记录，不能只依赖客户端避免重复。

输入校验包括格式、范围、引用、权限、状态和业务规则。前端校验改善体验，服务端校验保证安全和正确。批量输入还要提供批次号、行号、失败原因、成功失败统计和可重试范围。对设备输入，必须校验设备身份、时间戳、签名和数据质量。

输入层可以通过网关、适配器和消息接入隔离不同渠道。这样业务处理层面对统一领域事件，不必在核心逻辑中散落网页、设备和供应商协议细节。

三、业务处理部分

处理部分是 TPS 的核心，负责执行业务规则、维护状态、计算结果和产生副作用。可以包含业务服务、工作流、规则引擎、事务协调器和任务调度器。

处理逻辑应区分领域规则、流程协调和技术能力。库存不能为负、票据不能重复入账等属于领域不变量；调用支付、通知和消息属于流程协调；连接池、重试、序列化和日志属于技术能力。职责混杂会使规则难以测试和复用。

事务处理要明确事务边界、并发控制、幂等和一致性。单数据库内可以利用本地事务；跨服务场景需要可靠消息、状态机、补偿、对账或人工处理。每个关键操作都应定义成功、失败、处理中、超时和未知结果，不能只设计成功返回。

处理部分还要控制资源和故障。线程池、连接池、队列和锁要有上限和监控；外部调用要有超时、退避、熔断和重试；非核心工作可以异步削峰；核心业务需要优先级和隔离，避免报表或通知拖垮交易。

四、数据存储部分

TPS 的存储部分保存业务事实、状态、审计、配置、任务和恢复信息。数据库可以是关系数据库、键值存储、文档数据库、时序数据库或文件/对象存储，选择应依据数据模型、事务、一致性、访问模式、容量和运维能力。

关系数据库适合强结构、事务和关联约束；键值或文档存储适合特定访问模式和灵活结构；对象存储适合大文件；消息日志适合事件保留和异步处理。多种存储组合时要明确权威来源、同步方向、延迟和故障补偿，不能让同一事实在多个系统中无主。

数据设计要考虑主键、唯一性、索引、约束、版本、归档、备份和删除。索引提高查询但增加写入成本；读写分离可能有复制延迟；分片提高容量但增加跨分片处理；缓存提升速度但引入失效和一致性问题。架构师要把数据质量和生命周期纳入组成设计。

恢复信息也属于存储设计。事务日志、检查点、幂等记录、消息状态、批次结果和对账记录，决定系统能否在故障后继续。只保存最终表数据而没有过程记录，往往难以解释和修复异常。

五、输出与呈现部分

输出包括页面、接口、业务单据、打印、文件、消息、邮件、短信、报表和设备控制。输出要明确数据来源、实时性、权限、格式、版本、错误和完成语义。

在线输出通常分为同步结果和异步结果。同步结果可以返回成功、失败或处理中；异步结果通过查询、回调或消息通知。用户需要知道受理号、当前状态、下一步操作和失败原因，不能只得到一个模糊提示。

输出层要防止越权和数据泄露。字段脱敏、行级权限、租户隔离和下载审计应在服务端执行；前端隐藏字段不能替代授权。报表和导出还要限制范围、频率和文件有效期，防止大量敏感数据被一次性带走。

六、通信与系统集成部分

TPS 通过通信与其他系统、设备和组织协作。通信方式包括同步 API、异步消息、文件交换、数据库复制、批量作业和专用设备协议。选择方式要结合实时性、可靠性、解耦、一致性、数据量和对方能力。

同步调用适合需要即时结果的校验和查询，但会叠加延迟并传播故障；异步消息适合后置动作和削峰，但需要处理重复、顺序、积压和最终一致；文件适合批量交换，但需要批次、校验、加密和重传；设备协议需要适配、心跳、时钟和离线处理。

接口契约应包括字段语义、版本、方向、超时、错误码、重试、幂等、鉴权和审计。跨系统集成要定义谁拥有数据、谁负责重试、谁确认完成以及如何对账。若接口只写“返回成功/失败”，无法支撑复杂业务。

七、控制、安全和审计部分

控制部分保证事务按照授权、规则和流程运行。它包括身份认证、访问控制、职责分离、审批、输入控制、批次控制、异常控制、审计和监控。

身份认证确认主体，授权确认主体可执行的操作，职责分离避免高风险操作由一人独立完成，审计记录责任和结果。控制要贯穿输入、处理、数据和输出，不能只在登录页面实现。

审计日志应记录业务号、主体、角色、来源、时间、对象、动作、前后状态、结果和规则/版本。重要日志要防篡改、限制访问并按合规要求保存。监控要覆盖业务成功率、错误、响应、队列、资源、数据质量和安全事件，形成告警、处置和复盘闭环。

八、运维、备份与恢复部分

TPS 需要可部署、可监控、可备份、可扩容和可恢复。运维组成包括配置管理、制品管理、发布、日志、指标、追踪、告警、备份、容灾、容量、服务台和应急。

发布要有检查、灰度、观察和回滚，数据库和配置变更要兼容；备份要验证可恢复而不是只看任务成功；容灾要演练切换、数据校验和业务恢复；容量管理要根据实际峰值、增长和故障余量调整资源。

运维文档应包括架构、依赖、启动停止、故障处理、数据恢复、对账、联系人和升级路径。知识不能只掌握在某个开发者手里，关键操作应可重复并经过演练。

九、案例：快递寄件系统

某快递企业建设寄件系统，包含网点录入、扫码称重、价格计算、面单打印、支付、运输接口和客服查询。系统出现重复面单、价格不一致、支付状态未知和客户无法追踪。

输入部分要为寄件单和扫码事件生成唯一号，校验网点、重量、地址和设备；处理部分把计价规则版本化，建立寄件状态机，并定义支付和运输的处理中状态；存储部分保存原始重量、计价明细、规则版本、支付流水和状态历史；输出部分提供面单、收据和轨迹查询，按角色脱敏；通信部分通过适配器连接支付、运输和打印设备，定义超时、重试和幂等；控制部分记录操作员、设备、网点和审计；运维部分提供监控、对账、补偿和回滚。

验收应覆盖重复扫码、设备离线、重量修改、规则升级、支付超时、运输回调重复、打印失败和节点故障。这样才能检验组成部分是否形成完整业务闭环。

十、练习与详细答案

1. TPS 通常由哪些组成部分构成？
2. 为什么输入层和处理层要分离？
3. 数据库存储为什么不能被所有模块直接访问？
4. 通信方式选择要考虑哪些因素？
5. 控制与运维部分为什么也是系统组成？

答案：1. 输入采集、业务处理、数据存储、输出呈现、通信集成、控制安全和运维恢复；2. 不同渠道协议和校验细节会变化，分离后核心业务面对统一事件，便于替换和测试；3. 直接访问造成结构强耦合、权限绕过和变更扩散，应由数据所有者通过接口和规则管理；4. 实时性、可靠性、解耦、一致性、数据量、对方能力、版本和运维成本；5. 没有权限、审计、监控、备份和恢复，业务即使能运行也不可控、不可追责和难以长期服务。

案例题：某订单系统功能齐全，但外部物流接口短暂不可用时订单状态被错误改为失败，恢复后无法补发。请从组成角度分析。

参考答案：处理层没有区分外部依赖失败与业务失败，通信层没有超时、重试、幂等和处理中语义，数据存储没有保存状态历史和重试任务，控制运维层没有告警、补偿和对账。应建立订单状态机，外部物流不可用时保留已创建状态并记录待同步任务；通信适配器统一处理超时、退避、重复回调和版本；任务以订单号幂等，失败进入可重试队列和死信；保存状态变更、请求和响应摘要；通过监控、告警、人工补偿和定期对账恢复；测试依赖超时、重复回调、节点故障和恢复后补发。

十一、论文素材与复盘

论文中可以按 TPS 组成展开架构：输入层统一接入并校验，处理层负责领域规则和状态机，数据层保存权威事实与恢复信息，输出层提供同步/异步结果，通信层隔离外部差异，控制层保证权限审计，运维层提供发布、监控、备份和容灾。每一层都要写接口、质量属性和验证场景。

今日核心记忆句：TPS 是输入、处理、存储、输出、通信、控制和运维组成的整体；各部分必须有清晰职责和契约；架构完整性不仅体现在业务流程，也体现在异常、审计、恢复和长期运维。案例题遇到“功能有但系统不可靠”，优先从缺失的组成职责和接口语义入手。