Dubbo入门

背景

架构的演化过程：

• 当流量非常低时，只打包成一个应用程序，所有功能都部署在一起，以减少部署的节点和还能控制成本。此时，应用属于单一应用架构，数据访问框架（ORM）是简化CRUD工作负载的关键。
• 随着流量逐渐变大时，添加单体应用程序实例无法很好地加速访问，提高效率的一种方法是将单体架构拆分为离散应用程序。此时，用于加速前端页面开发的Web框架（MVC）是关键。这种架构叫垂直架构
• 当出现越来越多的垂直应用程序，应用程序之间的交互是不可避免的，一些核心业务被提取并作为独立服务，逐步形成一个稳定的服务中心，这样前端应用程序可以更快地响应市场需求的变化。此时，**用于业务重用和集成的分布式服务框架（RPC）**是关键。这种架构叫分布式服务架构
• 当服务越来越多时，容量评估变得困难，小规模的服务也经常导致资源浪费。为了解决这些问题，应该添加一个调度中心来管理基于流量的集群容量，并提高集群的利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。此时项目架构演变成了流量计算架构

需求

在大规模服务化之前，应用可能只是简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。

当服务越来越多时，配置服务URL变得非常困难，F5硬件负载均衡器的单点压力也在增加。此时，需要服务注册中心来动态注册和发现服务，以使服务的位置透明。通过获取消费者端的服务提供商的地址列表，可以实现软负载平衡和故障转移，这减少了对F5硬件负载的依赖性和一些成本。

进一步发展，服务依赖性变得如此复杂，以至于甚至无法确定之前启动哪些应用程序，即使架构师也无法完全描述应用程序架构关系。这时，需要自动绘制应用程序的依赖关系图，以帮助架构师明确关系。

然后，服务的调用量越来越大，服务的容量问题暴露出来，需要多少台机器才能支持这项服务？什么时候应该添加机器？要解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

总结Dubbo 最基本的几个需求：

• 服务注册与发现
• 自动管理应用程序的依赖关系
• 服务调用统计和服务容量评估

架构

结点的规范

节点	规范
provider（提供者）	提供者展示远程服务
consumer(消费者)	消费者请求远程服务
Registry(注册中心)	注册中心负责服务发现和配置
monitor（监视中心）	监视器计算服务调用的数量以及耗时
Container（服务容器）	容器管理服务的生命周期

服务关系

• 服务容器负责启动，加载和运行服务提供者。
• 服务提供者在启动时将其服务注册到注册中心。
• 服务消费者在注册时会从注册中心订阅所需的服务。
• 注册中心将服务提供者列表返回给消费者，如果有变更，注册中心将通过长连接将更改的数据推送到消费者。
• 消费者基于软负载平衡算法从提供者地址列表中，选择一个提供者并执行调用，如果失败，它将选择另外的提供者。
• 服务消费者和提供者在内存中累计调用次数和调用时间，并且每分钟都会将统计信息发送给监控中心。

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

连通性

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

健壮性

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

伸缩性

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

升级性

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

节点角色说明

节点	角色说明
Deployer	自动部署服务的本地代理
Repository	仓库用于存储服务应用发布包
Scheduler	调度中心基于访问压力自动增减服务提供者
Admin	统一管理控制台
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心

用法

本地服务 Spring 配置

local.xml:

<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
    <property name=“xxxService” ref=“xxxService” />
</bean>

远程服务 Spring 配置

将上面的 local.xml 配置拆分成两份，将服务定义部分放在服务提供方 remote-provider.xml，将服务引用部分放在服务消费方 remote-consumer.xml。
remote-provider.xml:

<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” /> 
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” /> 

并在提供方增加暴露服务配置 <dubbo:service>，在消费方增加引用服务配置 <dubbo:reference>。
remote-consumer.xml:

<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”> 
    <property name=“xxxService” ref=“xxxService” />
</bean>

参考资料：
Dubbo官网