SpringCloud-微服务组件

置顶 Accountant！

已于 2023-02-20 17:48:16 修改

阅读量272

点赞数 2

文章标签： spring cloud java 微服务

于 2022-07-28 13:38:57 首次发布

本文链接：https://blog.csdn.net/m0_57254201/article/details/126033052

版权

1、服务注册

1.1、Eureka

Netflix公司产品，Eureka集成了Ribbon
Eureka包含两个组件
1. Eureka Server
  - Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
2. Eureka Client
  - 是一个java客户端，用于简化与Eureka Server的交互，客户端同时也是一个内置的、使用轮询(round-robin)负载算法的负载均衡器
自我保护机制
- 应用启动后，每30s向Eureka Server发送心跳，若Eureka Server在90s内没有接收到某个节点的心跳，在服务注册表中把这个服务节点移除
- eureka.server.enable-self-preservation: false，关闭保护机制，默认开启
Eureka使用多级缓存支撑高并发，第一级是读写缓存，第二级是只读缓存；注册中心每30s把数据同步给这两个缓存，读的时候先去只读缓存中找，没有则再去注册中心找，写类似，因此Eureka实现了读写分离
Eureka若是单机环境，设置eureka.client.register-with-eureka为false（不需要把自己注册到注册中心，默认为true），设置eureka.client.fetch-registry为false（不需要从注册中心获取服务信息，默认为true）；若某个微服务只调用其他服务，不需要被其他服务调用，可设置eureka.client.register-with-eureka为false
CAP原则
- C（Consistency，一致性）：分布式环境下的多个节点间的数据一致
- A（Availability，可用性）：所有节点保持高可用，能快速响应，不能出现超时，也不能出错
- P（Partiton tolerance，分区容错性）：多个节点相互通信难免遇到网络故障时，分区容错性保证了系统可以继续正常服务
- CA：保证一致高可用，但没有分区容错性，只用在单体系统，不能用在分布式系统
- CP：为保证在多个系统中保持数据一致性，数据在多个系统中同步，此时分布式系统不能保证可用性；Zookeeper保证CP
- AP：为保证在多个系统中保持可用性，系统能快速响应，此时分布式系统不能保证一致性；Eureka保证AP

1.2、Zookeeper

雅虎公司产品
基于观察者模式设计的分布式服务管理框架，负责存储和管理数据，接受观察者的注册，一旦数据发生变化，zookeeper就将负责通知已经在zookeeper上注册的观察者做出反应
zookeeper由一个Leader和多个Follower组成，集群中只要有半数以上节点存活，zookeeper就能正常工作。
崩溃恢复包括两部分：
- Leader选举：一个Leader多个Follower，奇数台机器。每台机器启动时，先投自己一票，若此机器票数没有半数以上，则把投给自己的票转给zxid大的机器；若票数达到总机器数半数以上，则选取自己当Leader；
- 数据恢复：Leader把数据同步到Follower

1.3、Consul

HashiCorp公司产品
分布式、高可用、可横向扩展的用于实现分布式系统服务的服务发现与配置

1.4、Nacos

Spring Cloud Alibaba子项目，Nacos = Eureka + Config + Bus
Nacos提供基于DNS和基于RPC的服务发现，即能被用来支持http/https的服务注册与发现，也支持RPC和dubbo的服务注册与发现
Nacos是一种去中心化去中心化的架构，属于CAP理论里的AP架构，支持最终一致性C，在分布式服务发现与注册场景下具有很好的性能
默认情况下，注册到Nacos的实例都是临时实例，客户端每5s发给Nacos一次心跳保活；若超过15s没有收到客户端心跳，就会把实例标记为不健康状态；若超过30s没有收到客户端的心跳，就删除实例
@RefreshScope开启配置动态刷新
Nacos使用CopyOnWrite（写时复制技术）支撑高并发，读的是原来的注册中心，进行写的时候对副本进行操作，写完同步给原来的注册中心，因此实现读写分离

2、服务调用

2.1、Ribbon

