解决Spring Cloud Alibaba/Spring Cloud整合Zipkin后的报错问题

TIPS

•本文服务发现组件以Nacos为例。

•本文基于 Spring Cloud Greenwich SR1

问题复现

依赖

<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

配置

spring:
 zipkin:
 base-url: http://localhost:9411/
 sleuth:
 sampler:
 probability: 1.0

结果

只要你的API被调用，应用就会疯狂报相似以下的异常。

2019-08-24 23:10:25.330 ERROR [user-center,,,] 48628 --- [.naming.updater] com.alibaba.nacos.client.naming : [NA] failed to update serviceName: DEFAULT_GROUP@@localhost
java.lang.IllegalStateException: failed to req API:/nacos/v1/ns/instance/list after all servers([localhost:8848]) tried: failed to req API:http://localhost:8848/nacos/v1/ns/instance/list. code:404 msg: service not found: DEFAULT_GROUP@@localhost
 at com.alibaba.nacos.client.naming.net.NamingProxy.reqAPI(NamingProxy.java:380) ~[nacos-client-1.0.0.jar:na]
 at com.alibaba.nacos.client.naming.net.NamingProxy.reqAPI(NamingProxy.java:304) ~[nacos-client-1.0.0.jar:na]
 at com.alibaba.nacos.client.naming.net.NamingProxy.queryList(NamingProxy.java:217) ~[nacos-client-1.0.0.jar:na]
 at com.alibaba.nacos.client.naming.core.HostReactor.updateServiceNow(HostReactor.java:273) ~[nacos-client-1.0.0.jar:na]
 at com.alibaba.nacos.client.naming.core.HostReactor$UpdateTask.run(HostReactor.java:318) [nacos-client-1.0.0.jar:na]
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_201]
 at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) [na:1.8.0_201]
 at java.util.concurrent.FutureTask.run(FutureTask.java) [na:1.8.0_201]
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_201]
 at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_201]
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_201]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_201]
 at java.lang.Thread.run(Thread.java:748) [na:1.8.0_201]

缘由：

Spring Cloud把 http://localhost:9411/ 看成了服务发现组件里面的服务名称；因而，Nacos Client尝试从Nacos Server寻找一个名为 localhost:9411 的服务…这个服务根本不存在啊，因而就疯狂报异常（由于Nacos Client本地定时任务，刷新本地服务发现缓存）

解决方案

知道缘由以后，要想解决很简单：

•让Spring Cloud 正确识别http://localhost:9411/ ，当成一个URL，而不要当作服务名。

•把Zipkin Server注册到Nacos

谈谈Zipkin Server注册到服务发现组件

Zipkin Server 官方并不支持注册到服务发现组件！！！！在 https://github.com/openzipkin/zipkin/issues/2540 里面，官方人员解答得很清楚了：

@nkorange[1] thank you for reaching out. We have had several users ask about service discovery with Zipkin Server over the years (see #1870[2]) and less ask about dynamic/external configuration. We don't currently support any service discovery as a first-class feature. There is a workaround to use Eureka mentioned in #1870[3]. So unless a user is using that, or is building a custom Zipkin Server (which we don't officially support), there should be no service discovery.

If you want to come chat with us on Gitter (https://gitter.im/openzipkin/zipkin[4]) about next steps, please do.

详见 We don't currently support any service discovery as a first-class feature.

若是你想要注册到服务发现组件，那么能够参考 https://github.com/openzipkin/zipkin/issues/1870 说明本身改造Zipkin Server让其注册到服务发现组件，但这样作不会获得任何官方的技术支持！！

因此，将Zipkin Server注册到Nacos或者其余服务发现组件，不是最优解。咱们的解决方案就演变成了：让Spring Cloud 正确识别 http://localhost:9411/ ，当成一个URL，而不要当作服务名。这一种解决方案。

配置走你！

spring:
 zipkin:
 base-url: http://localhost:9411/
 discovery-client-enabled: false

从这个配置的注释（ 代码见 org.springframework.cloud.sleuth.zipkin2.ZipkinProperties#discoveryClientEnabled ）来看，只要设置成false，那么就会把 http://localhost:9411/ 当成一个URL，而不是服务名称了。

你觉得已经牛逼了，然而当你去测试的时候，发现 然并卵 ，一点效果都没有。

Spring Cloud Sleuth Bug、解决方案与Pull Request

问题代码在这里：org.springframework.cloud.sleuth.zipkin2.sender.ZipkinRestTemplateSenderConfiguration.DiscoveryClientZipkinUrlExtractorConfiguration.ZipkinClientNoOpConfiguration ，里面是这么玩的：

@Configuration
@ConditionalOnProperty(value = "spring.zipkin.discoveryClientEnabled", havingValue = "false")
static class ZipkinClientNoOpConfiguration {
 ...
}

当你看到这个代码的时候，就应该知道解决方案啦！那就是你得把配置修改成：

spring:
 zipkin:
 base-url: http://localhost:9411/
 discoveryClientEnabled: false

就能够了！

这实际上是Spring Cloud Sleuth子项目 spring-cloud-sleuth-zipkin 的一个Bug！

•相关的Issue在：https://github.com/spring-cloud/spring-cloud-sleuth/issues/1376

•解决的Pul Request在：https://github.com/spring-cloud/spring-cloud-sleuth/pull/1379 ，代码已经合并了，在 Spring Cloud Greenwich SR3 版本中会修正！

简单总结一下：

•若是你使用的是Greenwich SR3以前的版本，务必使用 spring.zipkin.discoveryClientEnabled = false ，不然配置不生效！！

•若是你使用的是Greenwich SR3及更高版本，可以使用 discovery-client-enabled 或者 discoveryClientEnabled 。

为何Zipkin Server不支持服务发现，Spring Cloud还弄个服务发现的配置？

我暂时没有找到Spring Cloud这样作的意图。个人猜测：是由于早期Spring Cloud是使用本身编写代码实现Zipkin Server的（从Finchley开始，改为了直接用Zipkin官方现成的jar包启动），这种方式能够注册到你想要的服务发现组件上（由于本质上，Zipkin Server就是个基于Spring Boot的应用嘛）。

一点吐槽

我的以为Spring Cloud这部分的设计不太优雅，若是让我来设计的话，我应该会这么设计：

URL模式：

spring:
 zipkin:
 base-url: http://localhost:9411/

服务名称的模式：

spring:
 zipkin:
 base-url: lb://zipkin-server/

这样带来的好处：

•scheme（http:// 、 lb:// ）就能够区分出是具体URL仍是微服务名称了，无需配置 discoveryClientEnabled

•lb:// 协议和Spring Cloud Gateway造成了呼应，学习成本也比较低，使用体验更加一致

不过工做比较忙，只有创意，暂时没有时间提交PR…哈哈，因此…吐槽完仍是得继续忍着啊…

---

福利分享

关注后私信便可免费得到Java技术资料