Dubbo概述

秦彦卿 1年前 ⋅ 1059 阅读

Dubbo是什么,解决哪些问题

背景

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

架构发展

单一应用架构

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

垂直应用架构

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

分布式服务架构

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

流动计算架构

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

Dubbo 解决什么问题

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

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

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

Dubbo 整体框架

 

 

Dubbo 怎么用

整体功能演示

  1. Server(provider)
  2. Client(consumer)
  3. Dubbo Admin
  4. 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 重要特性 -多版本

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

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

配置示例:

老版本服务提供者配置:
<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="*" />

重要特性-并发控制

  1. 限制 com.foo.BarService 的每个方法,服务器端并发执行(或占用线程池线程数)不能超过 10 个:
interface="com.foo.BarService" executes="10" /> 
  1. 限制 com.foo.BarService 的每个方法,每客户端并发执行(或占用连接的请求数)不能超过 10 个:
interface="com.foo.BarService" actives="10" />
  1. 配置服务的客户端的 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框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。


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

全部评论: 0

    我有话说: