《Spring Cloud》学习（一） 服务治理！

原文： http://www.cnblogs.com/crazycheng/p/10826283.html
前言：之前网上学习过Spring Cloud，对于工作上需要是足够了，总归对于一些方面一知半解，最近难得有些闲暇时间，有幸读了崔永超先生的《Spring Cloud 微服务实战》，一方面记录下自己的学习历程和读后感，一方面分享下自己对Spring Cloud微服务的一些见解，写下此文。

注意：本文着重于描述Spring Cloud运行的机制和原理部分，不会涉及到过多的代码，不会演示如何搭建注册发现，高性能注册中心，配置负载均衡等等，但是会对其内部运行机制及原理进行一定的详解。所以本文默认读者有一定的Spring Cloud基础。 您如果打算系统学习该技术，本人还是推荐上述提及书籍。

当然欢迎大牛指导错误及不足！
介绍：Spring Cloud是基于Spring Boot实现的微服务架构工具，提供了配置管理，服务治理，断路器，智能路由，微代理，控制总线，全局锁，决策竞争，分布式会话，集权状态管理等操作。
第一章 服务治理
服务治理是微服务架构的核心与基础，主要实现各个服务实例的自动化注册与发现。Spring Cloud Eureka 基于 Netflix Eureka 做了二次封装，主要负责完成微服务架构中的服务治理功能。主要用来实现服务注册发现，同时包含服务端，客户端组件。
一.服务注册 服务续约 服务发现

1.服务注册 服务续约

服务注册：服务治理中，构建注册中心来统一管理每个服务，客户端向注册中心发送自身服务的服务名，端口，IP，通信协议等等元数据信息。注册中心会将其并储存至本地服务清单（双层Map结构存储）。

高可用注册中心：分布式环境中，我们需要充分考虑发生故障的情况，所以在生产 环境中必须对各个组件进行高可用部署，对于服务注册中心也一样。 需要构建高可用的服务注册中心以增强系统的可用性。 Eureka Server的设计一开始就考虑了高可用问题，在Eureka的服务治理设计中，所有 节点即是服务提供方，也是服务消费方，服务注册中心也不例外。
Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这 样就可以形成一组互相注册的服务注册中心， 以实现服务清单的互相同步， 达到高可用的 效果。 以集群的方式部署注册中心，允许分片故障期间，其他分片继续提供服务发现注册，故障分片恢复时其他分片会把状态同步回来。不同的注册中心分片通过异步方式互相复制状态，提供高的实例可用性。

如图4个客户端之间可以相互调用。

服务续约： 客户端向注册中心注册自身的服务信息后，并且周期性的（默认30秒）发送心跳（eurekaTransport.registrationClient.sendHeartBeat方法）来更新服务租约。 注册中心如果一段时间（默认90秒）内没收到客户端的心跳续约，则会剔除该客户端。
注册流程详解：

客户端操作：服务启动时发送REST请求到注册中心的方式进行的，以discoveryClent.register(instanceinfo)方法进行服务注册，可以看到以com.netflix.appinfo.Instanceinfo对象为参数，该对象就是注册时客户端给服务端的服务的元数据信息（主机名、IP地址、端口号、状态页和健康检查等等）。

注册中心端操作：注册中心接收到注册请求后，先调用publishEvent函数，将该新服务注册的事件已请求转发的方式传播出去，通知其他节点的注册中心，达到服务同步，然 后调用com.netflix.eureka.registry.AbstractlnstanceRegistry父类中的register注册实现，将InstanceInfo中的元数据信息存储在一个ConcurrentHashMap对象中。 ConcurrentHashMap<String, Map<String,Lease>>对象，它是一个两层Map结构，第一层的key存储服务名：InstanceInfo中的appName属性，第二层的key存储实例名：InstanceInfo中的instanceId属性。

2.服务发现
服务启动会调用com.netflix.discovery.DiscoveryClient的initScheduledTasks函数，发现在其中还有两个定时任务，分别是 服务获取 和 服务续约。
当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取注册中心存储的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时每个客户端都会周期的（默认30秒）向注册中心咨询，获取到所有的服务实例清单，存入本地(serverList),可以对其他具体服务实例进行访问。(若希望修改缓存清单的 更新时间，可以通过 eureka.clent.registry-fetch-interval-seconds=30参数进行修改)。
二.服务消费

服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例 （使用RestTemplate） 。

RestTemplate：主要有GET,POST,PUT,DELETE的请求方式。
GET有getForEntity和 getForObject 的重载。 POST有 postForEntity和 postFor Object的重载。
一般我们都会使用负载均衡结合 Ribbon 完成。当Ribbon与Eureka联合使用时，Ribbon的服务实例清单RibbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。 Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问(默认)以达到均衡负载的作用。

(具体的Ribbon及RestTemplate下章负载均衡会详解)
三.服务下线 失效剔除

3.1服务下线
在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续调用关闭了的实例。 所以在客户端程序中， 当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给注册中心,告诉服务注册中心：我要下线了。注册中心在接收到请求之后，将该服务状态置为下线(DOWN), 并把该下线事件传播出去。
3.2失效剔除
有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出，网络故障等原因使得服务不能正常工作，而服务注册中心并未收到服务下线的请求。为 了从服务列表中将这些无法提供服务的实例剔除， 注册中心在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。

3.3自我保护
自我保护机制：服务注册到Eureka Server之后，会维护一个心跳连接，告诉Eureka Server自己还活着。EurekaServer在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%, 如果出现低于的情况，EurekaServer会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的清况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
如果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中的其他分片会把它们的状态再次同步回来。
当然也可以使用eureka.server.enableself-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。
四.健康检测

Actuator监控管理：为了系统获取各个微服务相关指标比如环境变量，垃圾收集信息，内存信息，线程池信息，HTTP请求统计。Spring Cloud提供了Actuator模块来自动构建一系列用于监控的端点，并且支持扩展。模块中自带一些常用资源的健康指标检接口，比如磁盘空间，DataSource链接，Mongo数据库可用，Rabbit服务，Redis，Solr检测等，也可以自己实现自定义检测器。

默认情况下，Eureka中各个服务实例的健康检测并不是通过spring-boot-actuator模块的/health 端点来实现的， 而是依靠客户端心跳的方式来保持服务实例的存活。在Eureka 的服务续约与剔除机制下，客户端的健康状态从注册到注册中心开始都会处于 UP状态， 除非心跳终止一段时间之后，服务注册中心将其剔除。 默认的心跳实现方式可以有效检查客户端进程是否正常运作， 但却无法保证客户端应用能够正常提供服务。由于大多数微服务应用都会有一些其他的外部资源依赖，比如数据库、 缓存、 消息代理等，如果我们的应用与这些外部资源无法联通的时候， 实际上已经不能提供正常的对外服务了，但是因为客户端心跳依然在运行， 所以它还是会被服务消费者调用，而这样的调用实际上并不能获得预期的结果。

在Spring Cloud Eureka中，我们可以通过简单的配置，把Eureka客户端的健康检测交给spring-boot-actuator模块的/health端点， 以实现更加全面的健康状态维护。