其它
【原创】nacos整合dubbo踩坑清单
作者: whooyun发表于: 2024-06-12 21:32
整合Nacos 2.3与Dubbo 3时，需要注意以下几个关键点来确保两者能够顺畅协同工作：
1. **版本兼容性**：
- 确认Nacos和Dubbo的版本兼容性。虽然没有直接提及Nacos 2.3与Dubbo 3的具体兼容性报告，但基于历史实践，Dubbo 3系列一般能够与Nacos 2.x系列良好集成。你应参考官方文档或社区讨论确认最佳搭配版本。
当前推荐版本：nacos 2.2.3（官方稳定版），dubbo3.2.13（官方稳定版），当前版本整合后可有效减少服务生产者的no provider问题，应用状态假死问题发生的概率
2. **配置更新**：
- 更新或验证你的Dubbo配置，确保服务注册与发现指向Nacos 2.3的服务地址。这通常在Dubbo的配置文件（如`dubbo.properties`或通过Spring Boot的yaml配置）中完成。
建议nacos做成至少3节点集群，并通过自定义健康检查，监控nacos集群的可用性，业务应用的可用性，服务生产者对应接口的可用性，比如nginx+lua脚本监控nacos集群状态
nacos+钉钉或者企业微信监控业务应用状态，通过py脚本监控关键接口的可用性
3. **服务元数据同步**：
- 注意Dubbo服务实例的元数据同步问题。在Nacos 2.3中下线服务实例后，确认Dubbo消费者的本地缓存刷新策略，以避免因缓存未及时更新导致的调用问题。可能需要调整Dubbo的配置来优化服务实例缓存的刷新频率。
建议不使用本地缓存刷新策略，而是使用remote模式，因为本地缓存刷新可能会有延时或者服务异常问题
4. **应用服务监控**：
- 利用微服务调用链监控，监控所有服务接口的调用链及异常，有利于迅速排查，定位dubbo服务的不稳定性问题
以下坑已踩过：
1.nacos，dubbo版本兼容问题，导致服务消费者经常出现无法调用到服务生产者的no provider异常，或服务不可用异常，服务越多，稳定性越差
2.使用本地缓存刷新机制，缓存刷新不及时，出现no provider异常，在nacos上业务应用处于在线状态，但是仍然无法调用到
3.元数据不同步或者未及时刷新，可尝试删除所有的元数据，重新启动所有的服务，一般重新清理，重启服务后基本上都能恢复正常
4.jdk9及以上版本，由于模块化特性的变更，导致了dubbo3（java.base/java.lang），nacos2.3（安全特性兼容性问题） 出现各种包无法调用的情况，业务应用需要反复手动配置vm参数，极端浪费时间
java.lang.UnsupportedOperationException: Reflective setAccessible(true) disabled； java.lang.IllegalAccessException: class io.netty.util.internal.PlatformDependent0$6 cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @60438a68；
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Dio.netty.tryReflectionSetAccessible=true
5.业务服务应用超过40个，由于多节点问题，导致排查问题在20多台机器轮番查找异常日志，严重影响排查速度及生产的恢复
1. **版本兼容性**：
- 确认Nacos和Dubbo的版本兼容性。虽然没有直接提及Nacos 2.3与Dubbo 3的具体兼容性报告，但基于历史实践，Dubbo 3系列一般能够与Nacos 2.x系列良好集成。你应参考官方文档或社区讨论确认最佳搭配版本。
当前推荐版本：nacos 2.2.3（官方稳定版），dubbo3.2.13（官方稳定版），当前版本整合后可有效减少服务生产者的no provider问题，应用状态假死问题发生的概率
2. **配置更新**：
- 更新或验证你的Dubbo配置，确保服务注册与发现指向Nacos 2.3的服务地址。这通常在Dubbo的配置文件（如`dubbo.properties`或通过Spring Boot的yaml配置）中完成。
建议nacos做成至少3节点集群，并通过自定义健康检查，监控nacos集群的可用性，业务应用的可用性，服务生产者对应接口的可用性，比如nginx+lua脚本监控nacos集群状态
nacos+钉钉或者企业微信监控业务应用状态，通过py脚本监控关键接口的可用性
3. **服务元数据同步**：
- 注意Dubbo服务实例的元数据同步问题。在Nacos 2.3中下线服务实例后，确认Dubbo消费者的本地缓存刷新策略，以避免因缓存未及时更新导致的调用问题。可能需要调整Dubbo的配置来优化服务实例缓存的刷新频率。
建议不使用本地缓存刷新策略，而是使用remote模式，因为本地缓存刷新可能会有延时或者服务异常问题
4. **应用服务监控**：
- 利用微服务调用链监控，监控所有服务接口的调用链及异常，有利于迅速排查，定位dubbo服务的不稳定性问题
以下坑已踩过：
1.nacos，dubbo版本兼容问题，导致服务消费者经常出现无法调用到服务生产者的no provider异常，或服务不可用异常，服务越多，稳定性越差
2.使用本地缓存刷新机制，缓存刷新不及时，出现no provider异常，在nacos上业务应用处于在线状态，但是仍然无法调用到
3.元数据不同步或者未及时刷新，可尝试删除所有的元数据，重新启动所有的服务，一般重新清理，重启服务后基本上都能恢复正常
4.jdk9及以上版本，由于模块化特性的变更，导致了dubbo3（java.base/java.lang），nacos2.3（安全特性兼容性问题） 出现各种包无法调用的情况，业务应用需要反复手动配置vm参数，极端浪费时间
java.lang.UnsupportedOperationException: Reflective setAccessible(true) disabled； java.lang.IllegalAccessException: class io.netty.util.internal.PlatformDependent0$6 cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @60438a68；
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Dio.netty.tryReflectionSetAccessible=true
5.业务服务应用超过40个，由于多节点问题，导致排查问题在20多台机器轮番查找异常日志，严重影响排查速度及生产的恢复