采购系统如何对接其他系统？API、主数据与同步机制设计

集成困境：采购系统不是孤岛

采购系统的价值取决于它与其他系统的连接深度。一个孤立的采购系统只能做单据录入，但企业需要的是：采购订单自动同步到财务系统生成应付账款、收货数据实时更新库存台账、供应商信息从主数据平台统一分发。这些场景背后是同一个问题——采购系统如何对接其他系统？

集成失败的常见表现：数据对不上（财务说已付款，采购说订单未关闭）、流程断点（采购单审批后无法推送到供应商门户）、接口报错无人处理（重试耗尽后数据丢失）。这些问题往往不是单一系统的问题，而是集成设计时对主数据归属、接口协议、幂等与重试机制缺乏系统性考量。

本文从架构视角覆盖以下核心维度：主数据到底谁管、接口选 REST 还是消息队列、如何保证数据不丢不重、重试策略怎么设计才不崩溃、监控告警应该看什么。不涉及具体产品对比，只讲工程上经过验证的做法。

主数据归属：谁才是数据的主人？

主数据（Master Data）是企业核心业务实体的权威数据源。在采购集成中，最常见的三个主数据实体是：供应商、物料（商品）、采购组织。每个实体的归属策略直接影响接口设计。

供应商主数据

供应商信息通常由供应商管理系统（SRM）或主数据管理平台（MDM）统一维护。采购系统不应直接创建或修改供应商名称、银行账户、税务信息。采购系统只应引用供应商 ID，并在本地缓存名称、地址等展示字段。

如果企业没有 SRM 或 MDM，采购系统就需要承担供应商主数据的维护职责。此时采购系统必须对外暴露供应商查询接口，供财务系统、库存系统获取最新数据。一个常见错误是每个系统各自维护一套供应商信息，导致同一个供应商在财务系统叫“ABC 有限公司”，在采购系统叫“ABC 公司”，对账时永远对不上。

决策建议：如果企业有超过 100 个活跃供应商或跨法人实体采购，建议引入 MDM 或至少明确采购系统作为供应商主数据源。否则，采购系统只做引用。

物料主数据

物料主数据的归属更复杂。采购系统关注的物料属性（采购价格、采购单位、最小起订量）与库存系统（库存单位、批次属性）或产品数据管理系统（技术参数、BOM）可能不同。理想做法是物料主数据由 PLM 或 MDM 维护通用属性，采购系统维护采购专用属性。

实际项目中，很多企业让 ERP 系统承担物料主数据职责。采购系统通过接口获取物料列表，本地只存储与采购相关的扩展字段。这种方式要求采购系统在物料变更时及时同步，否则会出现采购单引用了 ERP 已停用的物料。

采购组织与法人关系

采购组织（Purchasing Organization）和法人实体（Company Code）的对应关系通常是财务系统的核心配置。采购系统在创建采购订单时，必须引用财务系统认可的法人编码，否则后续发票校验会失败。这类数据建议采购系统只读，从财务系统同步。

接口协议选择：REST 还是消息队列？

采购系统与外部系统的交互模式分为两类：同步查询和异步通知。选择哪种协议取决于数据实时性要求和失败容忍度。

同步查询：RESTful API

适用于高实时性、低数据量的场景。例如：采购员在创建采购单时查询供应商当前信用额度，这个操作需要秒级响应，且查询频率不高（每次创建时才触发）。用 REST API 最直接。

设计要点：

• 接口必须支持分页和过滤，避免一次返回全量数据。
• 超时时间应设置合理，一般 5 秒到 10 秒。超过 10 秒的查询应考虑异步方案。
• 查询类接口必须幂等（GET 天然幂等），但写操作（POST/PUT）必须显式实现幂等（见下一节）。

异步通知：消息队列（Message Queue）

适用于高吞吐、可容忍秒级延迟的场景。例如：采购订单审批通过后，需要通知库存系统预留物料、通知财务系统生成应付暂估。这些操作不需要实时返回，但必须保证最终送达。

常用中间件：RabbitMQ、Kafka、RocketMQ。选择时考虑企业现有技术栈和运维能力。Kafka 适合高吞吐日志型数据，但消息顺序保证需要额外配置；RabbitMQ 适合路由复杂的业务消息。

设计原则：

• 消息必须包含唯一业务 ID（如采购单号），便于消费端去重。
• 消息体应包含关键业务数据，避免消费端频繁回查。例如采购订单消息应包含供应商 ID、物料编码、数量、单价、交货日期，而不是只传一个订单号让消费端再查一次。
• 生产者必须实现发送确认（Publisher Confirm），消费端必须实现手动 ACK。

