【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析

文章目录

    • 前言
    • 一、什么是微服务?
    • 二、Dubbo是什么?
      • 1.Ddubbo使用RPC实现服务输入输出
      • 2.RPC是什么 ?
      • 3.Dubbo工作原理(RPC框架)
    • 三、Spring Cloud是什么?
      • 1.Spring Cloud包含什么?
      • 2.Spring Cloud的五大核心组件
        • 2.1 Eureka
        • 2.2Ribbon
        • 2.3Feign
        • 2.4Hystrix
        • 2.5Zuul
    • 总结

前言

云原生(CloudNative)是一个组合词,Cloud+Native。Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。Cloud Native是一种应用程序开发风格,可鼓励在持续交付和价值驱动型开发领域轻松采用最佳实践。一个相关的学科是构建12要素应用程序,其中开发实践与交付和运营目标保持一致,例如,通过使用声明性编程,管理和监视。

云元素的四要素:

1.微服务:几乎每个云原生的定义都包含微服务,跟微服务相对的是单体应用,微服务有理论基础,那就是康威定律,指导服务怎么切分,很玄乎,凡是能称为理论定律的都简单明白不了,不然就忒没b格,大概意思是组织架构决定产品形态,不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后,服务解耦,内聚更强,变更更易;另一个划分服务的技巧据说是依据DDD来搞。

2.容器化:Docker是应用最为广泛的容器引擎,在思科谷歌等公司的基础设施中大量使用,是基于LXC技术搞的,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,谷歌搞的,Docker和K8S都采用Go编写,都是好东西。

3.DevOps:这是个组合词,Dev+Ops,就是开发和运维合体,不像开发和产品,经常刀刃相见,实际上DevOps应该还包括测试,DevOps是一个敏捷思维,是一个沟通文化,也是组织形式,为云原生提供持续交付能力。

4.持续交付:持续交付是不误时开发,不停机更新,小步快跑,反传统瀑布式开发模型,这要求开发版本和稳定版本并存,其实需要很多流程和工具支撑。


一、什么是微服务?

        作为云元素之首的微服务,它的架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。其中,Dubbo和Spring Cloud是两种比较主流的微服务架构。下面就来简单介绍下Dubbo和Spring Cloud。


二、Dubbo是什么?

-        Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。Dubbo是一种分布式服务框架(RPC框架)。


1.Ddubbo使用RPC实现服务输入输出

        在去选择技术框架时,技术框架最基本要解决上面现存问题,同时我们也要确认出我们的期望,要达到的目标是什么:

1.支持当前业务需求,这是最最基本的条件;
2.服务避免单点问题,去中心化;
3.服务高可用、高并发,解耦服务依赖;
4.服务通用化,支持异构系统调用服务;
5.服务依赖关系自维护,可视化;
6.服务性能监控自统计,可视化;
7.服务需自带注册、发现、健康检查、负载均衡等特性;
8.开发人员关注度高,上手快,简单轻量,低侵入;

        还有最重要一点,这也是往往很多技术人员进入的误区,“对于技术,不要为了使用而使用,用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的,能快速方便的满足业务需求的架构才是好的架构。所以Dubbo选择了RPC。
【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第1张图片


2.RPC是什么 ?

        分布式服务架构当垂直应用(Web框架 MVC)越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。 此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
可以实现RemoteProcedureCall 远程过程调用 。


3.Dubbo工作原理(RPC框架)

Dubbo的工作原理可分为5个组件及6个步骤:

5个组件:Container 服务容器(有时会忽视)、Provider 提供者 、Registry 注册中心 、Consumer 消费者和Monitor 监控中心。

6个步骤:Start 开始(发布)、Register 注册、Subscribe 订阅、Notify 推送、Invoke 调用缓存、统计 Count。

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第2张图片

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第3张图片

(1)Container 服务容器

(2)Provider 提供者

(3)Registry 注册中心 zookeeper

(4)Consumer 消费者

(5)Monitor 监控中心

0.服务容器Container 负责启动加载运行服务提供者Provider。(第一步start,就是将服务装载容器中,然后准备注册服务。和Spring中启动过程类似,spring启动时,将bean装载进容器中的时候,首先要解析bean。所以dubbo也是先读配置文件解析服务。)

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第4张图片

0.服务容器Container 负责启动加载运行服务提供者Provider。【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第5张图片

根据Provider配置的文件根据协议发布服务 , 完成服务的初始化.

1.Provider在启动时,根据配置中的Registry地址连接Registry,

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第6张图片

将Provider的服务信息发布到Registry,在Registry注册自己提供的服务。

