dubbo的介绍
dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的RPC实现服务的输出和输入功能,可以和Spring框架无缝集成。
dubbo框架是基于Spring容器运行的。
RPC远程过程调用
远程过程调用协议是一种通过网络从远程计算机程序上请求服务,而不需要了解网络底层技术的协议。
RPC协议假定某些传输协议的存在,如TCP或者UDP,为通信程序之间携带信息数据。
在OSI网络通信模型中,RPC跨越了传输层和应用层。
RPC的优点:使得开发包括网络分布式多程序在内的应用程序更加容易。
dubbo角色介
注册中心(registry):生产者在此注册并发布内容,消费者在此订阅并接收发布的内容。
消费者(consumer):客户端,从注册中心获取到方法,可以调用生产者中的方法。
生产者(provider):服务端,生产内容,生产前需要依赖容器(先启动容器)。
容器(container):生产者在启动执行的时候,必须依赖容器才能正常启动(默认依赖的是spring容器),
dubbo技术不能脱离spring框架。2.5.3版本的dubbo默认依赖spring2.5版本,可以选用spring4.5以下的版本
2.5.7版本的dubbo默认依赖spring4.3.10版本,可以选择任意的spring版本。
监控中心(monitor):是dubbo提供的一个jar工程。主要功能是监控服务端和消费端的使用数据。
如:服务端是什么,有多少接口,多少方法,调用次数,压力信息等,客户端有多少,调用过哪些服务端,调用了多少次等。
dubbo执行流程(以上图为例)
0.start:启动Spring容器时,自动启动dubbo的Provider
1.register:dubbo的Provider在启动后自动会去注册内容。注册的内容包括:
1.1 Provider的IP
1.2 Provider的端口
1.3 Provider对外提供的接口、方法
1.4 dubbo版本号
1.5 访问Provider的协议
2.subscribe:订阅,当Consumer启动时,自动去Registry获取到所有已注册的服务信息
3.notify: 通知, 当Provider的信息发生变化时,自动由Registry向Consumer推送通知
4.invoke: 调用, Consumer调用Provider中的方法
4.1同步请求,消耗一定性能,但是必须是同步请求,因为需要接收调用方法后的结果
5.count: 次数, 每隔2分钟,Provider和Consumer自动向Monitor发送访问次数,Monitor进行统计。
升级性
当服务集群规模进一步扩大,带动IT治理结构进一步升级,需要实现动态部署,进行流动计算,现有分布式服务架构不会带来阻力。下图是未来可能的一种架构:
节点角色说明
节点 | 角色说明 |
---|---|
Deployer | 自动部署服务的本地代理 |
Repository | 仓库用于存储服务应用发布包 |
Scheduler | 调度中心基于访问压力自动增减服务提供者 |
Admin | 统一管理控制台 |
Registry | 服务注册与发现的注册中心 |
Monitor | 统计服务的调用次数和调用时间的监控中心 |
dubbo的工作原理
初始化过程细节:第一步,就是将服务装载到容器中,然后准备注册服务。和Spring中启动过程类似,Spring启动时,将bean装载进容器中的时候,首先要解析bean。所以dubbo也是先读配置文件解析服务。
解析服务:1)、基于dubbo.jar内的META-INF/spring.handlers配置,spring在遇到dubbo名称空间时,会回调DubboNamespaceHandler类。
2)、所有的dubbo标签都统一用DubboBeanDefinitionParser进行解析,基于一对一属性映射,将XML标签解析为Bean对象,生产者或者消费者初始化的时候,会将Bean对象转换为URL格式,将所有Bean属性转换成URL的参数。然后将URL传给Protocal扩展点,基于扩展点的Adaptive机制,根据URL的协议头,进行不同协议的服务暴露和引用。
暴露服务:1)、直接暴露服务端口:在没有注册中心的情况下,配置ServiceConfig解析出的URL,基于扩展点Adaptive机制,通过URL的协议头识别,直接调用DubboProtocol的export()方法,打开服务端口
2)、向注册中心暴露服务:将服务的IP和端口一同暴露给注册中心。ServiceConfig解析出的url格式,基于扩展点的Adaptive机制,通过URL的协议头识别,调用RegistryProtocol的export()方法,将export参数中的提供者URL先注册到注册中心,再重新传给Protocol扩展点进行暴露。
引用服务:1)、直接引用服务:在没有注册中心的情况下,直连提供者,ReferenceConfig解析出URL格式,基于扩展点的Adaptive机制,通过URL协议头识别,直接调用DubboProtocol的refer方法,返回提供者引用。
2)、从注册中心发现引用服务:ReferenceConfig解析出的URL的格式,基于扩展点的Adaptive机制,通过URL协议头识别,就会调用RegistryProtocol的refer方法,从refer参数总的条件,查询提供者URL,通过提供者URL协议头识别,就会调用DubboProtocol的refer()方法,得到提供者引用。然后RegistryProtocol将多个提供者引用通过Cluster扩展点,伪装成单个提供者引用返回。
服务提供与消费详细过程
暴露服务的主过程:
首先ServiceConfig类拿到对外提供服务的实际类ref,然后将ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到invoker的转化。接下来就是Invoker转换到Exporter的过程。 Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程,下面我们以Dubbo和rmi这两种典型协议的实现来进行说明: Dubbo的实现: Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法,它主要是打开socket侦听服务,并接收客户端发来的各种请求,通讯细节由dubbo自己实现。 Rmi的实现: RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法,他通过Spring或Dubbo或JDK来实现服务,通讯细节由JDK底层来实现。
服务消费的主过程:
首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例。接下来把Invoker转为客户端需要的接口。
Dubbo 要解决的需求
在大规模服务化之前,应用可能只是通过 RMI 或 Hessian 等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过 F5 等硬件进行负载均衡。
当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心,动态地注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。
当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。 这时,需要自动画出应用间的依赖关系图,以帮助架构师理清关系。
接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器? 为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阈值,记录此时的访问量,再以此访问量乘以机器数反推总容量。
Dubbo 的简单实用入门
本地服务 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
。 - 并在提供方增加暴露服务配置
<dubbo:service>
,在消费方增加引用服务配置<dubbo:reference>
。
remote-provider.xml:
<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />
remote-consumer.xml:
<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>