幂等设计：如何保证数据不重复？

幂等（Idempotency）是集成中最容易被忽视但后果最严重的问题。一次接口调用因为网络超时，客户端重试，结果服务器端创建了两条采购单。幂等设计的核心是：无论请求被重复执行多少次，业务结果只生效一次。

基于唯一键的幂等

最简单的做法：调用方在请求中携带全局唯一的业务键（Idempotency Key），接收方在第一次处理时记录该键，后续相同键的请求直接返回第一次的处理结果，不再重复执行。

采购场景示例：财务系统调用采购系统的“确认付款”接口，每次请求携带“付款流水号 + 采购单号”组合键。采购系统收到请求后，先查询该组合键是否已处理，已处理则直接返回成功，未处理则执行付款确认逻辑并记录键值。

注意事项：

• 幂等键的存储必须持久化（数据库或 Redis），不能仅靠内存缓存，因为服务重启会丢失。
• 幂等键的过期时间需要合理设置。一般建议 24 小时至 7 天，过期后允许重复执行。但涉及资金的接口，建议永不过期或由人工清除。
• 幂等键的生成规则由调用方负责，接收方只做校验。

基于业务状态的幂等

某些场景下，业务状态本身就是天然幂等键。例如：采购订单状态从“已审批”变更为“已发货”，如果订单当前已经是“已发货”，再次收到“已发货”请求应该直接返回成功，而不是报错。

这种方案要求接口设计时明确状态机的合法流转路径。例如：已审批 -> 已发货 -> 部分收货 -> 已收货 -> 已关闭。禁止跳过状态（如从已审批直接到已关闭），也禁止逆向流转（已发货不能回到已审批）。状态机定义越清晰，幂等判断越简单。

消息消费的幂等

消息队列场景下，消费端可能因为消费超时或重启而重复消费同一条消息。消费端必须在业务逻辑层实现幂等，而不是依赖消息中间件的“至少一次”语义。

做法：消费端在处理消息前，先检查业务数据是否已存在。例如消费“供应商信息变更”消息时，先根据供应商 ID 查询本地记录，如果本地记录的最后更新时间已经晚于消息中的时间戳，则跳过处理。

重试机制：失败时怎么办？

任何集成都可能失败：网络抖动、对方服务宕机、数据校验不通过。重试机制不能是简单的“失败了等一会儿再试”，必须分级设计。

客户端重试（调用方视角）

调用方发起请求时，如果遇到可重试的异常（如 HTTP 503、超时、连接重置），应该自动重试。不可重试的异常（如 HTTP 400 参数错误、401 认证失败）不应重试，应直接记录失败原因并告警。

重试策略推荐指数退避（Exponential Backoff）加随机抖动（Jitter）。例如：第一次重试等待 1 秒，第二次 2 秒，第三次 4 秒，最大等待时间 30 秒，总重试次数不超过 5 次。加上随机抖动（±500ms）可以避免多个客户端同时重试造成雪崩。

服务端重试（消息队列视角）

消息队列场景下，消费端处理失败时，通常将消息重新投递到延迟队列。延迟队列的配置需要区分失败类型：

• 业务校验失败（如采购单号不存在）：不重试，直接记录死信，人工介入。
• 系统异常（如数据库超时）：重试 3 次，间隔 1 分钟、5 分钟、30 分钟。
• 依赖服务不可用（如财务系统宕机）：重试 5 次，间隔 5 分钟、15 分钟、1 小时、4 小时、12 小时。

重试耗尽后，消息进入死信队列（Dead Letter Queue）。运维人员应每天检查死信队列，分析失败原因并手动处理。死信队列不应该被自动清理，保留至少 7 天。

全局重试治理

重试机制不能无限放大系统压力。一个采购系统对接 10 个下游系统，如果每个系统都独立做重试，遇到上游故障时可能产生 10 倍的重试流量。建议在采购系统内部实现统一的重试管理器，控制全局并发重试数量和频率。

具体做法：采购系统收到外部系统的重试请求时，先检查该请求对应的业务实体是否正在被其他重试任务处理。如果是，则排队等待而不是立即执行。同时设置全局重试速率限制，例如每分钟最多处理 200 个重试任务，超出部分直接拒绝并要求调用方稍后重试。

监控与告警：集成是否健康？

没有监控的集成是不可靠的。采购集成的监控维度应该覆盖三个层面：接口可用性、数据一致性、业务连续性。

接口可用性监控

