SpringCloud与SpringCloudAlibaba的比较

最新推荐文章于 2024-10-09 08:32:03 发布

额无语

最新推荐文章于 2024-10-09 08:32:03 发布

阅读量814

点赞数

分类专栏： java 文章标签： spring cloud eureka java linux maven

本文链接：https://blog.csdn.net/m0_67266585/article/details/126597177

版权

java 专栏收录该内容

289 篇文章 11 订阅

订阅专栏

一. 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就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， 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除了降级和熔断功能外，还可以配置限流规则、热点规则、系统规则，且规则的配置项更多更精确，使用更加灵活

参考文章：https://blog.csdn.net/qq_41889508/article/details/89526874utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=1619604578378_82005&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control