【etcd】解决 go-zero 注册 etcd 出现 “Auto sync endpoints failed.” 的问题

go: v1.20.3

go-zero: v1.5.4

etcd: v3.5.9


问题描述

在 go-zero 中用 etcd 去实现服务注册发现,rpc 服务可以注册到 etcd,同时其他服务可以发现注册的微服务,也可以访问。但是,注册的 rpc 服务的日志,就是一直报以下错误。日志一直在刷 Auto sync endpoints failed 的问题,服务也可以访问,就很诡异。

{"level":"warn","ts":"2023-07-30T15:57:02.004+0800","logger":"etcd-client","caller":"[email protected]/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0007281c0/192.168.2.2:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 0.0.0.0:2379: connect: connection refused\""}
{"level":"info","ts":"2023-07-30T15:57:02.004+0800","logger":"etcd-client","caller":"[email protected]/client.go:210","msg":"Auto sync endpoints failed.","error":"context deadline exceeded"}

如果是老手,看到这里 ,应该知道问题会出在哪里。我是菜鸟,就只好一步步分析。

如果想直接看解决方法的,到最后,下面是我的分析过程。


排查

当出现问题的时候,想的就是包的问题,不是我的问题。就去 trace go-zero 的源码,也就是 etcd 注册的那个地方。

把 go-zero,封装 etcd 的源码看了好几遍,也没发现有问题,都是正常的注册与发现。(注意:这时候我 go-zero 版本还是 v1.3.2)

没什么问题,以为是 go-zero 版本太旧了,升级一下。因为看 issue 说 etcd 版本也有可能太旧。

验证一

把 go-zero 版本升级到 v1.5.4(中间是先到v1.4.4),把 etcd 升级到 v3.5.9(中间是先到v3.5.7),发现并没有成功,还是会出现 Auto sync endpoints failed


想想 go-zero 应该也不至于会出这个问题,会不会是我 etcd 启动的问题?我是用 docker 启动的 etcd,因为是在测试,就用单点。这边对配置的 IP 其实没有概念,也不知道都是干嘛的。

docker run -d --name ai-etcd --network=host --restart always \
 -v $PWD/etcd.conf.yml:/opt/bitnami/etcd/conf/etcd.conf.yml \
 -e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
 -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
 -e ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380 \
 -e ETCD_INITIAL_ADVERTISE_PEER_URLS=http://0.0.0.0:2380 \
 -e ALLOW_NONE_AUTHENTICATION=yes \
 bitnami/etcd:3.5.9

这个 docker 的启动方式,也是往上找的,没问题呀。启动也 ok,go-zero 也注册得上去。

再看看 etcd 到底哪里出的问题,又去看了下源码。

// client.go L196
func (c *Client) autoSync() {
	if c.cfg.AutoSyncInterval == time.Duration(0) {
		return
	}

	for {
		select {
		case <-c.ctx.Done():
			return
		case <-time.After(c.cfg.AutoSyncInterval):
			ctx, cancel := context.WithTimeout(c.ctx, 5*time.Second)
			err := c.Sync(ctx)
			cancel()
			if err != nil && err != c.ctx.Err() {
				c.lg.Info("Auto sync endpoints failed.", zap.Error(err))
			}
		}
	}
}

// Sync synchronizes client's endpoints with the known endpoints from the etcd membership.
func (c *Client) Sync(ctx context.Context) error {
	mresp, err := c.MemberList(ctx)
	if err != nil {
		return err
	}
	var eps []string
	for _, m := range mresp.Members {
		...
	}
	c.SetEndpoints(eps...)
	return nil
}

上面这个方法报错,因为 Auto sync endpoints failed 是一直出现的,说明 go-zero 里面有个地方,应该也配置了 AutoSyncInterval ,所以这边会跑这个。下面是,go-zero 调用的地方,其实也就是初始化一个etcd client的传参。

// registry.go L337
// DialClient dials an etcd cluster with given endpoints.
func DialClient(endpoints []string) (EtcdClient, error) {
	cfg := clientv3.Config{
		Endpoints:            endpoints,
		AutoSyncInterval:     autoSyncInterval,
		DialTimeout:          DialTimeout,
		DialKeepAliveTime:    dialKeepAliveTime,
		DialKeepAliveTimeout: DialTimeout,
		RejectOldCluster:     true,
		PermitWithoutStream:  true,
	}
	...
}

