Eureka (服务发现框架) 及服务发现

一、Eureka 简介

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

        Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互，客户端同时也就是一个内置的、使用轮询 (round-robin) 负载算法的负载均衡器。

        在应用启动后，将会向 Eureka Server 发送心跳，默认周期为 30 秒，如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将会从服务中心注册表中把这个服务节点移除 (默认90秒)。

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

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

二、服务发现原理

三、服务发现组件的功能

(1) 服务注册表：一个记录当前可用服务实例的网络信息的数据库，是服务发现机制的核心。服务注册表提供查询 API 和管理 API，使用查询 API 获得可用的服务实例，使用管理 API 实现注册和注销；

(2) 服务注册：在服务启动时，将服务实例的网络地址信息添加到服务注册表中，称之为服务注册；

(3) 健康检查：服务发现组件会通过一些机制定时检测已注册的服务，如果发现某些服务无法访问了(可能是某几个心跳周期后)，就会将该服务从服务注册表中移除/注销掉；

四、服务发现方式

       服务实例的网络位置都是动态分配的。由于扩展、失败、升级，服务实例会经常动态改变，因此，客户端代码需要使用更加复杂的服务发现机制。服务发现有以下两种模式：

(1) 客户端发现：例如，Eureka、zookeeper；

       使用客户端发现模式时，客户端决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端查询服务注册表，后者是一个可用服务实例的数据库；然后使用负载均衡算法从中选择一个实例，并发出请求。

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

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

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

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

(2) 服务器端发现：Consul + nginx

       客户端通过负载均衡器向某个服务提出请求，负载均衡器查询服务注册表，并将请求转发到可用的服务实例。如同客户端发现，服务实例在服务注册表中注册或注销。

       AWS Elastic Load Balancer(ELB) 是服务端发现路由的例子，ELB 通常均衡来自互联网的外部流量，也可用来负载均衡 VPC(Virtual private cloud) 的内部流量。客户端使用 DNS 通过 ELB 发出请求 (HTTP 或 TCP)，ELB 在已注册的 EC2 实例或 ECS 容器之间负载均衡。这里并没有单独的服务注册表，相反，EC2 实例和 ECS 容器注册在 ELB。

       HTTP服务器与类似 NGINX PLUS 和 NGINX 这样的负载均衡器也能用作服务端的发现均衡器。Graham Jenson 的 Scalable Architecture DR CoN: Docker, Registrator, Consul, Consul Template and Nginx 一文就描述如何使用 Consul Template 来动态配置 NGINX 反向代理。Consul Template 定期从 Consul Template 注册表中的配置数据中生成配置文件；文件发生变更即允许任意命令。

       Kubernetes 和 Marathon 这样的部署环境会在每个集群上运行一个代理，将代理用作服务端发现的负载均衡器。客户端使用主机 IP 地址和分配的端口通过代理将请求路由出去，向服务发送请求。代理将请求透明地转发到集群中可用的服务实例。

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

五、服务注册与远程服务调用的流程：

        在 RPC 架构项目中，一个服务从注册到被调用的整个流程步骤如下：

1. 启动注册中心 (Ereka、Zookeeper、Redis、...)，等待服务提供者或者消费者连接；

2. 启动服务提供者；服务提供者启动时，会把当前服务的基本信息以别名的方式注册到注册中心上去；

     备注：① 服务的基本信息，是一般是指服务的地址、端口号；

                ② 别名，是指在注册中心存储服务信息时，会为每个服务生成一个serviceId；在注册中心存储的所有服务的 serviceId 是唯一的，而存储的服务信息不一定唯一；即有可能多个 serviceId 对应相同的服务地址及端口号；

                ③ 注册中心存储服务的方式是以类似于Java中的Map的形式存储的；即类似于键值对的形式，其键就是生成的 serviceId，值就是所注册服务的地址和端口号，例如:127.0.0.1:8080；

3. 启动服务消费者；服务消费者启动时，会使用服务别名 (也就是 serviceId) 去注册中心获取实际的 RPC 远程调用地址；

4. 在消费者获取到实际的 RPC 远程调用地址后，再使用本地的 HttpClient 技术 (http + json) 实现调用；

     备注：① 消费者在获取到 RPC 远程调用的服务地址后，会首先将其混村在本地的 jvm 内存中；

                ② 默认情况下，Eureka 会每隔 30 秒更新一次服务调用地址；