如何利用抽象方法在流程引擎中强制各个节点上报当前吞吐指标

在流程引擎里做吞吐监控，最怕的不是技术选型，也不是数据存储，而是各个节点、各个开发团队各自为政。有的节点报了，有的节点忘了，有的报的格式五花八门——最后汇总到监控大盘，数据口径都对不上，那就彻底失去监控的意义了。

所以，真正靠谱的做法，是在架构层面就把“必须上报”这个规矩写进代码里，编都编不过去。这就要靠抽象方法了。

抽象基类：把“上报吞吐”变成硬性契约

先定义一个抽象基类，让所有流程节点——无论你是做设备数据采集的、做字段校验的、还是给PLC发写入指令的——都必须继承它。这个基类里有一条核心规矩：声明一个抽象方法：

• reportThroughput(ThroughputMetrics metrics)，参数是一个标准化的吞吐指标对象，里面至少包含processedCount（处理量）、errorCount（异常数）、lastLatencyMs（最近一次耗时毫秒值）这几个字段。
• 这个方法没有默认实现，子类必须自己重写，否则编译直接报错，没得商量。
• 基类在execute()方法执行完毕之前，会自动调用这个上报方法。也就是说，不管业务逻辑跑得顺不顺利，这趟上报动作是无论如何都会被触发一次的。

指标对象不是空壳：得带着数据和上下文

光规定“你得上报”还不够，如果指标对象本身是个空壳子，子类还得自己去拼数据、算时间戳、处理并发，那这个设计就打了折扣。

一个合格的ThroughputMetrics，应该做到：

• 构造时直接绑定当前的Execution实例，能自动提取processInstanceId、nodeId、startTime这些元信息。
• 内部集成计时器钩子：节点刚进入时调startTimer()，执行结束后自动算耗时、累加到统计数据里。
• 使用线程安全的原子计数器（比如AtomicLong processed）来记录处理量，避免多个并行实例同时跑的时候统计数值乱掉。

这样一来，子类在重写reportThroughput时，基本只需要做一件事：往metrics里填当前节点自己算出来的实际数据，剩下的那些元信息、时间戳、并发保护，统统由基类和指标对象兜底搞定。

上报通道：抽象层统一管，子类别碰网络

上报这件事本身——到底是发到Prometheus Pushgateway、写到本地环形缓冲区、还是推一条MQ消息——不应该让每个子类自己决定。一旦分散，后续改通道、换格式、加审计日志，就会变成一场噩梦。

正确的做法是：

• 抽象基类里持有一个ThroughputReporter接口引用，由依赖注入容器（比如Slickflow的AutoExecutionContext，或者自研调度器）提供。
• 子类在reportThroughput()里只管填充metrics字段，完全不接触网络、I/O或序列化逻辑。
• 基类在调用完子类的reportThroughput()之后，立即把填充好的metrics交给reporter.report(metrics)，由它完成实际的发送动作。

这样就把职责拆得干干净净：子类只管“算指标”，基类负责“触发上报”，上报器负责“发出去”。任何一个环节都不过界。

编译只是第一关，运行时还要兜底

编译阶段强制子类实现reportThroughput，这已经能拦住大多数疏漏。但工业场景下，还得防一种情况：有些节点虽然在代码里把方法签了，但实现体可能是空的，或者直接抛了异常。等到流量打进来才发现问题，那就晚了。

所以引擎启动阶段就必须做两件事：

• 扫描所有已注册的节点类型，通过反射加注解标记的方式，检查每个节点是否真的实现了reportThroughput方法，而不是继承了默认空的实现。
• 在流程实例首次运行之前，对每个节点执行一次空载测试：调reportThroughput(new DummyMetrics())，确保调用不抛异常、不会超时。
• 只要有任何一个节点没通过校验——无论是没实现还是空载调用失败——引擎直接拒绝加载该流程定义，同时写一条ERROR日志并触发告警。

这套机制走下来，吞吐指标的上报就不再是“看开发人员心情”的事了。架构层面已经替你把所有的偷懒路径都堵死了。