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框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
注意:本文归作者所有,未经作者允许,不得转载