服务发现：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提供的解决方案更好，它的设计考虑了服务架构和发现，它很简单，但功能强大，提供了一个完整的解决方案，而且不会牺牲简单性，在许多情况下，它是服务发现和健康检查需求的最佳工具。
更多的工具组合意味着工具复杂度以及技术维护成本的提升，在技术可靠性前提下，积极拥抱变化，降低工具复杂度，以便完成更好的微服务建设。