Dubbo服务治理框架解析-优快云博客

本文深入探讨了Dubbo服务治理框架的背景、需求及架构，解析了其在分布式服务架构中的角色，如Provider、Consumer、Registry和Monitor，以及它们之间的交互关系。介绍了Dubbo的特性，包括连通性、稳健性和可扩展性。

引言

首先这里介绍一下Dubbo这个框架的官方网站。http://dubbo.apache.org/en-us/ ，提供一个开发文档的地址 http://dubbo.apache.org/en-us/docs/user/quick-start.html 也可以通过一下的命令来获取到源码

git clone https://github.com/apache/incubator-dubbo.git dubbo

当然了以上这些简单的介绍都是来自上面提到的官方的网站，dubbo这个框架之前由阿里巴巴开发的，但是后来不维护了，所以就有了Dubbox的出现。当然了在上一篇文章也提到了这种服务治理的框架除了Dubbo框架之外，还有一个比较有名的就是SpringCould Eureka。这个也是可以与Dubbo相提并论的一个服务治理组件。

Dubbo背景（个人翻译总结）

随着Internet的快速发展，Web应用程序的规模不断扩大，最终我们发现传统的垂直架构（单片机）无法再解决这个问题。分布式服务架构和流量计算架构势在必行，迫切需要一个治理系统来确保架构的有序演进。如图所示
在这里插入图片描述

单一应用架构

当网站流量很小时，只需要一个应用，将这些功能都部署到一起，从而减少了节点部署的成本
另外一个问题就诞生了，用于简化对于增删改查工作的的数据访问框架（ORM 对象关系映射），就是关键点。

垂直应用架构

当访问量逐渐增大，单一应用通过增加机器带来的作用也越来越少，这个时候就需要将应用拆分成为一个不相关的应用，来提升效率
这个时候就需要一个加速前端页面开发的Web框架（MVC）。

分布式服务框架

当垂直的应用越来越多，应用之间的交互是不可避免的，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。使得前端更容易实现多变的市场需求
这个时候就需要出现提高服务复用的分布式服务调用框架（RPC）。

流动计算框架

服务越来越多，对于容量的评估，小服务资源的浪费的问题也越来越严重，这个时候就需要添加一个服务调度中心基于访问压力实时管理集群容量，提高集群的利用率
这就需要提高机器利用率的资源调度和治理中心（SOA）。

介绍完上面这些之后，还有提到一个概念，就是在之前的博客中写道的关于微服务架构。因为在之前的博客中可以看到所以这里就不在过多的去介绍微服务相关的东西，微服务现在也是一个比较火的概念。

Dubbo要求（个人翻译总结）

在这里插入图片描述
这张图是关于Dubbo服务治理的需求

1、当服务越来越多的时候，服务的URL配置管理变得非常的困难，F5负载均衡的单点压力也越来越大

2、进一步的发展，服务间的依赖关系变得错综复杂，有时候都分不清楚那个应用要在那个应用之前启动，架构师都不能完整的描述整个应用的架构

3、接着服务调用量不断增加，服务容量就成为一个新问题，整个服务需要多少机器作为支撑，什么时候要扩展机器

以上这些问题都是需要考虑的。考虑完成这些问题之后我们比较关注的一个地方就来了。那就是dubbo的架构，了解了Dubbo的架构，然后在来看Dubbo的源码就比较容易了。

Dubbo架构（个人翻译总结）

在进入到Dubbo官网的时候会看到一张图，这张图就是Dubbo的架构图，只不过网上比较流行的是这张图。
在这里插入图片描述
首先介绍一下各个节点在整个服务架构中扮演了什么样的角色

Provider 暴露服务的服务提供方
Consumer 调用远程服务的服务消费方
Registry 服务注册于发现的注册中心（比较常用的注册中心就是Zookeeper，也可可以使用Redis不常用）
Monitor 统计服务的调用次数和调用时间的监控中心
Container 服务运行的容器（在服务运行起来的时候依赖这样的一个容器）
Admin 这个是没有体现出来的一个角色，但是在很多的应用中都有的，就是管控台。作用就是将这些服务注册之后怎么去管理这些东西，也就是说怎么进行服务治理。怎么去实现这些负载均衡等等的操作，或者其他的更加细致的配置。

到这里不得不说的就是上面提到的SpringCloud 中的Eureka组件。这个就是一个典型的服务治理的组件。有兴趣的话可以了解一下。

介绍完成角色扮演之后下面就介绍一下各个角色之间有什么样的关系。