此时此刻很无奈,感觉不知道往哪里思考。服务也没报错,也能调用,就又很不想去分析。这种问题就很折磨,关键日志很多,很丑。还是多找找吧,去看 go-zero 的 issue,看到也有人提这个问题,不过都没有什么解决方案。去看 etcd 的 issue,也没有看到什么。最后也不知道怎么地,想为什么要一直带着 go-zero 去想这个问题,我自己写一个 etcd client 试一下不就行了。找了个范例,测一下,不就知道是 go-zero 的问题,还是 etcd 起的有问题。

范例我就不详细列了,可以去看我的另一篇 【etcd】docker 启动单点 etcd_非晓为骁的博客-CSDN博客 的文章。

cli, err = clientv3.New(clientv3.Config{
	Endpoints:        []string{"192.168.2.2:2379"},
	DialTimeout:      time.Second * 5,
	AutoSyncInterval: time.Second * 5,
})

同样也设置了 AutoSyncInterval,结果难受香菇,竟然也会报这个错误

这里有一个很重要的点,不要出了问题就局限在你用的框架里面,更要会抽丝剥茧,简单地看问题。


这时候说明 etcd 部的就是有问题的,只好再看下 docker run 的指令和错误。我把错误,减少到下面这一行,仔细看下,可以看到是服务 dial 0.0.0.0:2379 失败。rpc 服务和 etcd 是在 2 台服务器,访问本地 2379 就是访问容器内 2379,那肯定访问不到呀。关键是 0.0.0.0:2379 拿来的呢?

"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 0.0.0.0:2379: connect: connection refused\""

rpc 的配置,配的是 etcd 的 host,肯定不是 0.0.0.0:2379。那说明是 etcd 服务自身返回回来的。这时候,只好去分析 docker run 里面的 url。4 个,有 2 个是 2380,说明不是我要关注的,剩下 2 个应该就是问题本身。另外 2 个 2380,看起来是 cluster 相关的,所以也可以直接忽略。

  • -e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
  • -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \

看了下注释:

  • ETCD_LISTEN_CLIENT_URLS :List of comma separated URLs to listen on for client traffic.
  • ETCD_ADVERTISE_CLIENT_URLS:List of this member’s peer URLs to advertise to the rest of the cluster. The URLs needed to be a comma-separated list.

我理解的是 ETCD_LISTEN_CLIENT_URLS 是监听的 IP:PORT,谁可以访问这个服务,类似我们其他服务用的 bind,所以这个用 0.0.0.0 应该没问题。ETCD_ADVERTISE_CLIENT_URLS 这看起来是要通知别人要访问这个 IP:PORT 才可以访问到我,看起来好像是这个的问题。改成我的服务器 IP 试试。

验证二
docker run -d --name ai-etcd --network=host --restart always \
 -v $PWD/etcd.conf.yml:/opt/bitnami/etcd/conf/etcd.conf.yml \
 -e ETCD_ADVERTISE_CLIENT_URLS=http://192.168.2.2:2379 \
 -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
 -e ALLOW_NONE_AUTHENTICATION=yes \
 bitnami/etcd:3.5.9

emmm,这样子在用我 etcd 的范例测试一下,果真没有报错了。为自己的愚蠢感到深深的无语,还一直以为是 go-zero 的问题,其实跟 go-zero 一点关系都没有。


总结

这个问题,出现了很久从 v1.3.2 开始就有。但一直分析不出来就搁置,而且不影响使用。最后还是洁癖,看不惯,分析这个问题。一开始就先入为主地看是 go-zero 的问题,去看 issue,去百度,google,但都带上了 go-zero。其实就不是它的问题,自己的分析能力还是不够。etcd 这边 docker 启动的方式,大部分都是一样的,启动起来好像也没啥问题,也不会往那边去想。

这个问题深层次原因,应该还是对 etcd 不了解,里面的一些 url 不了解。而且,需要多去尝试,用最小单元去做测试,这样才可以事半功倍。

解决方案

etcd docker run 的 ETCD_ADVERTISE_CLIENT_URLS 要改成服务器 IP,然后 rpc 服务重新注册。


这个是我自己分析的过程及理解,可能这里面还有更深层次的问题,有懂的大佬可以分享一下。

你可能感兴趣的:(etcd,etcd,golang,go-zero,服务注册发现,etcd-client)