服务发现:Zookeeper vs etcd vs Consul
在微服务中,我们拥有的服务越多,如果我们使用预定义的端口,就会发生冲突的可能性越大。
管理一百个服务所使用的所有端口的紧密列表本身就是一项挑战。出于这个原因,我们应该在不指定端口的情况下部署服务,并让Docker为我们分配一个随机服务。
1. 服务注册与发现
1.1. 涉及问题
- 需要发现端口号并让其他服务了解它
- 服务的自动扩展,以及服务器故障的自动恢复
- 服务机器资源IP添加到需要在某处发现和存储的数据列表
1.2. 其他思考问题
- 如果服务停止工作并部署/注册新实例,我们是否应取消注册该服务?
- 当有多个同一服务的副本时会发生什么?我们如何平衡它们之间的负载?
- 如果服务器出现故障会怎样?
1.3. 服务发现
- 服务发现工具:主要目标是帮助服务找到并相互通信,为了履行职责,他们需要知道每项服务的位置;发现工具倾向于提供某种API,服务可以使用它来注册自己以及其他人查找有关该服务的信息。
- 服务发现思想:服务(或应用程序)的每个新实例能够识别其当前环境并存储该信息(通常存储在KV的分布式系统中),存储的主要用途是至少向可能需要与之通信的所有相关方(服务消费者)提供服务的IP和端口。
1.4. 大致流程
为了能够找到我们的服务,我们至少需要以下两个流程供我们使用:
- 服务注册过程,将正在运行的主机和端口服务存储起来 (服务提供者 <=> 服务注册服务 <=> 服务发现注册表)
- 服务发现过程,允许其他服务能够发现我们在注册过程中存储的信息 (服务消费者 <=> 服务发现服务 <=> 服务发现注册表)
2. 工具比较
2.1. ZooKeeper
源于Hadoop世界,稳定但复杂,Java系,功能丰富性将自身从优势转化为负债的部分。
2.2. Etcd
Etcd仅仅是分布式可靠键值存储,用于分布式系统的最关键数据。etcd是可通过HTTP访问的键/值存储,文档,安全,但是,它需要与少数第三方工具结合才能提供服务发现目标。
配套解决方案:Registrator+etcd+confd
,弊端:3个组合工具引入,在服务器资源上引入不必要的复杂性和开销。
- Registrator,通过检查容器在线或停止时自动注册和取消注册服务(Docker的服务注册表桥,带有可插拔适配器),支持etcd,Consul
- confd是一个轻量级的配置管理工具。常见用法是使用存储在etcd,consul和少数其他数据注册表中的数据使配置文件保持最新。它还可用于在配置文件更改时重新加载应用程序。
- etcd充当远程服务发现KV注册表
2.3. Consul
Consul是一个强大的一致数据存储区,它使用gossip
来形成动态集群。
配套解决方案: Registrator+Consul+consul-template
- Consul具有分层键/值存储,与Zookeeper和etcd不同,Consul实现嵌入式服务发现系统,不仅可用于发现有关已部署服务及其所在节点的信息,还可通过HTTP请求,TTL(生存时间)和自定义命令轻松扩展运行状况检查。
在许多情况下,Consul与我们探索的工具一起比etcd提供的解决方案更好。它的设计考虑了服务架构和发现。它很简单,但功能强大。它提供了一个完整的解决方案,而且不会牺牲简单性,在许多情况下,它是服务发现和健康检查需求的最佳工具。
2.4. Envory
Istio + Envory是针对微服务解决方案另外最新的一组大杀器。
3. 小结
在许多情况下,Consul比etcd提供的解决方案更好,它的设计考虑了服务架构和发现,它很简单,但功能强大,提供了一个完整的解决方案,而且不会牺牲简单性,在许多情况下,它是服务发现和健康检查需求的最佳工具。
更多的工具组合意味着工具复杂度以及技术维护成本的提升,在技术可靠性前提下,积极拥抱变化,降低工具复杂度,以便完成更好的微服务建设。