每个集成的接口都应该有健康检查端点（Health Check），返回当前服务状态和依赖服务状态。例如采购系统的健康检查应该返回：“采购系统正常，ERP 接口正常，财务接口超时”。

监控指标：

• 接口响应时间 P95 和 P99。超过 5 秒的接口需要关注。
• 接口成功率。低于 99.5% 需要排查。
• 重试次数分布。某个接口的重试次数突然增加，通常意味着下游不稳定。

数据一致性监控

采购系统与下游系统的关键数据应该定期对账。例如每天凌晨对比采购系统与财务系统的应付账款数据，找出差异并自动生成差异报告。

对账方式：采购系统导出业务数据，下游系统导出对应数据，用脚本比对关键字段（金额、数量、状态）。差异数据自动发送给运维人员处理。对账不需要实时，但必须每天执行。

业务连续性监控

集成失败后，业务不能卡死。采购系统应该设计“降级模式”：当财务系统不可用时，采购单可以正常创建，但标记为“财务待同步”，财务系统恢复后自动补发。这种设计比“财务系统挂了，采购系统也瘫痪”要合理得多。

降级模式的关键是明确边界：哪些操作可以降级（如查询供应商信用额度降级为不校验），哪些操作必须强依赖（如付款确认必须等财务系统返回）。边界定义需要业务部门和技术部门一起确认。

集成测试：上线前必须验证什么？

采购系统集成上线前，测试覆盖不能只做功能验证。以下三类测试必须通过：

异常场景测试

• 模拟下游系统返回 HTTP 500，验证采购系统的重试逻辑是否正确。
• 模拟网络超时，验证幂等机制是否生效（重复请求不会创建重复数据）。
• 模拟消息队列宕机，验证生产者的消息是否持久化到本地磁盘，恢复后能否自动补发。

数据量压力测试

• 采购系统同时处理 1000 张采购单的同步请求，验证接口响应时间是否在可接受范围内。
• 消息队列积压 10 万条消息时，消费端能否正常处理，是否出现内存溢出。

恢复测试

• 模拟数据库宕机 10 分钟后恢复，验证采购系统能否自动重连并补发未处理的消息。
• 模拟消息队列数据丢失（如磁盘损坏），验证是否有备份机制恢复数据。

这些测试不需要每次上线都做全套，但每次涉及接口协议、重试策略、幂等逻辑变更时，必须执行。

常见误区与工程建议

根据多个项目的实盘经验，以下是采购系统集成中最常见的五个误区：

误区一：所有数据都通过同步接口实时获取。这会导致采购系统对下游系统的强依赖，下游一挂采购也挂。正确做法是区分实时查询和本地缓存，非实时数据通过消息队列异步同步。

误区二：重试策略一刀切。所有接口都用同样的重试间隔和次数，导致高频率接口的重试请求堆积。正确做法是根据接口的业务重要性和下游系统的负载能力分别配置。

误区三：幂等只靠数据库唯一索引。唯一索引只能防止重复插入，无法防止重复更新。例如“更新采购单金额”接口，重复调用可能导致金额被覆盖两次。正确做法是结合业务状态或版本号。

误区四：不设计降级模式。集成失败时业务直接卡死，用户只能等运维修复。正确做法是提前定义降级条件，让业务在部分系统不可用时继续流转。

误区五：监控只看接口成功率。成功率 99.9% 的接口，如果失败的都是大额采购单，业务影响依然很大。正确做法是监控失败数据的业务价值分布。

在 SystemDo 参与的一个制造企业采购系统项目中，客户最初要求所有集成都用 REST 同步，理由是“简单”。我们在设计评审中指出了单点故障风险，最终改为采购订单审批后通过消息队列异步通知库存和财务系统。上线后，财务系统因月底结账压力导致偶尔超时，采购系统未受任何影响。这个案例说明，集成设计不能只看实现成本，还要看运行时的鲁棒性。

总结：集成设计的三条底线

采购系统对接其他系统时，技术选型和实现细节可以灵活，但三条底线不能突破：

第一，主数据必须有唯一权威源。供应商、物料、法人等核心数据不能多头维护，否则数据一致性永远无法保证。

第二，写操作必须幂等。不管用唯一键还是状态机，必须保证重复请求不会造成业务数据重复。

第三，重试必须有上限和降级方案。无限重试等于没有重试，不设计降级等于把系统命脉交给别人。

这三条做到了，采购系统的集成质量就有了基本保障。剩下的细节——协议选型、数据格式、日志规范——可以根据团队习惯和现有基础设施调整，不会出大问题。