search

apache / servicecomb-service-center

A standalone service center to allow services to register their instance information and to discover providers of a given service
Apache License 2.0
1.34k stars 343 forks source link

service-center与etcd集群之间的交互,偶尔会出现,或者获取缓存时间超长 #1147

Closed diwenzheng closed 3 years ago

diwenzheng commented 3 years ago

service-comb微服务测

2021-08-25 08:23:22.473 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.156:30100, message: Connection was closed

2021-08-25 08:23:22.474 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

2021-08-25 08:27:22.474 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [io.vertx.core.net.impl.ConnectionBase] - [ConnectionBase.java:216] - Connection reset by peer

2021-08-25 08:27:22.475 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.47:30100, message: Connection reset by peer

2021-08-25 08:27:22.475 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

2021-08-25 08:27:22.476 - [ERROR] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.client.http.RestUtils] - [RestUtils.java:95] - GET /v4/default/registry/instances?rev=098714c3c29a8fde9ff7f36aa69045799053b65a&appId=redtea-es&global=true&serviceName=Alarm&env=development&version=0.0.0%2B fail, endpoint is 10.0.1.47:30100, message: Connection was closed

2021-08-25 08:27:22.476 - [WARN] - [registry-vert.x-eventloop-thread-0] - [o.a.s.s.c.h.ServiceRegistryClientImpl] - [ServiceRegistryClientImpl.java:110] - invoke service [/v4/default/registry/instances] failed, retry.

diwenzheng commented 3 years ago

注册中心测日志 image

diwenzheng commented 3 years ago

etcd 是一个集群 image

diwenzheng commented 3 years ago

因部署方式是swarm的,etcd采用bitnami/etcd的集群.所以我们在指定注册中心地址的地方指定的是对内的集群VIP,可以理解成有三个注册中心然后外面有个nginx,服务内部配置的是nginx的ip.

diwenzheng commented 3 years ago

服务侧偶现 image 这样的日志.毕竟是个error日志,所以我们还是很关注这块的.

diwenzheng commented 3 years ago

官方好像没有提供关于service-center的分布式部署方案啊,我们是基于起了三个service-center实例,每个实例连接的是一个集群

diwenzheng commented 3 years ago

@tianxiaoliang

tianxiaoliang commented 3 years ago

service center链接etcd，所以只需要把etcd组成集群即可，另外因为通信走的etcdv3，所以发现的时候会自动发现etcd每个member的节点，因此配VIP或者lb是没用的

看下etcd client的源码 有个Sync函数

diwenzheng commented 3 years ago

service center链接etcd，所以只需要把etcd组成集群即可，另外因为通信走的etcdv3，所以发现的时候会自动发现etcd每个member的节点，因此配VIP或者lb是没用的

看下etcd client的源码 有个Sync函数

我们用的是etcd的集群,只不过是swarm部署,网络走的是docker的网络,意思这种方式下对于etcd的连接会不稳定?这种部署形态和k8s差不多.vip的理解是针对于swarm的内置的负载均衡的,service-center我们微服务连接的时候使用也是直接指向service-center的地址的,service-center的yaml是这样的.etcd1,etcd2,etcd3就是三个etcd实例的地址。这是一个集群.如果配置一个etcd的实例,可以发现其他两个member吗?针对k8s或者swarm这种部署形态,有推荐yaml吗 image

diwenzheng commented 3 years ago

针对于微服务的配置是这样的,image,所以前面才在解释VIP的事情.这里配的ip其实是docker的内置域名网络,而这个域名网络对应了三个service-center实例.

tianxiaoliang commented 3 years ago

可以先登录到sc的容器实例中查看下网络连通性，甚至用etcdctl试着operate这些etcd端点。

我们使用k8s部署的，没有走k8ssvc，而是用的hostnetwork这个配置项，全都是主机网络

diwenzheng commented 3 years ago

可以先登录到sc的容器实例中查看下网络连通性，甚至用etcdctl试着operate这些etcd端点。

我们使用k8s部署的，没有走k8ssvc，而是用的hostnetwork这个配置项，全都是主机网络

