微服务与微服务架构
微服务的优缺点
优点
缺点
Dubbo与Spring Cloud
Spring Cloud Netflix
Eureka
Eureka的自我保护机制
Eureka和ZooKeeper的区别
简单对比一下CAP和ACID
Ribbon
Ribbon内置的七大负载均衡算法
Feign
Hystrix断路器
服务雪崩、熔断与降低
Zuul
Config分布式配置中心
先简单了解一下微服务相关知识
微服务架构是一种架构模式,提倡将单一应用划分成一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合。服务之间采用轻量级的通信机制交互(基于HTTP的RESTful API)。
微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,从技术角度来看就是一种小而独立的处理过程,类似于进程概念,能够自行单独启动或销毁,拥有各自的数据库。
比如医院中的科室:内科,外科,心脑血管科,耳鼻喉科等。微服务强调的是个体,微服务架构强调的是整体,是把一个个的微服务整合起来,对外暴露,是一个整体。
Apache Dubbo 最初在 2008 年由 Alibaba 捐献开源,很快成为了国内开源服务框架选型的事实标准框架 ,得到了各行各业的广泛应用。在 2017 年,Dubbo 正式捐献到 Apache 软件基金会并成为 Apache 顶级项目,目前已经发展到了Dubbo3.x的版本, 是一款 RPC 服务开发框架。 利用 Dubbo 提供的丰富服务治理特性,可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。
Spring Cloud是一系列框架的整合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。其中最出名的就是Spring Cloud Netflix和Spring Cloud Alibaba两大类。
Dubbo是基于RPC形式的通信,而Spring Cloud是基于Rest形式的通信,其对比如下
Dubbo | SpringCloud | |
服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务监控 | Dubbo-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更为灵活,在强调快速演化的微服务环境下,显得更加合适。
Spring Cloud的功能比Dubbo更加强大,可以与其他Spring项目完美融合
Spring Cloud Netflix最出名且最常用的五大组件分别是
Eureka是Netflix的一个子模块,也是核心模块。Eureka是一个基于Rest的服务,用于定位服务,以实现云端中间层服务发现和故障转移。功能类似于Dubbo的注册中心(Zookeeper)。包含两个组件:Eureka Server和Eureka Client
某一个微服务不可用了,eureka不会立刻清理,依旧会对该微服务的信息进行保存。在自我保护模式中,Eureka Server会保护服务注册表中的信息,不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时,该Eureka Server节点就会自动退出自我保护模式。设计初衷就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例。
使用自我保护模式,可以让Eureka集群更加的健壮、稳定。可以使用eureka.server.enable-self-preservation=false 禁用自我保护模式
著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。
Zookeeper保证的是CP(一致性和分区容错性)、Eureka则是AP(可用性和分区容错性)。
当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于leader选举时间过长,30~120s,且选举期间zk集群都是不可用的,这会直接导致选举期间注册服务瘫痪。这是不可容忍的。
Eureka在设计优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依赖可以提供注册和查询服务。如何某个Eureka注册失败,则自动切换至其他节点,所以只要有一台Eureka还在,就能保证注册服务可用,只是查到的信息可能不是最新的。
提供客户端的软件负载均衡算法。Ribbon会自动根据配置的某个负载算法去连接机器,也可以自定义负载均衡算法。
是一个声明式的Web服务客户端,使得编写Web服务客户端变得非常容器。只需要创建一个接口,然后在上面添加@FeignClient注解即可。
Hystrix能保证在一个依赖服务出现问题的时候,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控,向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,从而避免了服务故障的蔓延。给予事先定义的响应结果,总比直接报错也友好的多
包含了对请求的路由和过滤两个最主要的功能
Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul跳转后获得。Zuul服务最终还是会注册进Eureka。
Zuul、Eureka、微服务之间的关系,就类似于小区保安,小区物业和业主的关系,物业知道有哪些业主,业主需要去物业登记,当请求(外卖或物业)保安根据物业登记的业务住址,告诉请求(外卖或物业)该前往那栋楼。
Spring Cloud为微服务架构中的微服务提供集合化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
当需要改变或添加环境配置时,之前的常规操作,都是需要打包重启服务,才能读取到最新的配置信息,而使用Spring Cloud Config可以进行非常灵活的配置,实时生效