LightESB Timer发布：服务级日志与响应编码增强

LightESB Timer ：从定时触发到服务级日志

在集成场景中，很多任务不依赖外部请求，而是依赖"按时间触发"：状态巡检、缓存刷新、批量处理、心跳探活。

LightESB 基于 Apache Camel 的 timer 组件，可以非常轻量地实现这一类任务，并且结合服务级日志能力实现可观测化。

本文基于仓库中的 timer 示例（v1.0.0 与 v1.0.1）说明：

• 如何定义稳定的定时路由
• 如何输出结构化状态信息
• 如何接入服务级日志与动态调级
• 如何做版本化演进

1. 为什么在 LightESB 里用 Timer

timer 组件是 Camel 最基础、也最稳定的触发器之一。对于 LightESB 来说，它有三个直接价值：

1. 去中心化调度：路由本身携带周期配置，不需要额外调度系统即可运行。
2. 便于版本化 ：可以按服务目录（如 timer/v1.0.0、timer/v1.0.1）独立迭代。
3. 天然可观测 ：结合 log / servicelog，可以快速确认路由是否存活、执行是否成功。

2. v1.0.0：最小可用定时路由

timer-test-routes.xml（v1.0.0）里给出了两个基础模式：

• 固定周期状态输出：每 10 秒输出一条运行日志
• 结构化状态检查：每 15 秒输出带时间戳的 JSON 状态

示例核心配置如下：

<route id="independent-timer-test-v1.0.0">
    <from uri="timer:independentTest?period=10000"/>
    <setBody>
        <constant>📊 独立CamelContext测试路由运行正常 - timer-test-routes.xml</constant>
    </setBody>
    <to uri="log:independent-context?level=INFO"/>
</route>

<route id="independent-status-check-v1.0.0">
    <from uri="timer:statusCheck?period=15000"/>
    <setBody>
        <simple>{"file": "timer-test-routes.xml", "status": "ACTIVE", "timestamp": "${date:now:yyyy-MM-dd HH:mm:ss}"}</simple>
    </setBody>
    <log message="📈 独立Context状态检查: ${body}"/>
</route>

这套模式适合做"活性证明"（liveness proof）：只要日志按周期稳定出现，说明路由线程和上下文都在正常运行。

3. v1.0.1：引入服务级日志与处理链

v1.0.1 在基础定时能力上做了两类增强：

3.1 服务级日志（servicelog）

除了标准 <log>，还增加了：

• servicelog:info?message=...
• servicelog:debug?message=...
• showBody=true 与 maxBodyLength=200 等输出控制参数

这让日志不再只是"文本打印"，而是可按服务维度聚合、分级、动态调节（例如调到 DEBUG 做短时排障）。

3.2 增加处理器链路

independent-status-check 路由里新增：

<process ref="jsonResponseProcessor"/>

这一步说明 Timer 路由不只是"打日志"，也可以接入标准处理器链，统一响应编码与内容格式，便于后续对接 HTTP/存储/告警链路。

4. 实际运行现象（基于示例日志）

从 lightesb-camel-app/timer/v1.0.1/logs/timer-test-routes.log 可以看到：

• independent-status-check 会先记录"状态检查开始"
• 随后输出包含 file/status/timestamp/version 的状态消息体
• timer-data-processing 会周期性输出 processId 与 timestamp

这类日志格式非常适合用于：

• 健康巡检看板
• 任务执行审计
• 异常时段回放与定位

5. 参数与设计建议

5.1 周期参数建议

• period=5000：快速验证 / 联调阶段
• period=30000：一般业务心跳或轻量巡检
• period=1500000：低频状态汇总（示例中的 25 分钟）

建议从"业务最小可接受时延"倒推周期，不要盲目设为高频。

5.2 路由命名建议

• route id 建议包含服务语义与版本信息（如 timer-data-processing、independent-status-check-v1.0.0）
• 消息体建议最少包含：status、timestamp、version、source/file

5.3 可观测建议

• 同时保留 servicelog 与 <log> 一段时间，便于迁移期对比
• 为关键路由保留"开始日志 + 完成日志 + 异常日志"三段式
• 对日志体长度进行限制（如 maxBodyLength），避免噪声和性能抖动

6. 什么时候用 / 不用 Timer

适合：

• 固定周期任务（巡检、同步、清理、汇总）
• 对触发精度要求"秒级以内可接受"的任务
• 希望把调度能力直接内嵌在路由配置中的场景

不适合：

• 强一致、严格对时（如金融撮合级）调度
• 需要复杂依赖编排（任务 DAG、回填重试矩阵）的任务
• 必须由统一外部调度平台托管的任务

7. 小结

LightESB 的 Timer 路由可以从"最小可用"快速起步，再逐步演进到"可观测、可调试、可治理"的生产形态。
v1.0.0 证明了定时触发与状态输出；v1.0.1 进一步展示了服务级日志与处理器链路的接入方式。

Links

• GitHub: lightesb-camel

If this deep dive is helpful, please star the project and share your timer patterns.