主动ping网络层正常,etcd的节点信息健康正常.这块在上文忘记说了

tianxiaoliang commented 3 years ago

使用的2.0版本么

diwenzheng commented 3 years ago

最开始我们用的1.3.0,后面我感觉或许版本更新了,所以用的2.0,但是我们的微服务用的1.3.0 改造2.0更换东西太繁琐,所以没有改。

tianxiaoliang commented 3 years ago

我们发布新版本后仅对上一个老版本支撑安全漏送修复，需要你切换到新版本

diwenzheng commented 3 years ago

我们发布新版本后仅对上一个老版本支撑安全漏送修复，需要你切换到新版本

所以 微服务打印warn级别的心跳错误日志,你认为是版本不是最新导致的问题吗.我看文档部分没有说修复这块的啊.

tianxiaoliang commented 3 years ago

关于遇到的网络问题，需要按照etcd官网的cluster指南进行部署，然后每个sc配置1个etcd或全部etcd的端点都可以，另外最好用主机网络

diwenzheng commented 3 years ago

具体原因已经查明,因为yaml配置不当导致的问题.之前我有专门贴出我的yaml配置.好像你们没有仔细看.

原: servicecomb: service: environment: development application: XXX name: mock-server version: 1.1.0 registry: address: ${REGISTRY_ADDRESS} client: timeout: idle: 60 instance: healthCheck: interval: 60 times: 6 pull: interval: 60 watch: true empty: pretection: true autodiscovery: true

现在移除那些idle那些,直接 servicecomb: service: environment: development application: xxx name: xxx version: 1.1.0 registry: instance: watch: true

在没有这样的日志了.哎 太难了,怀疑框架怀疑注册中心,怀疑etcd.就差怀疑人生了- -

@tianxiaoliang

diwenzheng commented 3 years ago

打印这种日志的强迫症终于结束了.

tianxiaoliang commented 3 years ago

打印这种日志的强迫症终于结束了.

这是一次比较好的调试经验，可以总结下，写成博客，自己发布

diwenzheng commented 3 years ago

等我跟liubao讨论后,决定配置的最优解,在总结.目前经过昨天一晚上,只有一次打印这样的日志,相对于以前不停打印,从开发以及维护人员观察日志定位问题方便了很多.

liubao68 commented 3 years ago

你配置的参数太特殊了， 刚好 client idle timeout = server idle timeout = pull interval = 60s 因为HTTP一般被用于短连接，通过连接超时实现复用。 当这3个参数相同的时候， 下一次pull， 获取连接， 可能刚好 server 关闭了连接， client未感知到， 使用这个连接发生请求， 就会出现偶然错误。

默认pull interval 是 30s， 只要请求不超时， 基本可以保证链接可以持续复用， 那么概率会降低很多。 理论上3个值分别为 50s , 60s, 30s ，保证 pull interval < client < server， 那么发生的概率会更小， 复用也最好。

client idle > pull interval = server idle 的情况，问题概率最高。

diwenzheng commented 3 years ago

你配置的参数太特殊了， 刚好 client idle timeout = server idle timeout = pull interval = 60s 因为HTTP一般被用于短连接，通过连接超时实现复用。 当这3个参数相同的时候， 下一次pull， 获取连接， 可能刚好 server 关闭了连接， client未感知到， 使用这个连接发生请求， 就会出现偶然错误。

默认pull interval 是 30s， 只要请求不超时， 基本可以保证链接可以持续复用， 那么概率会降低很多。 理论上3个值分别为 50s , 60s, 30s ，保证 pull interval < client < server， 那么发生的概率会更小， 复用也最好。

client idle > pull interval = server idle 的情况，问题概率最高。

确实是这个问题,仔细看了下源码,再结合配置确认是这个原因导致的.是我修改了这里的interval 为60,当时因为我们发现在每秒2000TPS的压力下,发现注册中心会主动让我们的实例下线.所以修改成60,重试次数是6次.但忽略了上面的问题.所以导致了没必要的日志打印