【Dubbo】导读:初识 Dubbo 及课程概要

导读:初识 Dubbo 及课程概要

导读

一般业务系统发展历程都是基本相似的,从单体应用到多应用,从本地调用到远程调用。选择单体应用架构模式的,一般都是网络流量比较小,由于只需一个应用,所有业务的功能都打包为了一个 War 包进行部署,这样可以减少机器资源和部署的繁琐,但是单体应用由于不同的业务相互纠缠在一起,开发起来比较费劲,并且由于所有功能都在一个应用里面运行,如果一个业务出现导致 JVM 死掉的异常,那么整个应用的功能就都瘫痪了。

随着业务的发展,网站的流量会越来越大,简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低,这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用,单体应用拆为多个应用后,由于不同的应用开发对应的功能,所以多应用开发之间可以独立开发而不用去理解对方的业务,另外不同的应用模块只承受对应业务流量的压力,不会对其他应用模块造成影响。

经过拆分,单体应用变为了包含多个应用的分布式系统了,在单体应用时,不同业务模块相互调用直接在本地 JVM 进程内就可以完成,而变为多个应用时候,相互之间进行通信的方式就不能简单的进行本地调用了,因为不同业务模块部署到了不同的 JVM 进程里面,更常见的是部署到了不同的机器,这时候一个高效、稳定的 RPC 远程调用框架就变得非常重要,Dubbo 就是阿里巴巴开发的一个开源的高性能的远程服务调用框架,目前 Dubbo 已经进入了 Apache 卵化器项目,其前景可谓无限光明。

image.png

如上图是 Dubbo 的架构图,其中:

  • Provider 为服务提供者集群,服务提供者负责暴露提供的服务;
  • Consumer 为服务消费者集群,服务消费者通过 RPC 远程调用服务提供者提供的服务;
  • Registry 为服务注册与发现的注册中心;
  • Monitor 为统计服务的调用次数和调用时间的监控中心;
  • Admin-Console 为服务管理控制中心。

以上各个组件调用关系如下:

  • 服务提供方在启动时候会注册自己提供的服务到服务注册中心。

  • 服务消费方在启动时候会去服务注册中心订阅自己需要的服务,然后服务注册中心异步把消费方需要的服务接口的提供者的地址列表返回给服务消费方,服务消费方根据路由规则和设置的负载均衡算法选择一个服务提供者 IP 进行调用。

  • 监控平台主要用来统计服务的调用次数和调用耗时,服务消费者和提供者,在内存中累计调用次数和调用耗时,并定时每分钟发送一次统计数据到监控中心,监控中心则使用数据绘制图表来显示,监控平台不是分布式系统必须的,但是这些数据有助于系统运维和调优。服务提供者和消费者可以直接配置监控平台的地址,也可以通过服务注册中心来获取。

  • 管理控制台主要提供路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能。管理控制台直接与服务注册中心打交道,从服务注册中心获取所有注册的服务和消费方法;并且可以通过管理台界面设置服务消费端的路由规则、动态配置等信息并注册到服务管理台,这些信息会被通知到服务消费端。管理控制台也不是分布式系统必备的组件,但是有了它我们可以对服务进行很好的治理和监控

Dubbo 架构具有连通性、健壮性、伸缩性。

  • 连通性,服务注册中心负责服务的注册与发现,服务提供者和消费者只在启动时与服务注册中心进行交互,服务注册中心不转发请求,这减轻了服务注册中心压力和服务转发延迟;监控中心负责统计各服务调用次数、调用时间等,统计是先在内存进行,然后汇总后每分钟一次发送到监控中心服务器,监控中心绘制为报表的方式显示,服务提供者向服务注册中心注册其提供的服务,并汇报调用时间到监控中心,此时间不包含网络开销;服务消费者向服务注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,同时汇报调用时间到监控中心,此时间包含网络开销;注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外服务注册中心通过长连接感知服务提供者的存在,如果服务提供者宕机了,服务注册中心通过长链感知服务提供者挂了,就会立即推送事件到消费者,消费者则更新可用的服务列表,服务注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表,注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。

  • 健状性,监控中心宕掉不影响使用,只是丢失部分监控数据,服务注册中心的数据库宕掉后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务,注册中心对等集群,任意一台宕掉后,将自动切换到另一台,注册中心全部宕掉后,服务消费者仍能通过本地缓存的地址列表进行远程调用,服务提供者无状态,任意一台宕掉后,不影响使用,服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复。

  • 伸缩性,服务注册中心为对等集群,可动态增加机器部署实例,所有客户端将自动发现新的注册中心。服务提供者无状态,可动态增加机器部署实例,注册中心将推送新的服务提供者信息给消费者。

课程内容

工欲善其事必先利其器,要想研究 Dubbo 的原理实现,首先需要使用 Dubbo 搭建出一个分布式系统。

本教程首先手把手教大家如何在目前主流的三种不同环境下使用 Dubbo 搭建系统。首先介绍如何使用 Spring 配置方式方法来搭建,然后介绍如何使用 Dubbo API 方式来搭建,最后基于 SpringBoot 和 dubbo-spring-boot-starter 使用注解方式搭建服务提供者和消费者。这个系统虽然简单,但是会包含服务提供者、服务消费者、服务注册中心(本课程使用 ZooKeeper)、管理控制台(Dubbo-Admin)、监控平台(Dubbo-Monitor),麻雀虽小,却五脏俱全。

然后会给大家介绍 Dubbo 的一些使用特性,比如何为服务调用方的泛化调用,何为异步调用等。

最后会先从整体分析 Dubbo 的系统架构,然后讲解 JDK 标准 SPI 的实现原理,Dubbo 如何实现的增强 SPI,如何实现的扩展实现类之间依赖的自动注入,扩展点实现类是如何进行自动包装从而起到对扩展实现类进行功能的增强。Dubbo 提供了哪些集群容错方式,并讲解 Failover 集群容错的实现原理。然后讲解 Dubbo 提供了哪些负责均衡策略,并讲解一致性 Hash 负载均衡策略原理;Dubbo 提供了哪些线程模型,如何进行自定义配置等等。接着讲解服务提供方如何启动并发布服务到注册中心的,服务消费方又是如何从服务注册中心获取服务地址列表,并发起远程调用的。最后总结下实战中使用Dubbo 时候需要注意的一些事情。

猜你喜欢

转载自blog.csdn.net/harwey_it/article/details/80225560