简介一份70页PPT完整承载某著名企业信息化发展规划中集成架构规划的顶层设计成果面向企业架构师、信息化规划人员与数字化转型顾问帮助拆解多业务板块融合后的系统集成难题。内容从业务发展趋势对信息集成的驱动力和要求讲起覆盖战略、财务、人力、投资、风险等八大管理领域以及矿业开发、金属流通两大核心运营平台的集成需求系统梳理界面集成、流程集成、数据集成、应用集成四类典型场景并借助集成能力评估框架逐一分析界面统一、流程贯通、数据共享的现状与关键发现提出改进建议在此基础上绘制总体集成架构蓝图与应用集成演进策略附件还包含集成需求清单与SOA基础说明为后续落地实施提供了完整参考框架。资源包仅1个pptx文件压缩包2.15MB轻量易用已有46人学习。1. 集成架构规划信息化规划里最容易被写得很薄的一层规划评审时最常被挑战的不是战略愿景而是集成架构。一份 70 页的信息化发展规划战略部分两三页就能讲过去集成架构却要占据十页以上还得当场回答哪些系统必须互联、哪些不需要、接口由谁提供、数据以谁为准、系统挂了业务怎么办。多数规划在这一层只放了一张 ESB 居中的拓扑图把所有集成问题简化成加一个总线。集成架构规划真正的价值是把系统边界、数据归属、同步策略和容错方案定清楚再决定用 API 网关、消息队列还是批处理去落地。下面这套做法做年度信息化规划、集成治理专项时可以直接复用。2. 集成现状评估先把系统、接口、数据流盘成一张矩阵2.1 三个清单系统清单、接口清单、数据流清单任何集成架构规划都不能从空白开始。无论目标架构定得多高第一步都是把现有集成关系摸清楚。访谈业务部门和开发团队时通常集中问三个核心问题企业里现有多少套业务系统这些系统两两之间是否存在数据交换交换是实时接口、定时批处理、文件传输还是人工导表。把答案落到台账上汇总成三张清单系统清单、接口清单、数据流清单。这三张清单不只是规划依据也是后续验收的基线。系统清单记录系统基本信息接口清单记录每条数据通路的来源、去向和方式数据流清单记录关键业务数据在各系统中的分布。字段不用做太细能指导决策就行。清单核心字段用途系统清单系统编码、系统名称、业务域、厂商/自研、技术栈、部署位置明确集成参与方和边界接口清单接口编号、源系统、目标系统、方向、业务场景、集成方式、协议、频率、数据量级识别集成点、估算治理工作量数据流清单数据实体、权威源系统、消费系统、同步方式、一致性要求主数据归属和冲突消解的依据提示接口清单最容易漏的是没有接口但靠人肉导表的数据流。这类隐性集成点往往是最该治理的存量问题访谈时一定要单独问一句现在有没有哪两个系统的数据是定期手工对账的。2.2 用脚本从访问日志里抽出接口清单系统清单靠访谈能基本做全接口清单则容易漏。常见做法是把集成平台、API 网关或应用服务器的访问日志统一导出一份用脚本聚合成源系统、API、调用量、错误量的粗粒度清单。脚本本身不复杂但比纯人工梳理完整得多。2.2.1 日志格式约定与脚本处理import re import sys from collections import defaultdict # 约定日志格式时间|源系统|目标API|状态码|耗时(ms)|消息ID # 示例2025-06-30 10:00:01|crm|/ip/order/create|200|230|a1b2c3 pattern re.compile( r^(?Pts\S \S)\| r(?Psrc\S)\| r(?Papi\S)\| r(?Pstatus\d{3})\| r(?Pcost\d)\| r(?Pmsgid\S)$ ) counter defaultdict(lambda: {calls: 0, errors: 0, total_cost: 0}) for line in sys.stdin: m pattern.match(line.strip()) if not m: continue src, api, status m.group(src), m.group(api), m.group(status) cost int(m.group(cost)) key (src, api) counter[key][calls] 1 counter[key][total_cost] cost if int(status) 400: counter[key][errors] 1 for (src, api), stat in sorted(counter.items(), keylambda kv: kv[1][calls], reverseTrue): avg_cost stat[total_cost] // stat[calls] print(f{src}\t{api}\t{stat[calls]}\t{stat[errors]}\t{avg_cost})脚本按约定的管道格式读取标准输入用正则解析出源系统、API 路径、状态码和耗时再按源系统 API聚合统计调用总量、错误数、平均耗时按调用量降序输出。执行时把网关日志重定向进脚本即可python3 parse_apis.py gateway.log api_list.tsv聚合出的 TSV 再合并进接口清单作为规划的现状基线。这个过程不消灭人工访谈但能把散落在几十个系统里的真实接口关系一次捞齐。2.2.2 输出口径与清单合并统计口径有三个地方要约定。第一状态码大于等于 400 记作错误但 5xx 重试和 3xx 跳转语义差别很大要看具体场景调整阈值。第二平均耗时是全量调用的算术平均会掩盖长尾规划矩阵里建议同时记录 P99抽几个耗时最高值看看是否集中在某个接口。第三这个清单只覆盖已经接入网关的流量直连数据库、SFTP 文件同步不在里面仍需访谈补全。2.3 用集成成熟度矩阵给每条集成关系打分拿到清单后不要急着画目标架构。常见做法是先给系统间的每条集成关系打一个成熟度分分数低的位置就是规划期内要优先治理的位置。评估维度一般取集成方式、接口标准化、主数据一致性、异常监控四项每项 1 到 4 分。维度1分2分3分4分集成方式人工导表定时文件/DB直连标准化API异步消息/事件驱动接口标准化各自定义报文有部分文档遵循统一规范带版本管理和契约测试主数据一致性多处维护无归属有维护但有冲突单一权威源实时订阅自动同步异常监控无监控只有日志记录有告警全链路追踪、自动补偿单条集成关系四项分数相加总分低于 8 分的进入治理范围12 分以上基本达到目标形态。评分时注意避免给自家系统都打高分建议由甲方的规划人员和独立技术评审分开打分取平均分。注意成熟度矩阵的意义不是排名而是让要动哪里、为什么动它有据可查。评分差异最大的两项通常就是痛点后续集成模式选型要优先回应这些痛点。2.4 从矩阵中圈出三类规划重点矩阵打分完成后整理出三类重点清单。第一类是高频率集成点调用量大但现状是文件直传或手工处理的优先设计成服务接口。第二类是失败率高的接口错误率超过 0.1% 的要查超时、重试、幂等这类问题常出现在跨部门系统之间。第三类是跨系统共享的数据实体比如客户、物料、订单凡是两个以上系统都在维护的直接进入主数据归属清单。这三类清单就是集成架构蓝图的输入。规划不需要覆盖所有系统先管住业务影响最大的前 20 个集成点效果会好过把 100 个接口全部重做一遍。3. 集成模式选型ESB、API 网关、消息队列、数据集成各管一段3.1 四种集成模式的分工集成现状盘完了接下来是把集成关系映射到具体技术上。规划中最大的常见误用是让所有集成一律走 ESB或一律走 API 网关。不同集成语义匹配不同模式选型的依据是业务对实时性、耦合度和数据量的要求。四种模式各管一段点对点接口HTTP/文件直接对接适合双方团队能同步排期、接口数量少、变更影响可控的场景。遗留系统之间常见规划的重点是决定保留还是收编不是见一个拆一个。ESB企业服务总线主打多协议转换、消息路由和服务编排适合异构系统多、通信协议杂SOAP、MQ、FTP 混杂的传统企业。API 网关面向服务入口的治理统一认证、限流、灰度、可观测适合前端、移动端、外部合作方访问业务服务的场景。消息队列/事件驱动解决异步解耦、削峰填谷、状态通知适合下单通知、库存联动、数据分发。数据集成ETL/CDC面向批量、流式数据同步适合数仓、数据集市、主数据分发。规律很明显越靠近业务入口、越要求实时返回的用同步 API越靠数据流转和状态联动、越允许延迟的用消息和批处理。ESB 只应该出现在协议必须转换的位置不是中间放一个总线就叫集成架构。3.2 先决策同步还是异步再谈工具集成选型的第一个分支不是工具选型而是同步/异步决策。判断标准收敛成一个问题业务上发起方是否必须拿到对方的处理结果后才能继续必须等待结果的走同步调用可以先记下来、后处理的走异步。规划文档里每个集成点都要标上这个结论两个结论混在一起写后续实现必然出问题。同步调用要注意超时和重试设计。超时建议分级内部服务读超时 2~3 秒写超时 3~5 秒跨企业间接口放宽到 5~10 秒。重试要指数退避不要固定间隔硬闯。异步集成则必须应对消息丢失、重复、乱序三个问题对应设计持久化、幂等键和顺序语义。还有折中形态叫同步接口 异步内部处理。接口立即返回已受理 任务号后台用队列把写库、通知、对账逐项完成。这种模式适合耗时不可控的批量操作但要在接口契约里明确状态语义让调用方知道返回不代表终态。3.3 集成模式选型决策表把常见集成场景和推荐模式对应起来可以直接用于评审沟通。建议先按这张决策表过滤一遍再决定是否需要引入中间件。集成场景推荐模式不建议的做法前端查订单、查用户信息API 网关同步把查询结果丢进消息队列再推回来下单后通知仓储、积分、客服消息队列异步同步调用一串下游拖慢主流程多个遗留系统协议不一SOAP/MQ/HTTPESB 做协议转换让各系统各自实现对方协议每晚同步 ERP 组织数据到数仓ETL/CDC 批处理用实时接口逐条推送两个系统需要共用主数据CDC 订阅分发两边各自维护一遍再对账这张表判完90% 的集成点会有明确方向。剩下 10% 处于边界场景例如流程强一致性要求归到 ESB 或服务编排层单独决策按业务容忍度倒推。3.4 消息中间件与 API 网关注重哪些参数集成平台的具体组件不需要在规划阶段选死但性能参数基线要定下来。按订单类业务常见的量级估算峰值 TPS 2000、平均消息大小 10 KB、要求端到端可追踪消息中间件的关键参数按下面几项考虑。# RocketMQ broker 配置参数规划基线按业务量等比调整 brokerClusterNameDefaultCluster namesrvAddr10.0.10.11:9876;10.0.10.12:9876 # 异步刷盘 异步复制单机顺序写 TPS 可达十万级适合内部消息 flushDiskTypeASYNC_FLUSH brokerRoleASYNC_MASTER # 消息体最大 4MB超过就走对象存储只传引用 maxMessageSize4194304 # 消费线程数默认 20IO 密集场景可提到 48 consumeThreadMin20 consumeThreadMax48刷盘和复制策略决定了可靠性换吞吐的取舍异步刷盘适合内部消息支付、账单类要求不丢消息的场景要改成同步刷盘。消费线程数影响单机吞吐提太高会造成磁盘 IO 竞争建议按 CPU 核数的 1.5~2 倍设置。规划材料里不用写配置细节但要写清峰值流量、可靠性等级、延迟上限三项作为采购和部署阶段的输入。API 网关侧重限流和幂等。令牌桶算法的常见参数是容量 1000、填充速率 500 每秒更简单的额度法是按月度配额除以峰值系数。幂等设计现在基本规约化调用方生成 UUID 放进X-Request-ID头服务端按这个键做结果缓存和去重表。这一条要写进集成架构蓝图的接口规范。4. 集成架构蓝图分层方案、接口规范、主数据归属与容量估算4.1 集成架构分层接入层、集成服务层、数据层蓝图部分要用一张分层图回答未来集成长什么样。常见做法是分成三层。接入层是消费端访问服务时的统一入口落点是 API 网关认证、限流、版本管理在这里做。集成服务层是核心地带服务编排、协议转换、消息路由、异步处理全部在这一层由 ESB 和消息平台协同承担。数据层负责跨系统的数据分发和汇总用 CDC 和 ETL 把主数据变更同步给下游消费系统。层职责主要组件规划关注点接入层统一入口、认证、限流、灰度API 网关认证协议、配额、审计集成服务层服务编排、协议转换、消息路由ESB、消息平台流程边界、消息契约、幂等数据层主数据分发、批量同步CDC、ETL、数仓数据归属、同步链路、延迟很多规划在这里的常见失误是让 ESB 承担接入层职责把外部请求也绕进总线。接入层和集成服务层要拆开外部流量在网关完成认证和限流后再进集成服务层内部系统间消息则可以直接进消息平台。这样的边界让安全策略和性能容量可以独立调整。4.2 一套能落地的接口规范超时、重试、幂等、限流蓝图里必须附一版接口规约否则后续开发各写各的。下面这份 YAML 是常见的最小集可以直接裁减成团队规范文档。# 集成平台接口规范 v1.2节选 api: prefix: /ip # 集成平台统一前缀 version: v1 # 版本号放路径避免破坏性变更 timeout: read: 3000 # 读超时 3s write: 3000 # 写超时 3s retry: max_attempts: 3 # 最多重试 3 次 backoff: [200, 500, 1000] # 指数退避单位 ms idempotency: header: X-Request-ID # 调用方每次生成 UUID 放在此头 dedupe_ttl: 86400 # 结果缓存 24h rate_limit: default_tps: 500 # 单接口默认 500 TPS burst: 1000 # 突发容量 2 倍路径规划采用/ip/{version}/{domain}/{resource}的形式版本放路径而不是查询参数升级时双版本并存一个周期到期再下掉。超时和重试是配套设计的同步接口重试的前提是接口幂等如果目标系统不能保证幂等宁可把重试次数降到 1 次也不要去撞重复数据。限流参数按业务峰值设置默认 500 TPS 对大多数制造业、零售业的内网服务足够秒杀类场景单独申请。消息集成要有同样的消息契约规范。常见的约定是 topic 命名domain.event.action三段式例如order.event.created事件 payload 里必须带eventId、occurredAt、source三个公共字段。字段都定义在 schema 里消费方不允许用我猜字段含义来对接。4.3 主数据归属一个数据实体只认一个权威系统集成架构里最容易被业务挑战的不是技术而是数据以谁为准。规划阶段把核心数据实体的归属定清楚建设期才能少吵架。各系统之间不直接更新对方数据表统一由归属方发事件其他系统订阅。下面这张表是规划材料里最常见的格式。数据实体权威归属系统分发方式消费者组织架构HR/主数据平台CDC 实时预算、OA、项目、CRM人员信息HR/主数据平台CDC 实时考勤、财务、项目客户档案CRMAPI 订阅订单、售后、财务物料主数据ERP/物料系统批量 事件采购、库存、计划供应商主数据ERP/供应商门户批量采购、财务、质检会计科目财务核算系统批量预算、成本、费用每条数据实体写清归属方、分发方式和消费方表格本身可以作为规划评审中的争议裁决表。归属原则一句话谁产生这条数据、谁最频繁修改它、谁对数据质量负最终责任谁就是权威源。实现归属时有两条比较稳妥的路径。一是归属方发布 消费方订阅归属方通过消息主题把变更广播出去消费方各自落地实时性高适合需要快速响应的场景。二是归属方登记 集成平台拉取由集成平台定时抓取对归属方系统的侵入极小适合改造周期长的传统核心系统。4.4 集成平台容量估算并发、带宽、存储三件事集成架构规划里容量不用做到精确设计但要用公式把量级论证清楚。并发计算用一个简化公式先估算同时在线请求线程数 N ≈ QPS × P99延迟秒×1 冗余系数其中延迟取 P99 而不是平均值冗余系数取 0.3~0.5。举例集成平台承接 500 QPS接口 P99 延迟 500 毫秒则 N ≈ 500 × 0.5 × 1.4 ≈ 350。这个数字对应网关或集成平台的线程池、连接池规划。如果 350 已经是瓶颈优先做两步优化慢接口把 P99 降下来或者把非实时调用挪到消息异步。带宽估算则是把典型报文平均大小乘以峰值 QPS 再乘 8字节转比特得到 bps。例如平均报文 50 KB、峰值 1000 QPS约 400 Mbps考虑冗余应预留 1 Gbps 接入带宽。注意容量估算最容易翻车在两个假设——用了平均延迟而不是 P99以及把全天平均流量当成峰值流量。规划文档里把这两个口径写清楚评审基本不会在这页被卡。5. 集成架构落地路线图分阶段推进、费用测算与验收指标5.1 三阶段路线图治理、平台、服务化规划交付后最怕一次性铺开。常见做法是分三阶段走。阶段一0~6 个月做存量治理先建统一日志和异常监控把失败率最高的 20 个接口修复同步建立接口规范阶段二6~18 个月建平台部署 API 网关和消息平台把高频同步调用迁移到网关异步场景推到消息阶段三18~36 个月做服务化和数据资产化主数据归属落实到平台ESB 协议转换收拢试点事件驱动架构。5.2 参照费用测算标准粗估集成建设投入集成规划的预算可以参照四川省信息化项目费用测算标准这类政府/行业测算文件的通用口径来粗估。简便做法是把工作量分成新增接口和存量治理两类存量治理按每接口 2~4 人天、新增按每接口 3~8 人天估算乘上本地市场人天单价再加集成平台采购和运维成本。人天单价以当地测算文件公布的区间为准。按 120 个存量接口重点治理的场景粗算大约在 500~900 人天这个量级可以直接用于排期和立项。5.3 验收与监控脚本 指标卡住集成绩效集成的可用性验收可以做成定期抽检脚本把状态码、耗时记录到日志文件再做聚合报表# 抽检集成平台核心接口记录状态码和耗时到 /tmp/api_health.log for api in /ip/v1/order/create /ip/v1/order/query /ip/v1/inventory/deduct; do start_ts$(date %s%3N) code$(curl -s -o /dev/null -w %{http_code} -m 5 -X POST \ -H X-Request-ID: $(uuidgen) \ -H Content-Type: application/json \ -d {check: true} https://gw.example.com${api}) end_ts$(date %s%3N) echo $(date %Y-%m-%d %H:%M:%S)|${api}|${code}|$((end_ts-start_ts)) /tmp/api_health.log done脚本在 Linux 的 bash 环境执行-m 5限制单次最多 5 秒返回超过即失败避免抽检卡死X-Request-ID每次用uuidgen生成正好同时验证幂等逻辑耗时由脚本自己计时不依赖服务端报告。汇总指标建议设为接口成功率不低于 99.9%P99 耗时低于 1 秒消息积压超过阈值 10 分钟触发告警。拿这套指标对照规划 PPT 里的承诺值就是集成架构规划从文档走向运维闭环的最终落点。本文还有配套的精品资源点击获取 从现状评估到落地：企业集成架构规划实践指南
简介一份70页PPT完整承载某著名企业信息化发展规划中集成架构规划的顶层设计成果面向企业架构师、信息化规划人员与数字化转型顾问帮助拆解多业务板块融合后的系统集成难题。内容从业务发展趋势对信息集成的驱动力和要求讲起覆盖战略、财务、人力、投资、风险等八大管理领域以及矿业开发、金属流通两大核心运营平台的集成需求系统梳理界面集成、流程集成、数据集成、应用集成四类典型场景并借助集成能力评估框架逐一分析界面统一、流程贯通、数据共享的现状与关键发现提出改进建议在此基础上绘制总体集成架构蓝图与应用集成演进策略附件还包含集成需求清单与SOA基础说明为后续落地实施提供了完整参考框架。资源包仅1个pptx文件压缩包2.15MB轻量易用已有46人学习。1. 集成架构规划信息化规划里最容易被写得很薄的一层规划评审时最常被挑战的不是战略愿景而是集成架构。一份 70 页的信息化发展规划战略部分两三页就能讲过去集成架构却要占据十页以上还得当场回答哪些系统必须互联、哪些不需要、接口由谁提供、数据以谁为准、系统挂了业务怎么办。多数规划在这一层只放了一张 ESB 居中的拓扑图把所有集成问题简化成加一个总线。集成架构规划真正的价值是把系统边界、数据归属、同步策略和容错方案定清楚再决定用 API 网关、消息队列还是批处理去落地。下面这套做法做年度信息化规划、集成治理专项时可以直接复用。2. 集成现状评估先把系统、接口、数据流盘成一张矩阵2.1 三个清单系统清单、接口清单、数据流清单任何集成架构规划都不能从空白开始。无论目标架构定得多高第一步都是把现有集成关系摸清楚。访谈业务部门和开发团队时通常集中问三个核心问题企业里现有多少套业务系统这些系统两两之间是否存在数据交换交换是实时接口、定时批处理、文件传输还是人工导表。把答案落到台账上汇总成三张清单系统清单、接口清单、数据流清单。这三张清单不只是规划依据也是后续验收的基线。系统清单记录系统基本信息接口清单记录每条数据通路的来源、去向和方式数据流清单记录关键业务数据在各系统中的分布。字段不用做太细能指导决策就行。清单核心字段用途系统清单系统编码、系统名称、业务域、厂商/自研、技术栈、部署位置明确集成参与方和边界接口清单接口编号、源系统、目标系统、方向、业务场景、集成方式、协议、频率、数据量级识别集成点、估算治理工作量数据流清单数据实体、权威源系统、消费系统、同步方式、一致性要求主数据归属和冲突消解的依据提示接口清单最容易漏的是没有接口但靠人肉导表的数据流。这类隐性集成点往往是最该治理的存量问题访谈时一定要单独问一句现在有没有哪两个系统的数据是定期手工对账的。2.2 用脚本从访问日志里抽出接口清单系统清单靠访谈能基本做全接口清单则容易漏。常见做法是把集成平台、API 网关或应用服务器的访问日志统一导出一份用脚本聚合成源系统、API、调用量、错误量的粗粒度清单。脚本本身不复杂但比纯人工梳理完整得多。2.2.1 日志格式约定与脚本处理import re import sys from collections import defaultdict # 约定日志格式时间|源系统|目标API|状态码|耗时(ms)|消息ID # 示例2025-06-30 10:00:01|crm|/ip/order/create|200|230|a1b2c3 pattern re.compile( r^(?Pts\S \S)\| r(?Psrc\S)\| r(?Papi\S)\| r(?Pstatus\d{3})\| r(?Pcost\d)\| r(?Pmsgid\S)$ ) counter defaultdict(lambda: {calls: 0, errors: 0, total_cost: 0}) for line in sys.stdin: m pattern.match(line.strip()) if not m: continue src, api, status m.group(src), m.group(api), m.group(status) cost int(m.group(cost)) key (src, api) counter[key][calls] 1 counter[key][total_cost] cost if int(status) 400: counter[key][errors] 1 for (src, api), stat in sorted(counter.items(), keylambda kv: kv[1][calls], reverseTrue): avg_cost stat[total_cost] // stat[calls] print(f{src}\t{api}\t{stat[calls]}\t{stat[errors]}\t{avg_cost})脚本按约定的管道格式读取标准输入用正则解析出源系统、API 路径、状态码和耗时再按源系统 API聚合统计调用总量、错误数、平均耗时按调用量降序输出。执行时把网关日志重定向进脚本即可python3 parse_apis.py gateway.log api_list.tsv聚合出的 TSV 再合并进接口清单作为规划的现状基线。这个过程不消灭人工访谈但能把散落在几十个系统里的真实接口关系一次捞齐。2.2.2 输出口径与清单合并统计口径有三个地方要约定。第一状态码大于等于 400 记作错误但 5xx 重试和 3xx 跳转语义差别很大要看具体场景调整阈值。第二平均耗时是全量调用的算术平均会掩盖长尾规划矩阵里建议同时记录 P99抽几个耗时最高值看看是否集中在某个接口。第三这个清单只覆盖已经接入网关的流量直连数据库、SFTP 文件同步不在里面仍需访谈补全。2.3 用集成成熟度矩阵给每条集成关系打分拿到清单后不要急着画目标架构。常见做法是先给系统间的每条集成关系打一个成熟度分分数低的位置就是规划期内要优先治理的位置。评估维度一般取集成方式、接口标准化、主数据一致性、异常监控四项每项 1 到 4 分。维度1分2分3分4分集成方式人工导表定时文件/DB直连标准化API异步消息/事件驱动接口标准化各自定义报文有部分文档遵循统一规范带版本管理和契约测试主数据一致性多处维护无归属有维护但有冲突单一权威源实时订阅自动同步异常监控无监控只有日志记录有告警全链路追踪、自动补偿单条集成关系四项分数相加总分低于 8 分的进入治理范围12 分以上基本达到目标形态。评分时注意避免给自家系统都打高分建议由甲方的规划人员和独立技术评审分开打分取平均分。注意成熟度矩阵的意义不是排名而是让要动哪里、为什么动它有据可查。评分差异最大的两项通常就是痛点后续集成模式选型要优先回应这些痛点。2.4 从矩阵中圈出三类规划重点矩阵打分完成后整理出三类重点清单。第一类是高频率集成点调用量大但现状是文件直传或手工处理的优先设计成服务接口。第二类是失败率高的接口错误率超过 0.1% 的要查超时、重试、幂等这类问题常出现在跨部门系统之间。第三类是跨系统共享的数据实体比如客户、物料、订单凡是两个以上系统都在维护的直接进入主数据归属清单。这三类清单就是集成架构蓝图的输入。规划不需要覆盖所有系统先管住业务影响最大的前 20 个集成点效果会好过把 100 个接口全部重做一遍。3. 集成模式选型ESB、API 网关、消息队列、数据集成各管一段3.1 四种集成模式的分工集成现状盘完了接下来是把集成关系映射到具体技术上。规划中最大的常见误用是让所有集成一律走 ESB或一律走 API 网关。不同集成语义匹配不同模式选型的依据是业务对实时性、耦合度和数据量的要求。四种模式各管一段点对点接口HTTP/文件直接对接适合双方团队能同步排期、接口数量少、变更影响可控的场景。遗留系统之间常见规划的重点是决定保留还是收编不是见一个拆一个。ESB企业服务总线主打多协议转换、消息路由和服务编排适合异构系统多、通信协议杂SOAP、MQ、FTP 混杂的传统企业。API 网关面向服务入口的治理统一认证、限流、灰度、可观测适合前端、移动端、外部合作方访问业务服务的场景。消息队列/事件驱动解决异步解耦、削峰填谷、状态通知适合下单通知、库存联动、数据分发。数据集成ETL/CDC面向批量、流式数据同步适合数仓、数据集市、主数据分发。规律很明显越靠近业务入口、越要求实时返回的用同步 API越靠数据流转和状态联动、越允许延迟的用消息和批处理。ESB 只应该出现在协议必须转换的位置不是中间放一个总线就叫集成架构。3.2 先决策同步还是异步再谈工具集成选型的第一个分支不是工具选型而是同步/异步决策。判断标准收敛成一个问题业务上发起方是否必须拿到对方的处理结果后才能继续必须等待结果的走同步调用可以先记下来、后处理的走异步。规划文档里每个集成点都要标上这个结论两个结论混在一起写后续实现必然出问题。同步调用要注意超时和重试设计。超时建议分级内部服务读超时 2~3 秒写超时 3~5 秒跨企业间接口放宽到 5~10 秒。重试要指数退避不要固定间隔硬闯。异步集成则必须应对消息丢失、重复、乱序三个问题对应设计持久化、幂等键和顺序语义。还有折中形态叫同步接口 异步内部处理。接口立即返回已受理 任务号后台用队列把写库、通知、对账逐项完成。这种模式适合耗时不可控的批量操作但要在接口契约里明确状态语义让调用方知道返回不代表终态。3.3 集成模式选型决策表把常见集成场景和推荐模式对应起来可以直接用于评审沟通。建议先按这张决策表过滤一遍再决定是否需要引入中间件。集成场景推荐模式不建议的做法前端查订单、查用户信息API 网关同步把查询结果丢进消息队列再推回来下单后通知仓储、积分、客服消息队列异步同步调用一串下游拖慢主流程多个遗留系统协议不一SOAP/MQ/HTTPESB 做协议转换让各系统各自实现对方协议每晚同步 ERP 组织数据到数仓ETL/CDC 批处理用实时接口逐条推送两个系统需要共用主数据CDC 订阅分发两边各自维护一遍再对账这张表判完90% 的集成点会有明确方向。剩下 10% 处于边界场景例如流程强一致性要求归到 ESB 或服务编排层单独决策按业务容忍度倒推。3.4 消息中间件与 API 网关注重哪些参数集成平台的具体组件不需要在规划阶段选死但性能参数基线要定下来。按订单类业务常见的量级估算峰值 TPS 2000、平均消息大小 10 KB、要求端到端可追踪消息中间件的关键参数按下面几项考虑。# RocketMQ broker 配置参数规划基线按业务量等比调整 brokerClusterNameDefaultCluster namesrvAddr10.0.10.11:9876;10.0.10.12:9876 # 异步刷盘 异步复制单机顺序写 TPS 可达十万级适合内部消息 flushDiskTypeASYNC_FLUSH brokerRoleASYNC_MASTER # 消息体最大 4MB超过就走对象存储只传引用 maxMessageSize4194304 # 消费线程数默认 20IO 密集场景可提到 48 consumeThreadMin20 consumeThreadMax48刷盘和复制策略决定了可靠性换吞吐的取舍异步刷盘适合内部消息支付、账单类要求不丢消息的场景要改成同步刷盘。消费线程数影响单机吞吐提太高会造成磁盘 IO 竞争建议按 CPU 核数的 1.5~2 倍设置。规划材料里不用写配置细节但要写清峰值流量、可靠性等级、延迟上限三项作为采购和部署阶段的输入。API 网关侧重限流和幂等。令牌桶算法的常见参数是容量 1000、填充速率 500 每秒更简单的额度法是按月度配额除以峰值系数。幂等设计现在基本规约化调用方生成 UUID 放进X-Request-ID头服务端按这个键做结果缓存和去重表。这一条要写进集成架构蓝图的接口规范。4. 集成架构蓝图分层方案、接口规范、主数据归属与容量估算4.1 集成架构分层接入层、集成服务层、数据层蓝图部分要用一张分层图回答未来集成长什么样。常见做法是分成三层。接入层是消费端访问服务时的统一入口落点是 API 网关认证、限流、版本管理在这里做。集成服务层是核心地带服务编排、协议转换、消息路由、异步处理全部在这一层由 ESB 和消息平台协同承担。数据层负责跨系统的数据分发和汇总用 CDC 和 ETL 把主数据变更同步给下游消费系统。层职责主要组件规划关注点接入层统一入口、认证、限流、灰度API 网关认证协议、配额、审计集成服务层服务编排、协议转换、消息路由ESB、消息平台流程边界、消息契约、幂等数据层主数据分发、批量同步CDC、ETL、数仓数据归属、同步链路、延迟很多规划在这里的常见失误是让 ESB 承担接入层职责把外部请求也绕进总线。接入层和集成服务层要拆开外部流量在网关完成认证和限流后再进集成服务层内部系统间消息则可以直接进消息平台。这样的边界让安全策略和性能容量可以独立调整。4.2 一套能落地的接口规范超时、重试、幂等、限流蓝图里必须附一版接口规约否则后续开发各写各的。下面这份 YAML 是常见的最小集可以直接裁减成团队规范文档。# 集成平台接口规范 v1.2节选 api: prefix: /ip # 集成平台统一前缀 version: v1 # 版本号放路径避免破坏性变更 timeout: read: 3000 # 读超时 3s write: 3000 # 写超时 3s retry: max_attempts: 3 # 最多重试 3 次 backoff: [200, 500, 1000] # 指数退避单位 ms idempotency: header: X-Request-ID # 调用方每次生成 UUID 放在此头 dedupe_ttl: 86400 # 结果缓存 24h rate_limit: default_tps: 500 # 单接口默认 500 TPS burst: 1000 # 突发容量 2 倍路径规划采用/ip/{version}/{domain}/{resource}的形式版本放路径而不是查询参数升级时双版本并存一个周期到期再下掉。超时和重试是配套设计的同步接口重试的前提是接口幂等如果目标系统不能保证幂等宁可把重试次数降到 1 次也不要去撞重复数据。限流参数按业务峰值设置默认 500 TPS 对大多数制造业、零售业的内网服务足够秒杀类场景单独申请。消息集成要有同样的消息契约规范。常见的约定是 topic 命名domain.event.action三段式例如order.event.created事件 payload 里必须带eventId、occurredAt、source三个公共字段。字段都定义在 schema 里消费方不允许用我猜字段含义来对接。4.3 主数据归属一个数据实体只认一个权威系统集成架构里最容易被业务挑战的不是技术而是数据以谁为准。规划阶段把核心数据实体的归属定清楚建设期才能少吵架。各系统之间不直接更新对方数据表统一由归属方发事件其他系统订阅。下面这张表是规划材料里最常见的格式。数据实体权威归属系统分发方式消费者组织架构HR/主数据平台CDC 实时预算、OA、项目、CRM人员信息HR/主数据平台CDC 实时考勤、财务、项目客户档案CRMAPI 订阅订单、售后、财务物料主数据ERP/物料系统批量 事件采购、库存、计划供应商主数据ERP/供应商门户批量采购、财务、质检会计科目财务核算系统批量预算、成本、费用每条数据实体写清归属方、分发方式和消费方表格本身可以作为规划评审中的争议裁决表。归属原则一句话谁产生这条数据、谁最频繁修改它、谁对数据质量负最终责任谁就是权威源。实现归属时有两条比较稳妥的路径。一是归属方发布 消费方订阅归属方通过消息主题把变更广播出去消费方各自落地实时性高适合需要快速响应的场景。二是归属方登记 集成平台拉取由集成平台定时抓取对归属方系统的侵入极小适合改造周期长的传统核心系统。4.4 集成平台容量估算并发、带宽、存储三件事集成架构规划里容量不用做到精确设计但要用公式把量级论证清楚。并发计算用一个简化公式先估算同时在线请求线程数 N ≈ QPS × P99延迟秒×1 冗余系数其中延迟取 P99 而不是平均值冗余系数取 0.3~0.5。举例集成平台承接 500 QPS接口 P99 延迟 500 毫秒则 N ≈ 500 × 0.5 × 1.4 ≈ 350。这个数字对应网关或集成平台的线程池、连接池规划。如果 350 已经是瓶颈优先做两步优化慢接口把 P99 降下来或者把非实时调用挪到消息异步。带宽估算则是把典型报文平均大小乘以峰值 QPS 再乘 8字节转比特得到 bps。例如平均报文 50 KB、峰值 1000 QPS约 400 Mbps考虑冗余应预留 1 Gbps 接入带宽。注意容量估算最容易翻车在两个假设——用了平均延迟而不是 P99以及把全天平均流量当成峰值流量。规划文档里把这两个口径写清楚评审基本不会在这页被卡。5. 集成架构落地路线图分阶段推进、费用测算与验收指标5.1 三阶段路线图治理、平台、服务化规划交付后最怕一次性铺开。常见做法是分三阶段走。阶段一0~6 个月做存量治理先建统一日志和异常监控把失败率最高的 20 个接口修复同步建立接口规范阶段二6~18 个月建平台部署 API 网关和消息平台把高频同步调用迁移到网关异步场景推到消息阶段三18~36 个月做服务化和数据资产化主数据归属落实到平台ESB 协议转换收拢试点事件驱动架构。5.2 参照费用测算标准粗估集成建设投入集成规划的预算可以参照四川省信息化项目费用测算标准这类政府/行业测算文件的通用口径来粗估。简便做法是把工作量分成新增接口和存量治理两类存量治理按每接口 2~4 人天、新增按每接口 3~8 人天估算乘上本地市场人天单价再加集成平台采购和运维成本。人天单价以当地测算文件公布的区间为准。按 120 个存量接口重点治理的场景粗算大约在 500~900 人天这个量级可以直接用于排期和立项。5.3 验收与监控脚本 指标卡住集成绩效集成的可用性验收可以做成定期抽检脚本把状态码、耗时记录到日志文件再做聚合报表# 抽检集成平台核心接口记录状态码和耗时到 /tmp/api_health.log for api in /ip/v1/order/create /ip/v1/order/query /ip/v1/inventory/deduct; do start_ts$(date %s%3N) code$(curl -s -o /dev/null -w %{http_code} -m 5 -X POST \ -H X-Request-ID: $(uuidgen) \ -H Content-Type: application/json \ -d {check: true} https://gw.example.com${api}) end_ts$(date %s%3N) echo $(date %Y-%m-%d %H:%M:%S)|${api}|${code}|$((end_ts-start_ts)) /tmp/api_health.log done脚本在 Linux 的 bash 环境执行-m 5限制单次最多 5 秒返回超过即失败避免抽检卡死X-Request-ID每次用uuidgen生成正好同时验证幂等逻辑耗时由脚本自己计时不依赖服务端报告。汇总指标建议设为接口成功率不低于 99.9%P99 耗时低于 1 秒消息积压超过阈值 10 分钟触发告警。拿这套指标对照规划 PPT 里的承诺值就是集成架构规划从文档走向运维闭环的最终落点。本文还有配套的精品资源点击获取