转： 六个问题带你了解服务发现
转自： http://dockone.io/article/509
六个问题带你了解服务发现
【编者的话】四位专家解答了有关服务发现的六个问题：（1）什么是服务发现？（2）服务发现包括哪些关键特性，为什么？（3）服务发现带来的主要好处是什么？（4）哪一种服务发现方案是最可靠的？（5）实施服务发现面临的最大挑战是什么？（6）已有的系统如何集成服务发现的功能？
「不可更改基础设施：六问六专家」很成功，这次我们套用这种形式，向四位专家提问有关服务发现的六个问题。
服务发现不是什么新问题（想想 DNS 出现多久了）。最近几年，由于服务和微服务架构——当然，还包括 Docker ——的爆发，服务发现发展得非常快。
关于服务发现的含义、好处、挑战和实现方案，众说纷纭。我们邀请四位有经验的专家，请他们回答下面六个问题：
不同的使用情境，服务发现的含义也不同。例如，网络设备发现、零配置网络（ rendezvous ）发现和 SOA 发现等。无论是哪一种使用情境，服务发现提供了一种协调机制，方便服务的发布和查找。
前文已经提到过，服务元数据存储是服务发现的关键，因为复杂的服务提供了多种服务接口和端口，部署环境也比较复杂。一旦服务发现组件存储了大量元数据，它就必须提供强大的查询功能，包括服务健康和其它状态的查询。
服务发现组件必须提供查询所有服务的部署状态和集中控制所有服务实例的手段。对于那些不仅提供 DNS 功能的复杂系统，这一点尤为关键。
人们已经使用 DNS 很长时间了， DNS 可能是现有的最大的服务发现系统。小规模系统可以先使用 DNS 作为服务发现手段。一旦服务节点的启动和销毁变得更加动态， DNS 就有问题了，因为 DNS 记录传播的速度可能跟不上服务节点变化的速度。
ZooKeeper 大概是最成熟的配置存储方案，它的历史比较长，提供了包括配置管理、领导人选举和分布式锁在内的完整解决方案。因此， ZooKeeper 是非常有竞争力的通用的服务发现解决方案，当然，它也显得过于复杂。
etcd 和 doozerd 是新近出现的服务发现解决方案，它们与 ZooKeeper 具有相似的架构和功能，因此可与 ZooKeeper 互换使用。
Consul 是一种更新的服务发现解决方案。除了服务发现，它还提供了配置管理和一种键值存储。 Consul 提供了服务节点的健康检查功能，支持使用 DNS SRV 查找服务，这大大增强了它与其它系统的互操作性。 Consul 与 ZooKeeper 的主要区别是： Consul 提供了 DNS 和 HTTP 两种 API ，而 ZooKeeper 只支持专门客户端的访问。
如果你希望实现一个 AP( Availability and Partition ) 系统， Eureka 是一个很好的选择，并在 Netflix 得到了实战的检验。在出现网络分区时， Eureka 选择可用性，而不是一致性。
一开始，你可以用一个配置文件实现服务发现，这个文件中包含了所有服务的名字、 IP 地址和端口等信息。当系统变得更加动态后，你就要把服务发现从静态配置迁移到一个真正的解决方案。这个迁移过程，并不像一般人所想的那么容易。最大的一项挑战是无从知晓所选的服务发现系统的侵入性如何：一旦选定一个服务发现系统，就很难再改用其它的服务发现系统，因此，一开始就必须选择正确的解决方案。
很多服务发现系统都实现了某种形式的分布式共识算法，保证即使有节点失效系统仍然能够正常运转。但是，这些算法是出名地难实现，关键是要识别出分布式系统中失效的节点，这很困难。如果不能正确地识别，就不会正确地实现分布式共识算法。
一旦选定了服务发现的机制（网络或者服务），理解了系统的优化点（这是最难的部分），接下来只要集成注册和查找组件就可以了。
包含完整解答的 PDF 文档
可以从下面的网址下载包含完整解答的 12 页 PDF 文档。
译者注：请访问原文下载
原文链接：Service Discovery: 6 questions to 4 experts （翻译：柳泉波）
「不可更改基础设施：六问六专家」很成功，这次我们套用这种形式，向四位专家提问有关服务发现的六个问题。
服务发现不是什么新问题（想想 DNS 出现多久了）。最近几年，由于服务和微服务架构——当然，还包括 Docker ——的爆发，服务发现发展得非常快。
关于服务发现的含义、好处、挑战和实现方案，众说纷纭。我们邀请四位有经验的专家，请他们回答下面六个问题：
- 什么是服务发现？
- 服务发现应该具备哪些关键特性，理由是什么？
- 你认为服务发现带来的主要好处是什么？
- 时至今日，哪一种服务发现方案是最可靠的？
- 实施服务发现面临的最大挑战是什么？
- 在一个全新的系统中实现服务发现（相对）容易。已有的系统如何集成服务发现功能？
专家名单
- Sam Newman 是 ThoughtWorks 的一名技术布道者，他的工作范围包括参与开源项目、在技术会议上讲演、技术写作（包括由 O’Reilly 出版的书籍「 Building Microservices 」）等。
- Nitesh Kant 是 Netflix 云与平台工程团队的一名工程师，他引领了进程间通信（Inter Process Communication, IPC ）技术方案的革新，使之符合响应式编程（ reactive programming ）范式。他是这套技术方案的核心——响应式 IPC 库 RxNetty 的核心开发者。他还参与了 Netflix 服务发现系统 eureka 的开发，构思和设计了 2.0 版。 Eureka 是 Netflix 微服务架构的支柱，支撑了成千上万的微服务。
- Jeff Lindsay 是 Dokku 以及其它很多与 Docker 相关的开源项目的作者。他是 Glider Labs 的共同创始人和主任，一位擅长 Docker 架构开发和运维的顾问。 Jeff 参与了 Docker 早期的开发，曾与 Twilio、Digital Ocean 和 NASA Ames 等组织一起做分布式系统和开发者平台相关的工作。
- Eberhard Wolff 是一位 innoQ Fellow ，他的技术兴趣包括现代体系架构——包括云计算、持续交付、开发运维、微服务和 NOSQL 。 Eberhard 是国际会议的演讲者常客，他已经写了超过 100 篇文章和几本书，大部分是用德语写的。
亮点
本文最后给出的链接，包含了所有回答的全部内容，推荐阅读。这里只列出部分亮点。1）什么是服务发现？
服务发现组件记录了（大规模）分布式系统中所有服务的信息，人们或者其它服务可以据此找到这些服务。 DNS 就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、健康监控、多种查询和实时更新等。不同的使用情境，服务发现的含义也不同。例如，网络设备发现、零配置网络（ rendezvous ）发现和 SOA 发现等。无论是哪一种使用情境，服务发现提供了一种协调机制，方便服务的发布和查找。
2）服务发现应该具备哪些关键特性，理由是什么？
服务发现是支撑大规模 SOA 的核心服务，它必须是高可用的，提供注册、目录和查找三大关键特性，仅仅提供服务目录是不够的。前文已经提到过，服务元数据存储是服务发现的关键，因为复杂的服务提供了多种服务接口和端口，部署环境也比较复杂。一旦服务发现组件存储了大量元数据，它就必须提供强大的查询功能，包括服务健康和其它状态的查询。
3）你认为服务发现带来的主要好处是什么？
服务发现的主要好处是「零配置」：不用使用硬编码的网络地址，只需服务的名字（有时甚至连名字都不用）就能使用服务。在现代的体系架构中，单个服务实例的启动和销毁很常见，所以应该做到：无需了解整个架构的部署拓扑，就能找到这个实例。服务发现组件必须提供查询所有服务的部署状态和集中控制所有服务实例的手段。对于那些不仅提供 DNS 功能的复杂系统，这一点尤为关键。
4）时至今日，哪一种服务发现解决方案是最可靠的？
目前，业界提供了很多种服务发现解决方案。人们已经使用 DNS 很长时间了， DNS 可能是现有的最大的服务发现系统。小规模系统可以先使用 DNS 作为服务发现手段。一旦服务节点的启动和销毁变得更加动态， DNS 就有问题了，因为 DNS 记录传播的速度可能跟不上服务节点变化的速度。
ZooKeeper 大概是最成熟的配置存储方案，它的历史比较长，提供了包括配置管理、领导人选举和分布式锁在内的完整解决方案。因此， ZooKeeper 是非常有竞争力的通用的服务发现解决方案，当然，它也显得过于复杂。
etcd 和 doozerd 是新近出现的服务发现解决方案，它们与 ZooKeeper 具有相似的架构和功能，因此可与 ZooKeeper 互换使用。
Consul 是一种更新的服务发现解决方案。除了服务发现，它还提供了配置管理和一种键值存储。 Consul 提供了服务节点的健康检查功能，支持使用 DNS SRV 查找服务，这大大增强了它与其它系统的互操作性。 Consul 与 ZooKeeper 的主要区别是： Consul 提供了 DNS 和 HTTP 两种 API ，而 ZooKeeper 只支持专门客户端的访问。
如果你希望实现一个 AP( Availability and Partition ) 系统， Eureka 是一个很好的选择，并在 Netflix 得到了实战的检验。在出现网络分区时， Eureka 选择可用性，而不是一致性。
5）实施服务发现面临的最大挑战是什么？
服务发现之复杂，远超一般人的想象。这种复杂性源自分布式系统的复杂性。一开始，你可以用一个配置文件实现服务发现，这个文件中包含了所有服务的名字、 IP 地址和端口等信息。当系统变得更加动态后，你就要把服务发现从静态配置迁移到一个真正的解决方案。这个迁移过程，并不像一般人所想的那么容易。最大的一项挑战是无从知晓所选的服务发现系统的侵入性如何：一旦选定一个服务发现系统，就很难再改用其它的服务发现系统，因此，一开始就必须选择正确的解决方案。
很多服务发现系统都实现了某种形式的分布式共识算法，保证即使有节点失效系统仍然能够正常运转。但是，这些算法是出名地难实现，关键是要识别出分布式系统中失效的节点，这很困难。如果不能正确地识别，就不会正确地实现分布式共识算法。
6）在一个全新的系统中实现服务发现（相对）容易。已有的系统如何集成服务发现功能？
第一步，让服务的客户无需了解服务的具体部署细节，通过查询外部的服务信息存储来找到服务。一开始简单地使用属性保存服务的元数据就可以了，随着系统变得更加动态，再升级到使用外部的服务发现系统。一旦选定了服务发现的机制（网络或者服务），理解了系统的优化点（这是最难的部分），接下来只要集成注册和查找组件就可以了。
包含完整解答的 PDF 文档
可以从下面的网址下载包含完整解答的 12 页 PDF 文档。
译者注：请访问原文下载
原文链接：Service Discovery: 6 questions to 4 experts （翻译：柳泉波）
