2. 系统架构总览：基于微服务的发票与合同付款系统架构图
在深入排查发票匹配异常与合同付款卡顿之前，首先需要建立对目标系统整体架构的清晰认知。本课程所涉及的发票与合同付款系统采用微服务架构，通过服务拆分、API 网关统一接入以及分层数据库设计，支撑高并发、高可用的企业级财务结算场景。下图展示了系统的核心分层与关键组件。
架构设计目标： 实现发票与合同付款流程的端到端可追溯、异常可定位、性能可观测。微服务拆分以“业务边界”为原则，每个服务拥有独立的数据库实例，避免跨服务直接访问数据。
2.1 系统分层架构总览
系统从接入层到数据层共分为四个主要层次，每一层承担明确的职责，并通过定义良好的接口进行通信。
| 层次 | 核心组件 | 主要职责 |
|---|---|---|
| 接入层 | API 网关 (Kong / Spring Cloud Gateway) | 统一入口、路由转发、身份认证、限流熔断、请求日志 |
| 业务服务层 | 合同服务、发票服务、付款服务、对账服务、通知服务 | 核心业务逻辑处理、状态机管理、事件发布 |
| 中间件层 | 消息队列 (RabbitMQ / Kafka)、缓存 (Redis)、任务调度 (XXL-Job) | 异步解耦、数据缓存、定时任务与重试机制 |
| 数据层 | MySQL (主从)、Elasticsearch、对象存储 (MinIO) | 结构化数据持久化、全文检索、发票影像与合同附件存储 |
架构要点： API 网关是流量的“守门员”，所有客户端请求（Web、移动端、外部系统）必须经过网关。网关层集中处理鉴权和限流，有效保护下游业务服务不被异常流量冲垮。
2.2 核心业务服务与数据流
业务服务层是架构的核心，各服务围绕“合同-发票-付款”这条主线协同工作。以下表格梳理了关键服务及其数据流向。
| 服务名称 | 核心数据表 | 关键数据流 |
|---|---|---|
| 合同服务 | contract, contract_item, contract_payment_plan | 创建合同 → 生成付款计划 → 推送待付款事件 |
| 发票服务 | invoice, invoice_item, invoice_verify_log | 发票录入 → OCR 识别 → 税务校验 → 匹配合同 |
| 付款服务 | payment_request, payment_record, payment_audit_log | 接收付款指令 → 预算检查 → 审批流 → 银行接口调用 |
| 对账服务 | reconciliation_result, mismatch_record | 拉取银行流水 → 逐笔匹配 → 生成差异报告 |
数据流典型路径：合同创建 → 发票录入并匹配合同 → 触发付款申请 → 审批通过 → 执行付款 → 银行回单对账。任何一个环节出现数据不一致或服务响应超时，都会导致“发票匹配异常”或“合同付款卡顿”。
2.3 架构图：微服务组件与交互关系
以下 SVG 图展示了系统的完整组件拓扑，包括 API 网关、业务服务集群、中间件以及数据库层的连接关系。图中使用不同颜色区分服务类型，箭头表示请求或数据流向。
架构解读： 注意图中虚线箭头表示异步消息或事件驱动（如发票匹配完成后通过 MQ 通知付款服务），实线箭头表示同步 RPC 调用（如 API 网关转发请求）。这种混合通信模式在提升系统响应速度的同时，也引入了消息丢失、重复消费等排查难点，是后续课程的重点。
2.4 发票匹配与付款卡顿的关键链路
在微服务架构下，一次完整的“发票匹配 → 合同付款”流程会跨越多个服务。以下流程图聚焦于该核心链路，标识出最容易出现异常和卡顿的环节。
排查重点： 在实际故障排查中，超过 70% 的“合同付款卡顿”问题集中在节点④（匹配合同）和节点⑥（审批流）。前者通常由数据不一致或缓存失效引起，后者则多与工作流引擎的异步回调超时有关。后续章节将针对这些环节进行详细的日志分析和代码级排查。
2.5 架构设计对异常排查的支撑
良好的架构设计不仅保障系统运行，更为异常排查提供了基础设施。以下是架构层面对排查能力的支撑要点：
- 全链路追踪： 通过集成 SkyWalking 或 Zipkin，为每个请求生成唯一 Trace ID，串联 API 网关、业务服务、数据库调用日志，快速定位卡顿发生在哪个服务。
- 服务熔断与降级： 当银行接口或税务校验服务响应缓慢时，Sentinel 或 Hystrix 触发熔断，避免故障扩散。熔断日志是排查卡顿根因的重要线索。
- 事件溯源： 发票匹配、付款申请等关键操作均通过 MQ 发布事件，事件日志记录了完整的业务状态变更历史，可用于回放异常场景。
- 数据库读写分离： 主库负责写入，从库负责查询。排查时可通过从库慢查询日志定位索引缺失或 SQL 性能问题，而不影响主库业务。