文章目录
Dubbo
默认使用dubbo协议,hessian序列化框架,zookepper注册中心,使用Neety通信,随机负载均衡,失败自动切换,自动重试其它服务器,默认同步阻塞
Consumer:服务消费者,即服务调用方;
Provider:服务提供者,即被调用方;
Registry:注册中心,服务注册与服务发现,dubbo支持4种注册中心(multicast zookeeper redis simple),dubbo推荐使用zookeeper注册中心;
Monitor:服务监控中心,提供服务调用次数和调用时间统计;
Container:服务运行容器;
分为十层
代理层的动态代理使用的是javaSsesit
负载均衡策略
-
random loadBalance
默认情况下,使用随机调用来实现负载均衡,可以对不同provider。也可以使用不同权重,来进行负载均衡
-
randomRobin loadBalance
轮询来分发流量,每台机器的次数严格一样。也可以调整权重
-
leastactive loadBalance
自动感知,如果某个机器性能越差,分发的请求就越少
-
一致性hash
如果需要一类请求都到一个节点,就可以使用,配合缓存很好用
协议
dubbo
默认的协议是dubbo,适用于小数据量大并发,单一长连接,NIO异步传输(TCP传输),Hessian 二进制序列化
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
特性
缺省协议,使用基于 mina 1.1.7 和 hessian 3.2.1 的 tbremoting 交互。
连接个数:单连接
连接方式:长连接
传输协议:TCP
传输方式:NIO 异步传输
序列化:Hessian 二进制序列化
适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用 dubbo 协议传输大文件或超大字符串。
适用场景:常规远程服务方法调用
全量配置
<dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo” serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9” buffer=“8192” accepts=“1000” payload=“8388608” />
//简单配置,使用dubbo协议,端口20868,线程数200
<dubbo:protocol name="dubbo" port="20868" threadpool="cached" threads="200"/>
rmi
阻塞式短连接,同步TCP传输,Java 标准二进制序列化
hessian
多个短连接,HTTP同步传输,Hessian二进制序列化
集群容错策略
在服务提供方或服务消费方中,均可设置
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failover" retries="1"/>
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failover" retries="2" />
-
failOver cluster模式
失败自动切换,自动重试。
-
fialFast cluster模式
一次调用失败就立即失败,不在重试,适用于写操作
-
failSafe cluster模式
出现异常忽略掉,常用语记录日志
-
failBack
失败了后台自动记录请求,然后定时重发,比较适合于写消息队列
-
forking
并行的调用多个provider,只要一个成功就立即返回
-
broadcast
依次调用所有的provider
服务启动依赖检查
<dubbo:consumer check="false" />
duboo在启动时候会进行所有消费者的服务检查,如果服务都不可用,会抛错,默认为true,通过false进行关闭
服务治理
服务降级
mock只在出现非业务异常(比如超时,网络异常等)时执行,可配置bool值,或null
失败直接返回固定结果
<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="return null" />
失败时执行二级方案
现在消费的标签中,写mock=true
<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="true" />
然后服务提供方在目录下创建mock的处理类,dubbo在调用失败的时候会自动的访问mockxxxxService来进行执行
class xxxxServiceMock implements xxxxService{
//注意类名必须是接口名+Mock
fun1;
fun2;
}
循环依赖问题
可以通过启动时的健康检查来暴露(依赖的双方启动时候必有先后)
- 划分功能
- 使用MQ进行解偶
失败重试和超时重试
在 Provider 上可以配置的 Consumer 端的属性有:
- timeout
- retries
- loadbalance
路由
-
脚本路由
-
条件路由,需要在管理控制台中输入路由规则
# DemoService的sayHello方法只能消费所有端口为20880的服务实例
# DemoService的sayHi方法只能消费所有端口为20881的服务实例
scope: service
force: true
runtime: true
enabled: true
key: org.apache.dubbo.samples.governance.api.DemoService
conditions:
- method=sayHello => address=*:20880
- method=sayHi => address=*:20881
...
# app1的消费者只能消费所有端口为20880的服务实例
# app2的消费者只能消费所有端口为20881的服务实例
---
scope: application
force: true
runtime: true
enabled: true
key: governance-conditionrouter-consumer
conditions:
- application=app1 => address=*:20880
- application=app2 => address=*:20881
...
-
scope
表示路由规则的作用粒度,scope的取值会决定key的取值。必填
- service 务粒度
- application 应用粒度
-
Key
明确规则体作用在哪个服务或应用。必填
- scope=service时,key取