异构端到端流程可见性的五种方案对比

[[避免巨石流程流程模型必须完全归属一个上下文]]已经说明端到端流程很少只在一个上下文/微服务里执行，它甚至可能在工作流引擎介入之前就已经开始（比如入网流程可能从用户下载纸质表格、扫描、OCR分类就已经算起）——因此要看清整个端到端流程，需要跨系统拼接可见性，本章给出五种现实方案各自的取舍。分布式追踪：借助微服务社区成熟的可观测性工具（如Zipkin），靠唯一追踪ID在HTTP Header或消息头中透传来重建调用栈，成熟易上手，但有两个致命局限——普通业务人员很难看懂追踪结果（作者向非技术人员展示都失败了，反而用简单矩形箭头重画一遍效果更好），而且为了处理海量细粒度数据，追踪系统通常只采样一小部分（90%以上的请求可能根本没被记录），永远无法完整还原实际发生的事情。自定义集中式监控：改为收集有业务含义的领域事件（可能来自事件驱动架构本身、专门为监控发出的自定义事件、或从遗留系统提取），构建一个监听所有事件并集中存储的服务，粒度更合适，还能用bpmn.io这类轻量框架把状态叠加展示在图形流程模型上；代价是需要额外开发工作，在大型企业里常卡在”这个组件到底该由谁构建和运维”的所有权问题上。数据仓库/BI工具：直接复用现有DWH或BI能力，省去搭建新的集中式工具，但代价是丢失流程上下文和可视化流程模型，把审计数据预处理成DWH可用格式往往也很困难。流程挖掘工具：擅长从ERP/CRM等系统的历史日志文件里挖掘出流程模型、发现瓶颈，特别适合分析理解一个庞大陌生的遗留系统；但它们分析的是静态日志而非实时事件流，通常用Direct Follower Graph而非BPMN展示（不利于向所有干系人沟通），不适合用作实时监控或报告。流程事件监控：把事件映射到一个专门用于监控的流程模型上的任务节点，思路和自定义监控类似，区别是很多功能已由厂商预制好，省去自建的工作量。作者提醒这些类别边界正在变得模糊，各类工具都在互相借鉴对方的能力。

结构图：

flowchart TD
    A[异构端到端流程可见性方案] --> B[分布式追踪<br/>调用栈级ID透传]
    A --> C[自定义集中式监控<br/>业务/领域事件聚合]
    A --> D[数据仓库/BI工具<br/>复用现有DWH]
    A --> E[流程挖掘<br/>挖掘历史日志文件]
    A --> F[流程事件监控<br/>事件映射到监控流程模型]
    B -->|局限| B1[非工程师难懂+采样丢失90%+数据]
    C -->|局限| C1[需额外开发,所有权归属不明]
    D -->|局限| D1[丢失流程上下文和可视化模型]
    E -->|局限| E1[静态日志非实时,用DFG而非BPMN]
    F -->|优势| F1[厂商预制,省去自建工作量]