云倾万里

无人问津的港口,总是开满鲜花

0%

SpringCloud相关知识点

什么是微服务?什么是微服务架构?

微服务强调的是服务的大小,关注的是某一个点, 是具体解决某一问题的服务应用,狭义的可以看做IDEA中的一个个微服务工程,一个个Moudel。

微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底的解耦,一个服务做一件事情。从技术角度来看就是一种小二独立的处理过程,类似进程的概念,能够自行单独启动或销毁,可以拥有自己独立的数据库。

微服务架构是一种新的架构形式,Martin Fowler提出,是一种架构模式,它提倡单一应用程序划分成一组小的服务,服务之间互相协调,互相配合。每个服务运行在独立的进程中,服务与服务间采用轻量级的通信机制互相协作,每个服务都围绕具体的业务进行构建,并且能够独立的部署到生产环境中。

Spring Cloud和Spring Boot的关系?

  • spring boot专注于快速方便的开发单个个体微服务。(很多个Jar包)
  • spring cloud是关注全局的微服务协调整理治理框架,它将spring boot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供:配置管理,服务发现,断路由,路由,微代理,事件总线,全局锁,决策竞选,分布式会话等等继承服务。
  • springboot可以离开springcloud独立使用,开发项目,但是springcloud离不开springboot,属于依赖关系。
  • springboot专注于快速,方便的开发单个个体微服务,springcloud关注全局的服务治理框架

Dubbo和SpringCloud技术选型和两者区别

  1. 分布式+微服务Dubbo

    目前成熟的互联网架构:应用服务拆分+消息中间件

image-20211003144425884

Dubbo Spring
服务注册中心 Zookeeper Spring Cloud Netflix Eureka
服务调用方式 RPC REST API
服务监控 Duboo-monitor Spring Boot Admin
断路由 不完善 Spring Cloud Netflix Hystrix
服务网关 Spring Cloud Netflix Zuul
分布式配置 Spring Cloud Config
服务跟踪 Spring Cloud Sleuth
消息总线 Spring Cloud Bus
数据流 Spring Cloud Stream
批量任务 Spring Cloud Task

最大区别:SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式

这两种方式各有优势,虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题,而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适

解决的问题域不一样:Dubbo的定位是一款RPC框架,SpringCloud的目标是微服务架构下的一站式解决方案


Eureka服务注册与发现

作为服务注册中心,Eureka比Zookeeper好在哪里

著名CAP理论指出,一个分布式系统不可能同时满足C(一致性),A(可用性),P(容错性)。

由于分区容错性P在分布式系统中是必须要保证的,因此我们只能在A和C之间进行权衡

  • Zookeeper保证的是CP
  • Eureka保证的是AP

Zookeepr保证的是CP

​ 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性,但是Zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30~120s,且选举期间整个Zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,在云部署的环境下,因为网络问题使得Zk集群失去master节点是较大概率会发生的事件,虽然服务最终能够恢复,但是漫长的选举事件导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

​ Eureka看明白了这一点,因此在设计时就优先保证可用性,Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余节点依然可以提供注册和查询服务,而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务的可用性 ,只不过查到的信息可能不是最新的,除此之外,Eureka还有一种自我保护机制,如果在15分超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况

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

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

Welcome to my other publishing channels