dubbo少盲帖

作为测试经常会听到后端开发说起dubbo服务，dubbo服务到底使用干啥，查阅了网上资料再次简单介绍下（不涉及代码）

按用户人数，通过用一个图来具体说明架构和开发框架的演进过程

image.png

• 单一应用架构
  当网站流量较小，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用户简化增删改查的数据访问框架（ORM，object-relational mapping 对象关系映射）是关键。
  如Django的model举例：

from django.db import models
class User1(models.Model):
    name = models.CharField(max_length=225)

对应的数据库中可能就是一个表：user，里面有一个字段。
如有个User的实例，如：

user = User1()
user.name = 'jc'
user.save() //保存数据库

那么对应着数据可中就有一条记录，name为jc。此时的user实例，对应的正是这个表的一条记录
使用ORM的好处就是不用操作表，可以在程序中用面向对象的思路，直接操作对象即可。如上述代码，插入一条记录，直接 user.save()。对应ORM会帮助我们生成一条SQL语句。

Insert into user1(name) values('jc')

• 垂直应用架构
  当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC,模型，视图，控制器)是关键。

• 分布式服务架构
  当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC，Remote Procedure Call)是关键。
  RPC-远程过程调用，它是一种通过网络从远程计算机上请求服务，而不需要了解底层网络技术的协议。RPC采用客户机和服务器模式。请求程序是一个客户机，而服务提供程序就是一个服务器。
  1.客户机调用进程发送一个进程参数的调用信息到服务进程然后等待应答消息
  2.服务端，经常保持睡眠直到调用信息到达为止
  3.当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息
  4.客户端调用进程接受答复信息，获取进程结果，然后调用执行进行

• 流动计算架构
  当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA，Service Orirnted Architecture面向服务框架)是关键。

Dubbo服务原理

下图是从Dubbo官网直接拿来的，看一下基于RPC层，服务提供方和服务消费方之间的调用关系，如图所示

image.png

Provider：暴露服务的服务提供方
Consumer：调用远程服务的服务消费方
Registry：服务注册与发现的注册中心
Monitor：统计服务的调用次数和嗲用时间的监控中心
Container：服务运行容器

调用关系说明：

• 0：服务容器负责启动，加载，运行服务提供者
• 1：服务提供者在启动时，向注册中心注册自己提供的服务
• 2：服务消费者在启动时，向注册中心注册自己所需的服务
• 3：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
• 4：服务消费者，从提供者地址列表中，基于软负载均衡算法，选择一台提供者进行调用，如果调用失败，再选另一台调用
• 5：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo架构采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色。另外Dubbo架构还具有以下几个特点，连通性、健壮性、伸缩性、升级性，有关注册中心、协议支持、服务监控等内容，也在特点里有详细的描述。

连通性(服务消费者和服务提供者的关联)

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

健壮性(任意节点宕掉后，服务仍然可用)

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

伸缩性(节点可以自动增加)

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

升级性(可平滑升级)

当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，不会给现有分布式服务架构带来阻力。