服务的注册与发现（Eureka）

服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和发现。
微服务中用来做注册中心的组件常有zookeeper、eureka、Consul等，这里主要学习Eureka。

Eureka的工作原理

Eureka的组件主要由服务端和客户端组成：

• 服务端：即为注册中心，支持高可用配置，与zookeeper不一样，在CAP理论中，zookeeper保证CP，而Eureka保证AP。CAP理论：C(一致性)、A(可用性)和P(分区容错性)三个只能保证其二。注册中心能够接受客户端发来的服务注册请求，按照服务名分类组织服务清单，同时还以客户端设置的心跳模式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。
• 客户端：向服务端注册服务、从服务端发现服务。其嵌入在客户端应用程序的代码中。在应用程序启动时，Eureka客户端向服务注册中心注册自身提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。并周期性的发送心跳来更新它的服务租约。同时，他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期行的刷新服务列表的状态。然后通过服务名发起请求调用实现，而不是通过指定具体的实例地址来调用。

Spirng Cloud Eureka使用Netflix Eureka来实现服务注册与发现。服务端与客户端均采用java编写，所以Eureka主要适用于通过java实现的分布式系统，或是JVM兼容语言构建的系统。Eureka的服务端提供了较为完善的REST API，Eureka也支持将非java语言实现的服务纳入到Eureka服务治理体系中来，只需要其他语言平台自己实现Eureka的客户端程序。目前.Net平台的Steeltoe、Node.js的eureka-js-client等都已经实现了各自平台的Ereka客户端组件。

其结构图如下：

服务端

高可用服务注册中心的概念

考虑到发生故障的情况，服务注册中心发生故障必将会造成整个系统的瘫痪，因此需要保证服务注册中心的高可用。

Eureka Server在设计的时候就考虑了高可用设计，在Eureka服务治理设计中，所有节点既是服务的提供方，也是服务的消费方，服务注册中心也不例外。

Eureka Server的高可用实际上就是将自己做为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。

失效剔除

有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使服务不能正常运作。而服务注册中心并未收到“服务下线”的请求，为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。

自我保护

服务注册到Eureka Server后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间会统计心跳失败的比例在15分钟以之内是否低于85%，如果出现低于的情况，Eureka Server会将当前实例注册信息保护起来，让这些实例不会过期。

其原因是，这个心跳统计比例低于85%时，无法确认是注册中心的网络有问题还是客户端有问题，如果是客户端有问题剔除即可，可是如果是注册中心有问题，客户端的服务提供者依然健康，则把它剔除则不是很好，所以将其保护起来，使其它客户端在此注册中心获取服务列表时，依然能够获取此客户端的服务信息。
这样做会使客户端很容易拿到实际已经不存在的服务实例，比如：提供服务的客户端真的死掉了，则会出现调用失败的情况。因此客户端要有容错机制，比如请求重试、断路器。

以下是自我保护相关的属性：
eureka.server.enableSelfPreservation=true. 可以设置改参数值为false，以确保注册中心将不可用的实例删除。

服务同步

从eureka服务治理体系架构图中可以看到，不同的服务提供者可以注册在不同的服务注册中心上，它们的信息被不同的服务注册中心维护。

此时，由于多个服务注册中心互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现服务注册中心之间的服务同步。通过服务同步，提供者的服务信息就可以通过集群中的任意一个服务注册中心获得。

客户端

获取服务

消费者服务启动时，会发送一个Rest请求给服务注册中心，来获取上面注册的服务清单。消费者服务启动时，会发送一个Rest请求给服务注册中心，来获取上面注册的服务清单。同时该缓存清单默认会每隔30秒更新一次。
下面是获取服务的两个重要的属性：

1. eureka.client.fetch-registry：是否需要去检索寻找服务，默认是true
2. eureka.client.registry-fetch-interval-seconds：表示eureka client间隔多久去拉取服务注册信息，默认为30秒，对于api-gateway，如果要迅速获取服务注册状态，可以缩小该值，比如5秒

服务下线

在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭操作时，会触发一个服务下线的Rest服务请求给Eureka Server，告诉服务注册中心：“我要下线了。”服务端在接收到该请求后，将该服务状态置位下线（DOWN），并把该下线事件传播出去。

通讯协议

默认情况下，Eureka使用Jersey和XStream配合JSON作为Server与Client之间的通讯协议。也可以选择实现自己的协议来代替。