Netflix公司产品，Eureka、OpenFeign、Hystrix都集成了Ribbon
基于HTTP和TCP协议，用来做客户端负载均衡
Ribbbon需要根据服务名实现负载均衡，而不是根据ip
集中式负载均衡，在consumer和provider间使用独立的负载均衡（Nginx）；进程内负载均衡，把负载均衡集成到consumer，consumer从服务注册中心选取合适的provider（Ribbon）
负载均衡策略，在Application Client配置类中添加策略，不能同时配置多个策略
1. RoundRobinRule：轮询策略（默认）
2. WeightedResponseTimeRule：权重轮询策略（常用，中小型项目）
  - 为每个Application Service的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低
3. RandomRule：随机策略（测试使用，开发不使用）
4. BestAvailableRule：最少并发数策略（应用在软硬件一致的情况下，中小型项目）
  - 选择请求并发数最小的Application Service
5. AvailabilityFilteringRule：可用性敏感策略
  - 过滤掉在eureka中处于一直连接失败的Application Service
  - 过滤掉高并发的Application Service
6. ZoneAvoidanceRule：区域性敏感策略（应用在大型分布式环境中）
  - 以一个区域考察可用性，对不可用的区域整个丢弃，从剩下区域中选可用的Application Service
  - 若这个区域有一个或多个实例不可达或响应变慢，都会降低该ip区域内其他ip被选中的权重

2.2、LoadBalancer

Spring Cloud子项目
负载均衡器，使用RestTemplate进行远程访问时加上@LoadBalancer实现负载均衡

2.3、Feign

Netflix公司项目，不再使用...

2.4、OpenFeign

Spring Cloud子项目，内部集成了Ribbon
一种声明式RESTful风格的HTTP客户端（声明式服务调用），同时支持SpringMVC的注解，可进行远程访问时的服务调用
声明式服务调用，就像调用本地方法一样调用远程方法，无需关注与远程的交互细节，更无需关注分布式环境开发，也不需要通过RestTemplate进行调用
流程
1. Service向服务中心进行注册
2. Client从服务中心发现服务信息
3. 在Client中调用OpenFeign接口中的方法
4. Client中OpenFeign通过应用程序名调用Service，OpenFeign中进行远程调用的方法参数前默认有@RequestBody注解
通讯优化
- 将传输的数据经过压缩（gzip）降低网络字节数，加快网页加载的速度
- 搜索引擎可直接读取gzip文件检索网页，速度更快
- 进行gzip传输数据只涉及Application Client端和Application Service端，不涉及客户端

3、服务降级

3.1、Hystrix

Netflix公司产品，Hystrix内部集成了Ribbon
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免会调用失败，比如超时、异常，Hystrix能保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性
降级
- “断路器”本身是一种开关装置，当某个服务单元发生故障后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（fallback，服务降级），而不是长时间等待或抛出调用方法无法处理的异常，保证了服务调用的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩
- Application Client端的启动类上需加上@EnableCircuitBreaker开启降级
- 方法上使用@HystrixCommand配置降级机制
  - fallbackMethod：指定回调方法，方法返回值和参数类型需要对应
熔断
- 应对服务雪崩效应的一种服务链路保护机制。当扇出链路的某个微服务出错不可用或相应时间太长时，进行服务降级，进熔断该节点微服务的调用，快速返回错误的相应信息
- 熔断机制过程：打开 -> 半开 -> 关闭
  - 打开：请求不在进行调用当前服务，内部设置时钟一般为MTTR（平均故障时间），打开时长达到设定时钟就进入半熔断状态
  - 半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务回复正常，关闭熔断
  - 关闭：熔断关闭不会对服务进行熔断，因此熔断有自动恢复机制
- Application Client端的启动类上需加上@EnableCircuitBreaker开启熔断
- 方法上使用@HystrixCommand配置熔断机制
  - fallbackMethod：指定回调方法，方法返回值和参数类型需要对应
  - commandProperties：指定熔断机制，每个机制使用@HystrixProperty
    - @HystrixProperty(name = "circuitBreaker.enabled",value = "true")
      - 开启熔断策略，默认开启
    - @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "20")
      - 单位时间内，请求次数超出多少则触发熔断，默认20次
    - @HystrixProperty(name = "execution,isolation.thread.timeoutInMilliseconds",value = "10000")
      - 单位时间，默认10s
    - @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "5000")
      - 当熔断策略开启后，多久尝试再次请求远程服务，默认5s
    - @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50")
      - 单位时间内，出现错误的请求百分比达到多少，触发熔断，默认50