2.Consumer在启动时,根据消费者XML配置文件中的服务引用信

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第7张图片

息,连接到Registry,向Registry订阅自己所需的服务。

3.Registry根据服务订阅关系,返回Provider地址列表Consumer,

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第8张图片

如果有变更,Registry会推送最新的服务地址信息给Consumer。

4.Consumer调用远程服务时,会根据路由策略,先从缓存Provider

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第9张图片

地址列表中选择一台进行,跨进程调用服务,假如调用失败,再重新选另一台调用。

5.服务Provider和Consumer,会在内存中记录调用次数和调用时

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第10张图片

间,每分钟发送一次统计数据到Monitor(异步请求)。


三、Spring Cloud是什么?

Spring Cloud通过多种特定方式促进了云原生发展方式。起点是一组功能,分布式系统中的所有组件都需要轻松访问这些功能。Spring Cloud建立在Spring Boot上,涵盖了许多这些功能。Spring Cloud作为两个库提供了更多功能:Spring Cloud上下文和Spring Cloud Commons。Spring Cloud上下文为Spring Cloud应用程序的ApplicationContext提供了实用程序和特殊服务(引导上下文,加密,刷新作用域和环境端点)。Spring Cloud Commons是在不同的Spring Cloud实现中使用的一组抽象和通用类(例如Spring Cloud Netflix和Spring Cloud Consul)。


1.Spring Cloud包含什么?

Spring Cloud包含配置管理工具、核心组件、消息总线、集群、消息驱动等…其中核心组件是Spring Cloud的关键。

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第11张图片


2.Spring Cloud的五大核心组件

2.1 Eureka

Eureka是微服务架构中的注册中心,专门负责服务的注册与发现。每个服务中都有一个Eureka Client组件,这个组件专门负责将这个服务的信息注册到Eureka Server中。就是告诉Eureka Server,自己在哪台机器上,监听着哪个端口。而Eureka Server是一个注册中心,里面有一个注册表,保存了各服务所在的机器和端口号。

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第12张图片

2.2Ribbon

简单说,Ribbon主要提供客户侧的软件负载均衡算法。和其他构成NIWS 内部进程通信栈的组件一起,该算法在 Netflix 经历了严峻考验。一般与 Eureka 一起使用,Eureka 主要用来平衡到中间层服务的请求。

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第13张图片服务间发起请求的时候,基于Ribbon做负载均衡,从一个服务的多台机器中选择一台。


2.3Feign

Feign是声明性的web服务客户端。它使编写web服务客户端更加容易。要使用Feign,请创建一个接口并对其进行注释。它具有可插入的注释支持,包括Feign注释和JAX-RS注释。Feign还支持可插拔编码器和解码器。Spring Cloud添加了对Spring MVC注释的支持,并支持使用Spring Web中默认使用的同一HttpMessageConverters。Spring Cloud集成了Ribbon和Eureka以在使用Feign时提供负载平衡的http客户端。

【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第14张图片基于Feign的动态代理机制,根据注解和选择的机器,拼接请求URL地址,发起请求。


2.4Hystrix

Hystrix有三个作用:
1.隔离:其他服务不会受到影响。
2.熔断:不会调用宕机的服务。
3.降级:在“脏”数据库修改数据。

        对于隔离来说,Netflix创建了一个名为Hystrix的库,该库实现了断路器模式。在微服务架构中,通常有多个服务调用层,较低级别的服务中的服务故障可能会导致级联故障,则电路断开并且无法进行呼叫。在错误和断路的情况下,开发人员可以提供备用功能。所以 Hystrix后备可防止级联故障,保障其他服务不受影响。
【云原生】微服务架构之Dubbo与Spring Cloud的原理剖析_第15张图片
        对于熔断和降级来说,如果一个服务宕机,当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。发起请求是通过Hystrix的线程池来走的,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题。
        因此,Hystrix三个作用基本上是同时发生的,这极大的解决了服务器宕机问题。


2.5Zuul

Zuul,也就是微服务网关。这个组件是负责网络路由的,如果前端、移动端要调用后端系统,统一从Zuul网关进入,由Zuul网关转发请求给对应的服务。


总结

微服务两大主流架构Spring Cloud 和Dubbo到此就讲完了,在云原生火热的今天,我们不得不去学习、巩固、加强自己的支持储备,让自己变得强大,微笑迎接充实的每一天。


注:本文章仅用于参考学习,如有错误,请大家指正。

你可能感兴趣的:(云原生,云原生,微服务,spring,cloud,架构,cloud,native)