常见服务注册中心

名称	优点	缺点	接入	算法
zookeeper	1.功能强大，不仅仅只是服务发现。2.提供watcher机制能实时获取服务提供者的状态。3.dubbo等框架支持	1.没有健康检查2.需在服务中集成sdk，复杂度高3.不支持多数据中心。	sdk	Paxos
consul	1.简单易用，不需要集成sdk。2.自带健康检查。3.支持多数据中心。4.提供web管理界面	1.不能实时获取服务信息的变化通知。	http/dns	Raft
etcd	1.简单易用，不需要集成sdk。2.可配置性强。	1.没有健康检查。2.需配合第三方工具一起完成服务发现。3.不支持多数据中心。	http	Raft

• Etcd：是一个采用http协议的分布式键值对存储系统。如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。比如 etcd、Registrator、confd组合，但这就稍微麻烦点了，尤其相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。
• Consul：相较于etcd、zookeeper，consul ：它整合了服务发现普遍的需求，开箱即用，不需要任何第三方的工具。代码实现上也足够简单。
  • 通过DNS或HTTP，应用能轻易地找到它们依赖的系统。
  • 提供了多种健康检查方式：http返回码200，内存是否超限，tcp连接是否成功。
  • kv存储，并提供http api
  • 多数据中心，这点是zookeeper所不具备的。
  • 不需要专门的sdk集成到服务中，不限制语言。

我们看看consul一般是怎么使用的。

• 每台服务器上都要安装一个consul agent。
• consul agent支持通过配置文件注册服务，或者在服务中通过http接口来注册服务。
• 注册服务后，consul agent通过指定的健康检查方式，定期检查服务是否存活。
• 如果服务想查询其他服务的存活状态，只需要与本机的consul agent发起一次http请求或者dns请求即可。
• 简单点说，consul的使用不依赖任何sdk，依靠简单的http请求就能满足服务发现的所有逻辑。
• 不过，服务每次都从consul agent获取其他服务的存活状态，相比于zookeeper的watcher机制，实时性稍差一点，需考虑如何尽可能提高实时性，问题不会很大。
• watch：https://juejin.cn/post/6984378158347157512

为了以后支持多数据中心，同时为了快速支持不同的语言比如nodejs、python服务，我会选择consul作为我们的服务发现框架，但是实时获取服务信息变化通知的问题需尽可能减小。

两个 rust consul 库

• https://github.com/Roblox/rs-consul。支持 watch
• https://github.com/pierresouchay/consul-rust。下载量较多。

Envoy

• Envoy 由C++ 实现，是一个代理，当然它也有一套服务注册/发现机制，一般是作为“服务网格”方案的一个流量代理组件，单独当作服务注册中心来用，就有些太过复杂了。

https://cloud.tencent.com/developer/article/1683457