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组件。这个就是一个典型的服务治理的组件。有兴趣的话可以了解一下。

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

0 服务容器负责启动运行服务提供者
1 服务提供者在启动之后需要向注册中心提供自己的服务
2 服务消费者在启动的订阅自己需要的服务（这两者有点像发布订阅模式，但是实际上并不是发布订阅，当然在某种程度上可以理解为发布订阅）
3 注册中心返回服务提供者的列表中的服务提供者的信息给服务消费者，如果这个列表有变动的话可以通过长连接的方式将变动推给服务消费者。
4 服务消费者从提供者的列表中获取服务，当然这里提到一个概念就是负载均衡，例如权重、最多访问、或者是采用轮询的办法等等来实现。
5 服务消费者和服务提供者，在内存中累计调用的次数会通过健康机制发送给监控中心

接下来就是一些特性的介绍

连通性

注册中心负责服务地址的注册于查找，相当于目录服务，服务提供者和消费者只在启动的时候与注册中心交互，注册中心不转发请求，压力较小
监控中心负责统计服务调用的次数，调用的时间等等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并且以报表的形式展示
服务提供者想注册中心注册它提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
服务消费者向注册中心获取服务提供者的列表，并且根据负载均衡算法直接调用服务提供者，同时向监控中心汇报调用时间，此时时间包含网络开销
注册中心，服务提供者，服务消费者，三者之间都为长连接，监控中心除外
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送时间通知给消费者
注册中心和监控中心全部宕机，不会影响有运行的服务提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，消费者也可以直连服务提供者。

稳健性

监控中心宕机不影响使用，只是丢失部分的采样数
数据库宕机后注册中心仍然可以通过缓存提供服务列表查询，但不能注册新服务
注册中心对等集群，任意一台宕机之后，会自动切换到另一台
注册中心全部宕机之后，服务提供者和消费者任然可以使用本地缓存通讯
服务提供者无状态，任意一台宕机，不影响使用
服务提供者全部宕机，服务消费者将无法使用，并无限次重连等等服务提供者恢复

可扩展性

注册中心是一个可以动态增加其实例的对等集群，所有客户端都将自动发现新实例。
服务提供者是无状态的，它可以动态增加部署实例，并且注册表将新的服务提供者信息推送到服务消费者。

升级性

当服务集群进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有的框架不会带来任何阻力。

既然提到了就要提到图中的各个组件的是干什么的！

Deployer 自动服务部署的本地代理
Repository 存储库用于存储应用程序包
Scheduler 调度程序根据访问压力自动增加或减少服务提供者
Admin 统一管理控制台
Registry 注册表负责服务发现和配置
Monitor 监视器计算服务调用次数和耗时