服务发现介绍

服务发现介绍

这是一个由面试引处理的问题。通过找资料将服务发现的相关知识进行记录。

目录：

1. 什么是服务发现？
2. 服务发现应该具备哪些关键特性，理由是什么？
3. 你认为服务发现带来的主要好处是什么？
4. 时至今日，哪一种服务发现方案是最可靠的？
5. 实施服务发现面临的最大挑战是什么？
6. 在一个全新的系统中实现服务发现（相对）容易。已有的系统如何集成服务发现功能？

什么是服务发现

服务发现组件记录了（大规模）分布式系统中所有服务的信息，人们或者其它服务可以据此找到这些服务。 DNS 就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、健康监控、多种查询和实时更新等。

不同的使用情境，服务发现的含义也不同。例如，网络设备发现、零配置网络（ rendezvous ）发现和 SOA 发现等。无论是哪一种使用情境，服务发现提供了一种协调机制，方便服务的发布和查找。

服务发现应该具备哪些关键特性，理由是什么？

服务发现是支撑大规模 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 地址和端口等信息。当系统变得更加动态后，你就要把服务发现从静态配置迁移到一个真正的解决方案。这个迁移过程，并不像一般人所想的那么容易。最大的一项挑战是无从知晓所选的服务发现系统的侵入性如何：一旦选定一个服务发现系统，就很难再改用其它的服务发现系统，因此，一开始就必须选择正确的解决方案。

很多服务发现系统都实现了某种形式的分布式共识算法，保证即使有节点失效系统仍然能够正常运转。但是，这些算法是出名地难实现，关键是要识别出分布式系统中失效的节点，这很困难。如果不能正确地识别，就不会正确地实现分布式共识算法。

在一个全新的系统中实现服务发现（相对）容易。已有的系统如何集成服务发现功能？

第一步，让服务的客户无需了解服务的具体部署细节，通过查询外部的服务信息存储来找到服务。一开始简单地使用属性保存服务的元数据就可以了，随着系统变得更加动态，再升级到使用外部的服务发现系统。

一旦选定了服务发现的机制（网络或者服务），理解了系统的优化点（这是最难的部分），接下来只要集成注册和查找组件就可以了。