Spring Cloud技术总结
微服务架构我们为什么选择Spring Cloud？
Spring Cloud是微服务化得综合性解决框架，提供服务治理Eureka，容错Hystrix，客户端负载均衡Ribbon，配置中心Config，基于Ribbon和Hystrix的声明式服务调用组件Feign，网关Zuul，消息总线Bus等。对于第一次接触微服务架构的团队或者架构人员不足的团队能够快速搭建起整个微服务架构。
微服务架构的基础设施和微服务我们为什么选择Spring Boot？
- 和Spring Cloud整合起来简单
- 去掉Spring框架重复性复杂的配置，使用大量自动化配置来简化Spring原有的样板化配置帮助我们快速构建应用
- 嵌入式Tomcat，Jetty容器，部署起来更方便
服务治理Eureka
服务治理三个核心要素
- 服务注册中心：基于Eureka搭建服务注册中心，提供服务注册和服务发现的功能
- 服务提供者：将自己提供的服务注册到Eureka以供其他应用发现
- 服务消费者：从服务注册中心获取服务列表后，让消费者知道何处去调用需要的服务
高可用注册中心
服务注册中心一般需要搭建多台，多台服务注册中心分别向其他服务注册中心注册自己，实现服务清单互相同步，去掉单点故障，达到高可用的效果。
服务治理机制的几个关键实现
- 服务注册：服务提供者在启动的时候发送REST请求将自己注册到Eureka服务注册中心
- 服务同步：多台服务注册中心会互相同步服务
- 服务续约：服务提供者通过心跳让服务注册中心知道自己还活着
- 获取服务：服务消费者启动的时候通过REST请求获取Eureka服务注册中心的服务列表并定时更新
- 服务调用：基于Ribbon的客户端负载均衡来进行服务调用
- 服务下线：服务关闭时发送REST请求给服务注册中心下线服务，服务注册中心把下线事件广播出去
- 失效剔除：没心跳的服务服务注册中心会自动剔除
- 自我保护：如果在15分钟内超过85%的客户端节点都没有正常的心跳触发自我保护，保证服务不会过期
客户端负载均衡Ribbon
Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。
负载均衡方案分类
- 集中式, 即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5, 也可以是软件，如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方
- 客户端负载均衡，将负载均衡逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Ribbon是这种负载均衡。
负载均衡策略
- 简单轮询：以轮询的方式依次将请求调度不同的服务器
- 随机
- 加权：分配weight，weight越小，被选中的可能性越低
- 区域感知轮询：复合判断server所在区域的性能和server的可用性选择server
服务容错保护Hystrix
服务间调用的时候回出现调用超时(网络问题)，调用失败等问题。如果没有容错保护机制，整个微服务体系可能会因为某一个服务不可用而不可用，hystrix就是来保证微服务体系高可用性的组件。
资源隔离
线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
- 线程池隔离：为每个依赖服务申请线程池，对应的服务用自己的线程池里面的线程来执行，多个服务之间互不影响。
- 信号量隔离：使用一个原子计数器（或信号量）记录当前服务有多少个线程在运行，超过信号量的最大值则丢弃请求。
熔断
Hystrix会将服务调用结果（成功，失败，拒绝，超时）等信息报告给断路器，断路器会根据这些数据来更改断路器的状态。
断路器状态
- Closed：服务调用正常情况
- Open：服务调用异常，断路器统计后达到打开断路器的条件，后面再有服务调用，直接拒绝
- Half-Open：断路器打开一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到Open状态，如果调用成功，则回到Closed状态
断路器开启关闭条件：
- 当满足一定的阀值的时候（默认10秒内超过20个请求次数）
- 当失败率达到一定的时候（默认10秒内超过50%的请求失败）
- 到达以上阀值，断路器将会开启
- 当开启的时候，所有请求都不会进行转发
- 一段时间之后（默认是5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启。重复4
降级
服务调用失败后Hystrix提供降级方案，有下面两种方案：
- 快速返回静态值（常用）
- 访问备用服务，查询DB，缓存等
缓存
hystrix提供缓存功能，同样服务请求调用，根据cacheKey来判断是否从缓存中读取
声明式服务调用Feign
Feign是一个声明式的Web Service客户端，它整合了Ribbon和hystrix。Feign提供了HTTP请求的模板，通过编写简单的接口和插入注解，就可以定义好HTTP请求的参数、格式、地址等信息。我们在实际微服务开发过程中就是使用Feign，不会xianshi
Feign特性
- 注解实现
- 支持hystrix功能（熔断，fallback降级等）
- 支持ribbon功能（负载均衡）
- 请求GZIP压缩
网关服务Zuul
在微服务架构中，我们通过Feign来实现服务间调用，但有些服务需要提供对外访问接口，Zuul就是来提供这个功能的。Zuul主要提供两个功能，路由配置和请求过滤，Zuul和feign一样整合了Ribbon和Hystrix包，提供负载均衡和熔断等功能。由于所有的外部访问都会首先通过网关，所以网关还可以很方便的提供统一鉴权和监控的功能。
路由配置
下面的单实例和多实例配置可以帮忙转发请求到对应IP和端口。但由于eureka保存了服务名和对应服务访问的端口和IP，我们也可以配置路由规则和服务名对应起来，而且zuul默认添加了路由规则和服务名对应的路由。zuul还提供各种路由匹配规则，像通配符匹配，忽略表达式，路由前缀等等。
单实例配置
如下，符合/user-services/**规则的路由转发到http://localhost:8080/
zuul.routes.user-service.path=/user-services/**
zuul.routes.user-service.url=http://localhost:8080/多实例配置
符合/user-services/**规则的路由转发到http://localhost:8080/,http://localhost:8081/，同时依赖ribbon实现了负载均衡。
zuul.routes.user-service.path=/user-services/**
zuul.routes.user-service.serviceId=user-service
ribbon,eureka.enabled=false
user-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081/服务路由默认规则
如果每一个服务都要定义服务路由规则也实在太麻烦了，所以Eureka上的服务默认都会被Zuul自动创建路由规则。默认路由规则如下，符合/user-services/**规则的路由访问user-service服务。
zuul.routes.user-service.path=/user-services/**
zuul.routes.user-service.url=user-service请求过滤
过滤器类似于Spring filter功能，zuul过滤器负责对请求的处理过程进行干预，实现请求的校验，监控等功能。
filter type
以下提供四种标准的Filter类型及其在请求生命周期中所处的位置：
- PRE Filter：在请求路由到目标之前执行。一般用于请求认证、负载均衡和日志记录。
- ROUTING Filter：处理目标请求。这里使用Apache HttpClient或Netflix Ribbon构造对目标的HTTP请求。
- POST Filter：在目标请求返回后执行。一般会在此步骤添加响应头、收集统计和性能数据等。
- ERROR Filter：整个流程某块出错时执行。
filter特征
- Type：用以表示路由过程中的阶段（内置包含PRE、ROUTING、POST和ERROR）
- Execution Order：表示相同Type的Filter的执行顺序
- Criteria：执行条件
- Action：执行体
Zuul请求生命周期
配置中心Config
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。Spring Cloud Config就是Spring Cloud微服务架构提供的配置中心。它包含了Client和Server两个部分，server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client通过接口获取数据、并依据此数据初始化自己的应用。Spring cloud使用git或svn存放配置文件，默认情况下使用git。spring-boot-starter-actuator监控模块，提供/refresh接口实现客户端应用配置信息的重新获取与刷新。
客户端启动获取流程：
- 启动时，根据bootstrap.properties中的配置的应用名，环境名，分支名向config server请求获取配置信息
- Config Server根据传递过来的配置信息去查找配置信息
- git clone命令下载配置信息到Config Server的文件系统中
- Config Server读取配置信息并返回到客户端
- 客户端优先加载外部配置文件，Jar包的重复内容不再被加载
消息总线Bus
我们如果要去更新所有微服务的配置，如何避免向一个个服务发送Post请求来通知更新。这时候我们就不要忘记消息队列的发布订阅模型。这时Bus消息总线就能解决，你只需要在springcloud Config Server端发出refresh，就可以触发所有微服务更新了。Spring Cloud Bus需要配合RabbitMQ或者Kafka来实现。Bus提供微服务架构中的发布订阅功能，利于配置更新或者其他的一些需要让所有客户端知道的管理操作。
客户端下面的架构图，我们来简单整理一下整个客户端配置更新的流程
- 配置中心服务端更新配置
- 配置中心服务端发送更新消息到Bus（RabbitMQ或者Kafka）
- 客户端接受消息
- 客户端请求最新配置更新到内存完成配置的更新
架构图：
