Spring Cloud（Spring复习四）

1. Spring Cloud之Eureka

• 作用：将应用根据不同的功能划分成不同的服务，方便维护和复用，但是服务如何找到需要的服务地址较为麻烦，在配置文件中写死，硬编码并不可取。该组件的功能就是提供一个服务的注册和发现的功能。特点：高可用，由以下几点保证，1.客户端会缓存服务的注册表信息，2.服务端会向客户端发起心跳，确认是否断开，3.可以存在多个服务端，他们之间的数据可以相互同步。
• 实现：
  • 创建Eureka Server（注册中心）
    1. 创建Maven工程
    2. 引入Cloud的依赖，加入eureka-server的包
    3. 编写启动类
    4. application.yml配置文件中进行配置
    5. 启动
  • 创建Eureka Client
    1. 创建Maven工程
    2. 引入Cloud的依赖，加入eureka-server的包
    3. 编写启动类，启动类上加入@EnableDiscoveryClient注解
    4. application.yml配置文件中进行配置服务端的地址，从而注册
    5. 注入DiscoveryClient,并通过服务ID获取服务实例，从而获取IP和端口
    6. 启动
• 原理：客户端将服务的信息注册到注册中心，Eureka Server会将这些信息存储在自己的注册表中，当有其他的Eureka Server注册时，注册表中的内容会进行同步，并且Eureka Server会定时对客户端发起心跳，确保客户端可用的状态。客户端也会缓存一份服务端的注册表，即使注册中心和客户端间出现网络故障，客户端依然能够找到需要的服务的地址，从而保证系统高可用。

springcloud(十三)：注册中心 Consul 使用详解

2. Spring Cloud之Ribbon

• 作用：可切换服务间调用的负载均衡算法

• 实现：

  1. 引入Ribbon的依赖
  2. 在定义RestTemplate的实例方法上加@LoadBalanced注解

• 原理：底层使用了拦截器，在调用服务时，会经过Ribbon的拦截器，将服务名解析为服务的地址：IP+端口的形式替换原有的服务名，从而完成调用

• 负载均衡的策略

策略类	命名	描述
RandomRule	随机策略	随机选择server
RoundRobinRule	轮询策略	按照顺序选择server（ribbon默认策略）
RetryRule	重试策略	在一个配置时间段内，当选择server不成功，则一直尝试选择一个可用的server
BestAvailableRule	最低并发策略	逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
AvailabilityFilteringRule	可用过滤策略	过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）
ResponseTimeWeightedRule	响应时间加权重策略	根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间
ZoneAvoidanceRule	区域权重策略	综合判断server所在区域的性能和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server

3. Spring Cloud之Hystrix

• 作用：解决因其中的一个服务挂掉而无法调用，导致级联故障，整个系统都无法使用，从而产生雪崩的结果，提供容错保护的机制，
• 实现：
  1. 引入Hystrix的依赖
  2. 在应用上加入@EnableHystrix注解
  3. 在调用服务的Service方法上加入@HystrixCommand注解，并标明备用方法
  4. 实现备用方法，调用即可
• 原理：发起请求通过Histrix线程池，不同的服务调用会走不同的线程池，实现了服务调用的隔离，在调用达到容错的阈值时，会调用备用的方法进行处理，避免级联故障

4. Spring Cloud之Feign

• 作用：使用Spring MVC申明式注解调用,基于Ribbon实现，有负载均衡的功能，还整合了Hystrix，但在Dalston版本中是关闭的
• 实现：
  1. 引入Feign的依赖
  2. 在应用上加入@EnableFeignClients注解
  3. 在调用服务的Service类上加上@FeignClient注解，标注服务名，并根据Spring MVC的注解格式注解接口的方法
  4. 调用服务，直接调用上述的接口方法即可
• 原理：通过动态代理实现，实际调用的是根据注解解析生成的一个代理，代理实现的功能是找到服务地址，调用后再将数据组装返回

5. Spring Cloud之Zuul

• 作用：对外提供统一的网关功能，统一的调用方式，校验、权限控制、负载均衡的功能
• 实现：
  1. 创建项目，引入zuul依赖
  2. 在应用上加入@EnableZuulProxy注解
  3. 配置路由规则
  4. 配置ZuulFilter
  5. 启动测试
• 原理：在服务调用前，先通过一层网关，统一封装了网关的功能

6. Spring Cloud之Config

• 作用：集中管理服务的配置，提高了复用性和维护性
• 实现：
  • 创建Config Server
    1. 引入Cloud的依赖，加入config-server的包
    2. 编写启动类
    3. application.yml配置文件中进行配置，配置获取配置文件的方式和位置
    4. 启动
  • 创建Config Client
    1. 引入Cloud的依赖，加入config和actuator(加入refresh配置的功能)的包
    2. bootstrap.yml配置文件中加入配置服务的地址，在application.yml配置文件中启用actuator
    3. 通过注解的方式引入配置，在类上加入@RefreshScope的功能
    4. 调用refresh请求会进行配置文件的刷新
• 原理（猜测）：客户端在启动时，会首先根据配置的Config服务取获取相应的配置文件，当收到refresh方法时，会再去获取一遍参数，进行更新

7. Spring Cloud之Bus

• 作用：统一的通知所有的服务或者配置的维度的服务
• 实现：
  1. 在conifg-server中加入bus-amqp依赖
  2. 配置文件中加入rabbitmq配置
  3. web-hook地址修改为config-server地址/bus/refresh
  4. 启动测试
• 原理：会将refresh统一分发出去

8. Spring Cloud与Dubbo区别

1. spring cloud集成的组件更多，本身含有注册中心，而dubbo的注册中心是zookeeper
2. 服务和注册中心间的连接协议不同，spring cloud是http，而dubbo的协议更加多样，基于长连接的方式交互，性能相对更好
3. spring cloud通过心跳通知服务的消费者，而zookeeper通过长连接通知服务的变更
4. dubbo是RPC，依赖关系更大，需要接口相同，而spring cloud是REST方式，更为轻量化，但是容易导致接口定义和文档不一致，但可通过swagger解决

dubbo