降级和熔断区别：降级是出错返回托底数据，熔断是出错后若开启了熔断会在一定时间不再访问Application Service
服务限流
- 高并发情况下，为了防止某一时刻请求过多，设置某一时刻最大访问数
请求合并
- 把多个Application Client的请求合并为一个请求，可降低Application Service负载
隔离
- 线程池隔离
  - 优点：线程池之间不会相互影响，也解决高并发问题和限流问题
  - 缺点：增加CPU开销，不仅有tomcat线程池，也还有Hystrix线程池，线程之间的切换也需要消耗资源
默认情况下Feign的Hystrix没有开启，需要手动开启
- ```
feign:
  hystrix:
    enabled: true
```

3.2、Sentinel

Spring Cloud Alibaba子项目
把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保持服务的稳定性
解决的问题：服务雪崩、服务降级、服务熔断、服务限流
Sentinel与Hystrix的区别：Sentinel断路器在1.7版本没有半开状态，1.8版本后有半开状态
流控规则：
- 资源名：唯一名称，默认请求路径
- 针对来源：Sentinel可针对调用者进行限流，填写微服务名，默认dufault（不区分来源）
- 阈值类型/单机阈值：
  - QPS（每秒请求量）：当调用该API的QPS达到阈值时，进行限流
  - 线程数：当调用该API的线程数达到阈值的时候，进行限流
- 是否需要集群
- 流控模式：
  - 直接：API达到限流条件时，直接限流
  - 关联：当关联的资源达到阈值时，限流自己
  - 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就限流）
- 流控效果：
  - 快速失败：直接失败，抛异常
  - Warm up：根据coderFactor（冷加载因子，默认3）的值，从阈值/coderFactor，经过预热时长，才达到设置的QPS阈值
  - 排队等待：匀速排队，让请求匀速通过，阈值类型必须设置为QPS，否则无效
降级规则：
- RT（平均响应时间，秒）
  - 平均响应时间超出阈值且在时间窗口内通过的请求》=5，两个条件同时满足后触发降级
  - 窗口过期后关闭断路器
  - RT最大4900
- 异常比例（秒）
  - QPS>=5，且异常比例（秒）超过阈值，触发降级；时间窗口结束后，关闭降级
- 异常数（分种）
  - 出现异常的数量（分钟）超过阈值，触发降级；时间窗口结束后，关闭降级

3.3、Resilience4j

国外用的多，国内基本不用

4、服务网关

4.1、Zuul

Netflix公司产品，不再使用

4.2、Zuul2

Netflix公司产品，...

4.3、Gateway

SpringCloud子项目
Gateway功能：路由转发、权限校验、限流
Gateway相比Zuul，Gateway性能更高、功能更强大
Getway由WebFlux + Netty + Reactor实现的响应式API网关。因此Getway不能在传统的servlet容器中工作，也不能构建成war包
Getway提供统一的路由方式且基于Filter链的方式提供了网关的基本功能，如：安全认证、监控、限流

5、服务配置

5.1、Config

SpringCloud子项目
解决分布式系统的配置管理方案
在分布式环境中，很多服务都是集群部署，则这些集群部署的服务都需要相同的配置文件，此时可使用config组件进行众多的配置文件的统一管理

5.2、Nacos

Spring Cloud Alibaba子项目
Nacos = Eureka + Config + Bus

6、服务总线

6.1、Bus

SpringCloud子项目
用来管理和传播分布式系统的消息，像一个分布式执行器，可用于广播状态更改、事件推送，也可以当作微服务间的通信通道
总线：微服务架构中，一般使用轻量级的消息代理构建一个公用的消息主题，并让系统中所有微服务实例连接上来。由于该主题中产生的消息会被所有实例监听和消费，因此称它为消息总线。在总线上的各个实例，都可以方便的广播一些需要让其他连接在该主题上的实例都知道的消息
原理：Config实例都监听MQ中同一个topic。当一个服务刷新数据时，它会把这个信息放入topic，这样其它监听同一topic的服务就能得到通知，然后去更新自己的配置
只支持两种消息代理：RabbitMQ和Kafka