服务治理——Eureka

1.1 服务治理中心

服务治理中心是微服务（分布式）架构中最基础和最核心的功能组件，它主要对各个服务实例进行管理，包括服务注册和服务发现等。

1.2 微服务实例和服务治理中心的关系

任何的微服务都可以对Eureka服务治理中心（也称为Eureka服务端）发送REST风格的请求。在Eureka的机制中，一般是由具体的微服务（也称为Eureka客户端）来主动维持它们之间的关系的。Eureka客户端的请求类型包括注册、续约和下线。

1.2.1 注册

在将具体的微服务实例注册到Eureka服务端时，是通过REST风格请求其配置的属性eureka.client.serviceUrl.defaultZone生成的URL来完成的，这时，微服务会将其自身的信息传递给Eureka服务端，完成注册。在微服务实例中，存在一个配置项eureka.client.register-with-eureka，它的值是布尔（boolean）类型的，默认为true，代表默认情况下将微服务注册到Eureka服务治理中心。当我们将其配置为false的时候，微服务不会被注册到Eureka服务端。注意，当启动微服务时，它并不会马上向Eureka服务治理中心发送REST请求，在Eureka服务治理中心注册，它会延迟40秒才发起请求，所以在启动微服务的时候，需要稍等一会儿才能在Eureka服务治理中心页面中看到注册信息。

1.2.2 续约

在我们将具体的微服务实例注册到Eureka服务端后，并不能保证该实例一直可用，因为该实例可能出现网络故障、机器故障或者服务宕机等，所以具体的微服务实例会按照一个频率对Eureka服务器维持心跳，告诉Eureka该实例是可用的，借此来避免被Eureka服务端剔除出去，这样的行为被称为续约（Renew）。

1.2.3 下线

在系统出现故障，需要停止或者重启某个微服务实例的时候，在正常操作下，实例会对Eureka发送下线REST风格请求，告知服务治理中心，这样客户端就不能再请求这个实例了。

1.3 服务治理中心之间的关系

1.3.1相互复制

Eureka本身也会相互注册，以保证高可用和高性能。各个Eureka服务器之间也会相互复制，也就是当微服务发生注册、下线和续约这些操作的时候，Eureka会将这些消息转发到其他服务治理中心的实例上，这样就完成同步了。需要注意的是，这里的Eureka服务器之间采用的是对等模式（Peer-to-Peer），也就是每一个Eureka都是等价的，这有别于分布式中的主从模式（Master-Slave）。

1.3.2 服务剔除

在实际的工作中，有时候有些服务会因为网络故障、内存溢出或者宕机而导致服务不能正常工作，这个时候就要将这些无效的服务实例剔除出去。Eureka Server在启动时，会创建一个定时任务，在默认的情况下，每间隔60秒就会更新一次微服务实例的清单，只要发现有超过90秒没有完成续约的实例，就会将其剔除出去。

1.3.3 自我保护

在我们启动实例的时候，微服务实例都会自动查找Eureka进行注册，Eureka实例也是如此。在Eureka注册之后，它自己也会通过心跳来告诉自己还活着。在Eureka运行期间，如果在15分钟内低于85%的情况下心跳测试失败，它就会出现警告（在单机测试中很容易出现，在实际生产环境中往往是网络故障）。

1.4 微服务之间的相互调用

1.4.1 服务获取

服务获取是指微服务实例作为Eureka的客户端，从Eureka服务治理中心获取其他微服务实例清单的功能。它还会将该服务实例清单缓存到本地，并且按一定的时间间隔刷新。当我们启动微服务实例的时候，它就会以一个时间间隔（默认是30秒）向Eureka服务治理中心发送REST风格请求，获取一份只读的服务实例清单，跟着进行缓存，在下一个时间间隔再发送REST风格请求到Eureka，获取最新的服务实例清单，以确定哪些实例可用，哪些实例不可用。

1.4.2 服务调用

服务调用是指一个微服务调用另一个微服务的过程。在SpringCloud中，大部分会采用REST风格请求。