一. SpringCloud组件的升级与替换

过去两年里,由于SpringCloud Netflix原先的一些组件进入停更维护状态，因此这些组件逐渐被一些新技术所替代

项目

替换前

替换后

服务注册中心

Eureka

Zookeeper、Consul、Nacos（推荐）

配置中心

Config

Nacos

服务总线

Bus

Nacos

负载均衡

Ribbon

LoadBalancer

服务调用

Feign

OpenFeign、Dubbo

服务网关

Zuul

gateway

服务降级

Hystrix

Sentinel

二. 服务注册中心的比较

根据CAP理论对注册中心进行分类：

  • 保证CP（注重一致性）：Zookeeper、Consul
  • 保证AP（注重可用性）：Eureka
  • 既支持CP又支持AP：Nacos

Zookeeper通过Zab协议保证强一致性：

  • 所有的写请求必须经过leader节点传递给其他follower节点。
  • 但是当leader节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证高可用性：

  • Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的(不保证强一致性)。
  • 此外，Eureka还有自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳（短时间内丢失过多客户端），那么Eureka就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：
  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Nacos既支持AP模式又支持CP模式：

  • AP模式：不需要存储服务级别信息且服务实例是通过nacos-clinet注册，且能够保持心跳上报，可采用AP模式。如SpringCloud服务。AP模式下只支持注册临时实例
  • CP模式：如需要在服务级别编辑或存储配置信息，则需使用CP模式，如K8S,DNS。AP模式下只支持注册持久化实例。

三. 服务调用框架的比较

Ribbon:
  • Ribbon是一套客户端负载均衡的工具，使用时需与RestTemplate配合使用
  • 使用是需要模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。
  • 负载均衡：支持轮询、随机、空闲策略、响应时间策略
OpenFeign
  • 同样使用HTTP协议进行通讯
  • 使用时只需创建一个接口并使用注解（@FeignClient)的方式配置， 即可完成对服务提供方的接口绑定，是对Ribbon+RestTemplate的进一步封装
  • OpenFeign内部集成了 Ribbon，本质上是通过Ribbon完成负载均衡功能
Dubbo
  • 支持多种传输协议：Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景
  • 负载均衡：支持随机、轮询、活跃度、Hash一致性，负载均衡的算法可以精准到某个服务接口的某个方法。

四. 服务降级框架的比较

1. 关于服务降级的概念
  • 服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的”雪崩效应”.
  • 服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。如Hystrix默认发现5秒内20次调用失败就会启动熔断机制。
  • 服务降级：某个服务故障后，向调用方返回一个符合预期的、可处理的备选响应（Fallback)。发生降级的场景：程序运行异常、服务调用超时、服务熔断、线程池/信号量被打满
  • 服务限流：限制服务的请求速率
2. Hystrix和Sentinel的比较
  • Hystrix本身就是一个非常出色的熔断降级框架，Sentinel则是在Hystrix的基础上对其进行进一步的升级
  • Sentinel使用更方便：Sentinel提供了一个非常简洁的控制台界面，在控制台界面中即可非常方便地配置限流降级规则
  • Sentinel功能更丰富：Sentinel除了降级和熔断功能外，还可以配置限流规则、热点规则、系统规则，且规则的配置项更多更精确，使用更加灵活