有了服务注册和发现机制，消费者不需要知道具体服务提供者的真实物理地址就可以进行调用，也无须知道具体有多少个服务者可用；而服务提供者只需要注册到注册中心，就可以对外提供服务，在对外服务时不需要知道具体是哪些服务调用了自己。,这里分析go-zero 的etcd 部分源码, 源码引用https://github.com/zeromicro/go-zero-demo/tree/master/mall,1.png,cluster.getClient 拿到etcd 连接,cluster.load 作为第一次载入数据,cluster.watch 去watch 监听etcd 前缀key 的改动,2.png,为什么不用Redis 做注册中心(反正只是把被调方的地址存储, 过期Redis 也能胜任), 找了很久找到这个说法,简单从以下几个方面说一下瑞迪斯为啥在微服务中不能取代 etcd：,1、redis 没有版本的概念，历史版本数据在大规模微服务中非常有必要，对于状态回滚和故障排查，甚至定锅都很重要,2、redis 的注册和发现目前只能通过 pub 和 sub 来实现，这两个命令完全不能满足生产环境的要求，具体原因可以 gg 或看源码实现,3、etcd 在 2.+版本时，watch 到数据官方文档均建议再 get 一次，因为会存在数据延迟，3.+版本不再需要，可想 redis 的 pub 和 sub 能否达到此种低延迟的要求,4、楼主看到的微服务架构应该都是将 etcd 直接暴露给 client 和 server 的，etcd 的性能摆在那，能够承受多少的 c/s 直连呢，更好的做法应该是对 etcd 做一层保护，当然这种做法会损失一些功能,5、redis 和 etcd 的集群实现方案是不一致的，etcd 采用的是 raft 协议，一主多从，只能写主，底层采用 boltdb 作为 k/v 存储，直接落盘,6、redis 的持久化方案有 aof 和 rdb，这两种方案在宕机的时候都或多或少的会丢失数据,引用自https://www.v2ex.com/t/520367
© 版权声明
文章版权归作者所有，未经允许请勿转载。
