Dubbo是什么，解决哪些问题

背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

架构发展

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

垂直应用架构

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

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

流动计算架构

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

Dubbo 解决什么问题

在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

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

Dubbo 整体框架

Dubbo 怎么用

整体功能演示

Server（provider）
Client(consumer)
Dubbo Admin
Dubbo Monitor

服务端配置

"${dubbo.marketingCenter.app}" />  --用于配置当前应用信息  
“${dubbo.marketingCenter.registry}“  --注册中心地址
     protocol=”${dubbo.registry.protocol}” –注册协议  
     check=“${dubbo.registry.check}“  --启动时是否检查服务是否可用 
     file=”${dubbo.marketingCenter.file}” />--dubbo缓存文件使用文件缓存注册中心地址	列表及服务提供者列表，应用重启时将基于此文件恢复 
     “${dubbo.marketingCenter.protocol}“  --服务提供者协议  
     port=”${dubbo.marketingCenter.port}“ –服务提供端口   
     threadpool=”${dubbo.thread.pool}“   
     threads=”${dubbo.thread.amount}” />  
     “false”/> --启动时检查消费者是否可用
     “registry”/>监控中心协议，如果为protocol=“registry”，表示从注册中心发 					现监控中心地址，否则直连监控中心。  
     “com.gujinsuo.p2p.marketingCenter.client.CardClient” 
     ref=“cardClientImpl” loadbalance=“${dubbo.marketingCenter.loadbalance}“ –负载均衡测略
      retries=”${dubbo.marketingCenter.retries}”  
      executes=“${dubbo.marketingCenter.executes}“--服务提供者每服务每方法最大可并行执行请求数
      actives=”${dubbo.marketingCenter.actives}“ --每个客户端并发执行个数  
      delay="${dubbo.marketingCenter.delay}"/> --延迟注册服务时间(毫秒) ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务

客户端配置

     name="${dubbo.p2pOpen.app}" />
   address="${dubbo.p2pOpen.registry}" 
	protocol="${dubbo.registry.protocol}" check="${dubbo.registry.check}" file="${dubbo.p2pOpen.file}" />
	name="${dubbo.p2pOpen.protocol}" host="${dubbo.p2pOpen.host}" 
	port="${dubbo.p2pOpen.port}" threadpool="${dubbo.thread.pool}" threads="${dubbo.thread.amount}" />
	check="false"/>
	protocol="registry" />
	
	interface="com.gujinsuo.p2p.marketingCenter.client.CardClient" 
	id="cardClient" timeout="${dubbo.p2pOpen.timeout}" loadbalance="${dubbo.p2pOpen.loadbalance}" />

Zookeeper作用

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用

流程说明

服务提供者启动时: 向 /dubbo/com.gujinsuo.p2p.marketingCenter.client.CardClient/providers 目录下写入自己的 URL 地址
服务消费者启动时: 订阅 /dubbo/ com.gujinsuo.p2p.marketingCenter.client.CardClient /providers 目录下的提供者 URL 地址。并向 /dubbo/com.gujinsuo.p2p.marketingCenter.client.CardClient /consumers 目录下写入自己的 URL 地址
监控中心启动时: 订阅 /dubbo/com.gujinsuo.p2p.marketingCenter.client.CardClient目录下的所有提供者和消费者 URL 地址。

支持以下功能：

当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
当注册中心重启时，能自动恢复注册数据，以及订阅请求
当会话过期时，能自动恢复注册数据，以及订阅请求
当设置时，记录失败注册和订阅请求，后台定时重试
可通过设置 zookeeper 登录信息
可通过设置 zookeeper 的根节点，不设置将使用无根树
支持 * 号通配符，订阅服务的所有分组和所有版本的提供者

Dubbo 重要特性 -集群容错

Failover Cluster 失败自动切换，当出现失败，重试其它服务器
Failfast Cluster 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster 失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster 广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

Dubbo 重要特性 -多版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本

配置示例：

老版本服务提供者配置：
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
新版本服务提供者配置：
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
老版本服务消费者配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
新版本服务消费者配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
如果不需要区分版本，可以按照以下的方式配置 [1]：
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

重要特性-并发控制

限制 com.foo.BarService 的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：

interface="com.foo.BarService" executes="10" />

限制 com.foo.BarService 的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：

interface="com.foo.BarService" actives="10" />

配置服务的客户端的 loadbalance 属性为 leastactive，此 Loadbalance 会调用并发数最小的 Provider（Consumer端并发数）。

interface="com.foo.BarService" loadbalance="leastactive" />

Dubbo 深入理解

各层说明

config 配置层： 对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
proxy 服务代理层： 服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy为中心，扩展接口为 ProxyFactory
registry 注册中心层： 封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
cluster 路由层： 封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
monitor 监控层： RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService

-** protocol 远程调用层：** 封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter

exchange 信息交换层： 封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
transport 网络传输层： 抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
serialize 数据序列化层： 可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

Dubbo 学习资料和未来发展

Sentinel 为 Dubbo 服务保驾护航

官网：http://dubbo.apache.org/#!/docs/user/quick-start.md?lang=zh-cn
代码：https://github.com/apache/incubator-dubbo

总结

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

注意：本文归作者所有，未经作者允许，不得转载

Dubbo概述