首页  

SpringCloud与SpringCloud Alibaba的区别     所属分类 springcloud 浏览量 274
Nacos=分布式配置中心+分布式注册中心=Eureka+Config


组件 /	SpringCloud	 / SpringCloud Alibaba
服务注册中心	   Eureka	 Zookeeper、Consul、Nacos(推荐)
配置中心	      Config	Nacos
服务总线(消息总线)Bus	      Nacos
负载均衡	      Ribbon	LoadBalancer
服务调用	      Feign	    OpenFeign、Dubbo
服务网关	      Zuul	    Gateway
服务降级(熔断降级)Hystrix	                              Sentinel(流量控制、熔断降级、系统负载保护)
服务跟踪(链路追踪)Sleuth&Zipkin	                       SkyWalking
分布式事务	      无(第三方替代方案:2pc)	                Seata
分布式任务调度	   无(第三方替代方案:xxl-job)	             SchedulerX
消息中间件	      无(第三方替代方案:RabbitMQ)	            RocketMQ
批量任务	      SpringCloudTask	                    SpringCloudTask
数据流	          Stream	                            无
服务安全	      Security或(第三方替代方案:Shiro)	       Security


服务注册中心比较 根据CAP理论对注册中心进行分类 保证CP(注重一致性):Zookeeper、Consul 保证AP(注重可用性):Eureka 既支持CP又支持AP:Nacos Zookeeper通过Zab协议保证强一致性 所有的写请求必须经过leader节点传递给其他follower节点。 但是当leader节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。 问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。 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模式下只支持注册持久化实例。
服务调用框架比较 1、Ribbon Ribbon是一套客户端负载均衡的工具,使用时需与RestTemplate配合使用。 使用是需要模拟http请求然后使用RestTemplate发送给其他服务,步骤比较繁琐。 负载均衡:支持轮询、随机、空闲策略、响应时间策略。 2、OpenFeign 同样使用HTTP协议进行通讯。 使用时只需创建一个接口并使用注解(@FeignClient)的方式配置, 即可完成对服务提供方的接口绑定,是对Ribbon+RestTemplate的进一步封装。 OpenFeign内部集成了 Ribbon,本质上是通过Ribbon完成负载均衡功能。 3、Dubbo 支持多种传输协议:Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景。 负载均衡:支持随机、轮询、活跃度、Hash一致性,负载均衡的算法可以精准到某个服务接口的某个方法。
服务降级框架的比较 Hystrix和Sentinel的比较 Hystrix本身就是一个非常出色的熔断降级框架,Sentinel则是在Hystrix的基础上对其进行进一步的升级。 Sentinel使用更方便:Sentinel提供了一个非常简洁的控制台界面,在控制台界面中即可非常方便地配置限流降级规则。

上一篇     下一篇
PromQL group_left 用法

rabbitmq 基础

nacos 配置安装

prometheus http_sd_config 基于http服务发现

简单家常菜

flink prometheus 监控指标