Apache Dubbo 3.3.2 中 observability starter 导致 Actuator 端点失效问题分析

问题背景

在 Apache Dubbo 3.3.2 版本中，当开发者引入 dubbo-observability-spring-boot-starter 依赖后，Spring Boot Actuator 的默认端点（如 /info 和 /health）会突然变得不可访问。这是一个典型的 Spring Boot 自动配置与 Dubbo 集成时出现的兼容性问题。

现象描述

引入 observability starter 后，访问 /actuator 端点仅返回 Dubbo 相关的端点信息，而 Spring Boot 默认提供的其他监控端点全部消失。具体表现为：

1. /actuator/info 端点无法访问
2. /actuator/health 端点无法访问
3. 其他标准监控端点同样不可用

问题根源

这个问题源于 Spring Boot Actuator 的端点管理机制。在 Spring Boot 2.x 版本中，Actuator 端点默认采用"选择性暴露"策略。当引入 dubbo-observability-spring-boot-starter 时，该 starter 会覆盖 Spring Boot 默认的端点暴露配置。

深入分析发现，Dubbo 的 observability starter 在自动配置过程中，没有正确处理与 Spring Boot Actuator 默认端点的兼容性，导致默认端点被意外禁用。

解决方案

针对这个问题，社区提供了两种解决方案：

方案一：显式启用所有端点

在 application.properties 或 application.yml 中添加以下配置：

management.endpoints.enabled-by-default=true

这个配置会强制启用所有 Actuator 端点，包括 Dubbo 自定义端点和 Spring Boot 默认端点。

方案二：选择性启用特定端点

如果只需要部分端点，可以单独配置：

management.endpoint.info.enabled=true
management.endpoint.health.enabled=true

技术原理

Spring Boot Actuator 的端点管理遵循以下原则：

1. 默认情况下，端点是否启用由 management.endpoints.enabled-by-default 控制
2. 每个端点可以通过 management.endpoint.<name>.enabled 单独配置
3. 当引入第三方 starter 时，如果该 starter 修改了默认配置，可能会影响原有端点的行为

Dubbo observability starter 在实现时，为了确保其自定义端点能够正常工作，可能无意中覆盖了 Spring Boot 的默认配置。这种行为在 Spring Boot 生态中并不罕见，许多第三方 starter 都会面临类似的集成挑战。

最佳实践

为了避免类似问题，建议开发者在集成 Dubbo observability 时：

1. 明确了解项目中需要的 Actuator 端点
2. 在引入新 starter 后，及时检查 Actuator 端点是否按预期工作
3. 在生产环境中，建议显式配置需要暴露的端点，而不是依赖默认行为
4. 定期关注 Dubbo 和 Spring Boot 的版本更新，及时获取兼容性修复

总结

Dubbo 作为一款优秀的 RPC 框架，在与 Spring Boot 生态集成时，偶尔会出现类似的配置冲突问题。理解 Spring Boot 的自动配置原理和 Actuator 的工作机制，能够帮助开发者快速定位和解决这类集成问题。通过合理的配置管理，可以确保 Dubbo 的监控能力与 Spring Boot 的运维端点和谐共存。