SpringCloud微服务实战

监控与管理：

为了让运维系统能够获取各个微服务应用的相关指标，需要开发一套专门用于植入各个微服务应用的接口供监控系统采集信息。而这些接口往往大部分指标都是类似的，比如环境变量、垃圾收集信息、内存信息、线程池信息。
端点就是实现此功能的一个标准化框架。
Maven依赖引入spring-boot-starter-actuator模块能自动为SpringBoot构建的应用提供一系列用于监控的端点。同时SpringCloud在实现各个微服务组件的时候，会进一步扩展该模块，为原生端点增加了更多的指标和度量信息（比如在整合Eureka的时候会为/health端点增加相关信息，为网关Zuul提供/routes端点返回路由信息）。
原生端点：
应用配置类：获取应用程序中加载的应用配置、环境变量、自动化配置报告等配置类信息。

• /autoconfig:该端点用来获取应用的自动化配置报告，其中包括所有自动化配置的候选项，同时列出了每个候选项是否满足自动化配置的各个先决条件。我们可以通过它找到一些自动化配置没有生效的原因
• /beans:该端点用来获取应用上下文创建的所有的bean
• /configprops:该端点用来获取应用中配置的属性信息报告
• /env:该端点用来获取应用所有可用的环境属性报告，包括环境变量、JVM属性、应用的配置属性、命令行参数
• /mappings：该端点用来返回所有SpringMVC的控制器映射关系报告
• /info:返回一些应用自定义的信息

度量指标类：获取应用程序运行中的指标，比如内存信息、线程池信息、HTTP请求统计等

• /metrics:该端点用来返回当前应用的度量指标，比如内存信息、线程信息、垃圾回收信息
• /health:用来获取应用的各类健康指标信息
• /dump:用来暴露程序运行中的线程信息
• /trace:用来返回基本的HTTP跟踪信息

操作控制类：提供了对应用的关闭等操作类功能，前两类端点用来反映应用自身的属性或状态，而操作控制类端点有更强大的控制能力，如果要使用，需要通过属性来配置开启操作，原生端点中，只提供了一个用来关闭应用的端点：/shutdown,可通过如下配置开启：
endpoints.shutdown.enabled=true
默认，所有的actuator endpoint通过JMX被暴露，而通过HTTP暴露的只有health和info。
通过HTTP暴露Actuator endpoints：
management.endpoints.web.exposure.include=health,info

Eureka部分

为了解决微服务架构中的服务实例维护问题，产生了很多服务治理框架，这些框架都围绕着服务注册与服务发现来完成对微服务实例的自动化管理。
服务端
Eureka服务端，支持高可用配置。如果以集群模式部署，当集群中有分片故障时，Eureka会转入自我保护模式，他允许在分片故障期间继续提供服务的发现与注册，当故障分片恢复运行时，集群中的其他分片会把他们的状态再次同步回来。不同可用区域的服务注册中心通过异步模式互相复制各自的状态，这就说明在某时间点每个实例关于所有服务的状态有细微的差别。
客户端
客户端通过注解与参数配置，可嵌入在客户端应用程序的代码中。程序运行时，Eureka客户端向注册中心注册自身并周期性地发送心跳来更新服务租约，同时他也能从服务端查询当前注册的服务信息并缓存，然后周期性的刷新服务状态。
搭建服务注册中心
dependency引入spring-cloud-starter-eureka-server,启动@EnableEurekaServer

server.port=1111 
eureka.instance.hostname=localhost 
eureka.client.register-with-eureka=false
eureka.fetch-registry=false
eureka.client.serviceUrl.defaultZone=http://${eureka.instance.hostname}:${server.port}/eureka/

服务提供者:@EnableDiscoveryClient

spring.application.name=hello-service  
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

高可用注册中心：
实际上就是将eureka服务端作为服务向其他服务注册中心注册自己，这样形成了一组互相注册的服务注册中心，以实现服务清单的互相同步。
Ribbon：是一个基于HTTP和TCP的客户端负载均衡器，
它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到负载均衡的效果。当Ribbon与Eureka联合使用时，Ribbon的服务实例清单RibbonServerList会被DiscoveryEnableNIWServerList重写，扩展成从注册中心获取服务端列表，默认使用轮询策略。

Eureka详解

服务提供者：

• 服务注册：服务提供者在启动的时候会发通过发送REST请求将自己注册到Eureka Server，同时带上自身服务的一些元数据信息。Eureka Server接收到这个请求之后，会将元数据信息存储在一个双层Map中，第一层key是服务名，第二层key是具体服务的实例名。
• 服务同步：两个服务提供者分别注册到了两个不同的注册中心上，也就是说他们的信息分别被这两个服务注册中心所维护，此时如果服务注册中心之间互相注册为服务（高可用），当服务提供者发送注册请求到一个注册中心时，他会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息可以通过任何一个注册中心获取到。
• 服务续约：
  eureka.instance.lease-renewal-interval-in-seconds=30(默认)
  eureka.instance.lease-expiration-duration-in-seconds=90(默认)
  前者定义服务续约任务的调用间隔时间，后者用于定义服务失效的时间

服务消费者：

• 获取服务：当我们启动服务消费者的时候，他会发送一个REST请求给注册中心，来获取服务清单。获取服务需确保：
  eureka.client.fetch-registry=true
  若希望修改缓存清单的更新时间，可以：
  eureka.client.registry-fetch-interval-seconds=30(默认)
• 服务下线：当服务实例进行正常的关闭操作时，会触发一个服务下线的REST请求给Eureka Server，服务端收到请求之后，将该服务设置为DOWN

服务注册中心：

• 失效剔除：有时候服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因让服务不能正常工作，而注册中心未收到“服务下线”的请求。为了从服务列表中将他们剔除，Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认60s）将当前清单中超时（默认90s）没有续约的服务剔除。
• 自我保护：Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期。但是，在保护期间若实例出现问题，那么客户端很容易拿到实际已经不存在的服务实例，出现调用失败的情况。
  关闭保护机制：eureka.server.enable-self-preservation=true

Ribbon

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，通过SpringCloud的封装，它可以让我们轻松地将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。他只是个工具类框架，不需要像注册中心、网关那样独立部署，但他几乎存在于每一个SpringCloud构建的微服务和基础设施中。微服务间的调用，API网关的请求转发等内容，都是通过Ribbon实现的，包括Feign也是基于Ribbon。
负载均衡策略

Hystrix

Spring Cloud Hystrix 实现了断路器、线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的，该框架的目标在于通过控制那些访问远程系统服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。