服务发现 与 Eureka

服务发现：

在微服务架构中，服务发现（Service Discovery）是关键原则之⼀。⼿动配置每个客户端或某种形式的约定是很难做的，并且很脆弱。Spring Cloud提供了多种服务发现的实现⽅式，例如：Eureka、 Consul、Zookeeper。 Spring Cloud⽀持得最好的是Eureka，其次是Consul，最次是Zookeeper。

• 客户端服务发现模式：

使用客户端服务发现时，客户端负责决定可用服务实例的网络地址，并在它们中间进行负载均衡。客户端查询包含所有可用服务实例的服务注册表，使用负载均衡算法选择一个可用的服务，发出服务请求

客户端从服务注册服务中查询，其中是所有可⽤服务实例的库。客户端使⽤负载均衡算法从多个服务 实例中选择出⼀个，然后发出请求：

服务实例的网络位置在启动时被记录到服务注册表，等实例终止时被删除。服务实例的注册信息通常 使用心跳机制来定期刷新。

Netflix OSS 是客户端发现模式的绝佳范例。Netflix Eureka 是⼀个服务注册表，为服务实例注册管理 和查询可⽤实例提供了 REST API 接⼝。Netflix Ribbon 是 IPC 客户端，与 Eureka ⼀起实现对请求的 负载均衡。

客户端发现模式优缺点兼有。这⼀模式相对直接，除了服务注册外，其它部分⽆需变动。此外，由于客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡，比如使用哈希⼀致性。这种模式的一大缺点就是客户端与服务注册绑定，要针对服务端用到的每个编程语⾔和框架，实现客户端的服务发现逻辑。

• 服务端服务发现模式：

在服务端服务发现模式下，客户端向服务端的负载均衡器发送请求，负载均衡器查询服务注册表，将请求路由到对应的服务实例

服务端发现模式兼具优缺点。它最⼤的优点是客户端无需关注发现的细节，只需要简单地向负载均衡器发送请求，这减少了编程语⾔框架需要完成的发现逻辑。并且如上⽂所述，某些部署环境免费提供 这⼀功能。这种模式也有缺点。除非负载均衡器由部署环境提供，否则会成为⼀个需要配置和管理的高可用系统组件。

• 服务注册表：

服务注册表是服务发现的核心部分，是包含服务实例的网络地址的数据库。服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的网络地址，然而，这些信息最终会过时，客户端也就⽆法发现服务实例。因此，服务注册表会包含若干服务端，使用复制协议保持⼀致性。

如前所述，Netflix Eureka 是服务注册表的上好案例，为注册和请求服务实例提供了 REST API。服务实例使⽤ POST 请求来注册网络地址，每三十秒使用 PUT 请求来刷新注册信息。注册信息也能通过 HTTP DELETE 请求或者实例超时来被移除。以此类推，客户端能够使用 HTTP GET 请求来检索已注册的服务实例。

Netflix 通过在每个 AWS EC2 域运行⼀个或者多个 Eureka 服务实现高可用性。每个 Eureka 服务器都运行在拥有弹性 IP 地址的 EC2 实例上。DNS TEXT 记录被用来保存 Eureka 集群配置，后者包括可用域和 Eureka 服务器的网络地址列表。

Eureka 服务在启动时会查询 DNS 去获取 Eureka 集群配置，确定同伴位置，以及给自己分配⼀个未被使用的弹性 IP 地址。 Eureka 客户端，包括服务和服务客户端，查询 DNS 去发现 Eureka 服务的网络地址。客户端⾸选同⼀域内的 Eureka 服务。然⽽，如果没有可用服务，客户端会使用其它可用域中的 Eureka 服务。

其它的服务注册表包括：

etcd – 高可用、分布式、⼀致性的键值存储，⽤于共享配置和服务发现。Kubernetes 和 Cloud Foundry 是两个使⽤ etcd 的著名项⽬。

consul – 发现和配置的服务，提供 API 实现客户端注册和发现服务。Consul 通过健康检查来判断服务的可⽤性。

Apache ZooKeeper – 被分布式应用广泛使用的高性能协调服务。Apache ZooKeeper 最初是 Hadoop 的子项目，现在已成为顶级项⽬。 此外，如前所强调，像 Kubernetes、Marathon 和 AWS 并没有明确的服务注册，相反，服务注册已经内置在基础设施中。

• 服务注册的方式：

如前所述，服务实例必须在注册表中注册和注销。注册和注销有两种不同的⽅法。方法一是服务实例自己注册，也叫自注册模式（self-registration pattern）；另⼀种是采用管理服务实例注册的其他系统组件，即第三方注册模式。

自注册方式：

当使用自注册模式时，服务实例负责在服务注册表中注册和注销。另外，如果需要的话，⼀个服务实例也要发送心跳来保证注册信息不会过时。下图描述了这种架构：

Netflix OSS Eureka 客户端是非常好的案例，它负责处理服务实例的注册和注销。Spring Cloud 能够执行包括服务发现在内的各种模式，使得利用 Eureka 自动注册服务实例更简单，只需要给 Java 配置 类注释 @EnableEurekaClient。

自注册模式优缺点兼备。它相对简单，无需其它系统组件。然而，它的主要缺点是把服务实例和服务注册表耦合，必须在每个编程语⾔和框架内实现注册代码。

第三方注册模式：

将服务与服务注册表解耦合，服务实例不需要向服务注册表注册，而是服务注册器会通过查询部署环境或订阅事件的方式来跟踪运行实例的更改。一旦侦测到有新的可用服务实例，会向注册表注册此服务。服务管理器也负责注销终止的服务实例。

Registrator 是⼀个开源的服务注册项目，它能够自动注册和注销被部署为 Docker 容器的服务实例。 Registrator 支持包括 etcd 和 Consul 在内的多种服务注册表。

第三方注册模式也是优缺点兼具。在第三⽅注册模式中，服务与服务注册表解耦合，⽆需为每个编程语⾔和框架实现服务注册逻辑；相反，服务实例通过⼀个专有服务以中心化的方式进行管理。它的不足之处在于，除非该服务内置于部署环境，否则需要配置和管理⼀个高可用的系统组件。

• 总结：

在微服务应用中，服务实例的运行环境会动态变化，实例网络地址也是如此。因此，客户端为了访问服务必须使用服务发现机制。

服务注册表是服务发现的关键部分。服务注册表是可用服务实例的数据库，提供管理 API 和查询 API。服务实例使⽤管理 API 来实现注册和注销，系统组件使用查询 API 来发现可用的服务实例。

服务发现有两种主要模式：客户端发现和服务端发现。在使用客户端服务发现的系统中，客户端查询服务注册表，选择可用的服务实例，然后发出请求。在使用服务端发现的系统中，客户端通过路由转发请求，路由器查询服务注册表并转发请求到可用的实例。

服务实例的注册和注销也有两种方式。⼀种是服务实例自己注册到服务注册表中，即自注册模式；另⼀种则是由其它系统组件处理注册和注销，也就是第三方注册模式。

在⼀些部署环境中，需要使用 Netflix Eureka、etcd、Apache Zookeeper 等服务发现来设置自己的 服务发现基础设施。而另⼀些部署环境则内置了服务发现。例如，Kubernetes 和 Marathon 处理服务实例的注册和注销，它们也在每个集群主机上运行代理，这个代理具有服务端发现路由的功能。

HTTP 反向代理和 NGINX 这样的负载均衡器能够用做服务器端的服务发现均衡器。服务注册表能够将路由信息推送到 NGINX，激活配置更新，譬如使用 Cosul Template。NGINX Plus 支持额外的动态配置机制，能够通过 DNS 从注册表中获取服务实例的信息，并为远程配置提供 API

 

Eureka

Eureka是Netflix开发的服务发现框架，本身是⼀个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。Spring Cloud 将它集成在其子项目 spring-cloud-netflix 中，以实现 Spring Cloud 的服务发现功能。

Eureka官方架构图：

上图大致描述了 Eureka 集群的⼯作过程。由于图比较复杂，可能比较难看懂，这边用通俗易懂的语⾔翻译⼀下：

- Application Service 就相当于服务提供者，Application Client就相当于服务消费者；

- Make Remote Call，可以简单理解为调用 RESTful的接口；

- us-east-1c、us-east-1d 等是 zone，它们都属于us-east-1 这个region；

由图可知，Eureka包含两个组件：Eureka Server 和 Eureka Client。

Eureka Server 提供服务注册服务，各个节点启动后，会在 Eureka Server 中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

Eureka Client 是⼀个 Java 客户端，用于简化与 Eureka Server 的交互，客户端同时也具备⼀个内置的、 使用轮询（round-robin）负载算法的负载均衡器。 在应用启动后，将会向 Eureka Server 发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将会从服务注册表中把这个服务节点移除（默认 90秒）。

Eureka Server 之间将会通过复制的方式完成数据的同步。Eureka 还提供了客户端缓存的机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。

综上，Eureka 通过心跳检测、健康检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。