dubbo基础回顾

实践+理论+反复：思考自己是怎么用的

现在写的东西之前都总结过，也用过、但是……这样历史没什么好致敬的、干活

 

官网本尊：http://dubbo.apache.org/zh-cn/docs/user/quick-start.html

 

和springcloud的不同

两者基本无关联

1、通信方式不同：dubbo使用RPC通信，cloud是http restful方式

2、组成部分不同，cloud是一个全家桶目前还在不断膨胀

 

dubbo的url你见过吗

https://segmentfault.com/a/1190000019896723 主源自，侵删

dubbo://192.168.234.1:20880/com.sihai.dubbo.provider.service.ProviderService?anyhost=true&application=provider&bean.name=com.sihai.dubbo.provider.service.ProviderService&bind.ip=192.168.234.1&bind.port=20880&dubbo=2.0.2&generic=false&interface=com.sihai.dubbo.provider.service.ProviderService&methods=SayHello&owner=sihai&pid=8412&qos.accept.foreign.ip=false&qos.enable=true&qos.port=55555&side=provider×tamp=1562077289380

几乎是熟悉的配方了，如果你尝这个味道有些新鲜，亲、这边建议去找基础打一架

首先映入眼帘的是我们“dubbo”协议，当然也可以dubbo支持的其他协议

• 默认是dubbo协议，单一长连接NIO异步通讯，喜欢在 小数据量大并发的服务调用 舞台上 穿着Hessian做的中二序列号舞衣 为多数的的消费者机器和提供者 表演才艺
• rmi协议是多个阻塞式短链接，JDK标准的二进制序列化，传入传出参数数据包大小可参差不齐，消费者与提供者个数相仿，可传文件哦、与原生RMI互操作
• hessian协议底层是http通讯，servlet古老的技术暴露服务；多个短连接阻塞传输，hessian二进制序列化，参数数据包较大(可传文件的那种大)，提供者压力大、个数多
• http协议，多个短链接同步传输，参数数据包可大可小、可甜可闲，提供者个数比较多
• webservice协议，与webservice服务互操作多个短连接同步传输，http传输协议，SOAP文本序列化；实现Serializable接口、参数尽量使用基本类型 POJO
• thrift协议对thrift原生协议基础添加头信息，不支持null
• memcached 协议
• redis协议

    7、8个协议是不是很烦，一方面说明他灵活另一方面还是有迹可循的、总接一下发现共同点还不少

如此灵活多协议轻松支持，不同服务支持不同协议，同一服务支持不同协议，下方集群容错有实例

 

序列化：

hessian2：跨语言高效二进制序列化方式

json：文本序列化 1采用阿里fastjson库，2dubbo自己实现的简单json库，性能较低

java序列化：jdk自带java序列化实现，性能不理想

 

其他的平平无奇，qos成功了引起了偶滴注意：

QosProtocolWrapper.startQosServer()首先从url解析qos.enable，默认启动

Qos：Quality of Service，服务质量，这个名字似不似有中肃然起敬的赶脚，hh此处用处不大，转身送您一套禁用命令：

dubbo.application.qos-port=2222
dubbo.application.qos-enable=true
dubbo.application.qos-accept-foreign-ip=false

连接方式

以下多为xml配置方式，注解方式较为简单在下面有提及，具体还需要实践

1是zk做注册中心：提供者和消费者同样的配方，拿走不谢

//register="false"(只订阅，不注册) sbuscribe=false(只注册，不订阅) 

2是无注册中心直连

2.1通过配置文件

//但是消费者调用谁呐？消费者需要指定url
    
//或 酱紫，用id让url省点心

2.2JVM通过-D参数指定，key为服务全类名 value为服务提供的url优先级最高，1.0.15版本及其以上支持

java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890

2.3文件映射：这个我不想提他，自行搜索吧

2,4亲爱的注解：

@Reference(version = "1.0",url="
dubbo://localhost:20890
")

 

3是广播 ；我是因为2才写的这块，现在想想有些后悔，不过已经到这了 hh

注意组播地址段: 224.0.0.0 - 239.255.255.255

4分组，版本号也可以实现类似功能

//插一句：check启动时检查服务是否可用，false关闭检查，不可用时不报错

 

集群容错

• failover cluster 失败后自动切换，出现失败重试其他服务器，retries=“2”指定重试次数（不含第一次），常用于读操作
• failfast cluster 快速失败，调用失败即报错、不过有点机会，适合非幂等性写操作
• failsafe cluster 失败安全，有异常我看不见
• failback cluster失败自动恢复，失败没关系、定时补救重发，对了 消息通知的利器
•  forking cluster并行调用多个服务，一个成功即返回，实时性较高的读操作，forks=“2”设置最大并行数
• broadcast cluster 广播调用all提供者，任一台报错则报错

当然最近比较流行 注解，我相信以后也是这个趋势，注解里面有很多熟悉的宝贝,题外加一句 下面添加了版本号，不同服务可有不同版本，需要注意的是不同版本间不可调用（这句话并没有看起来这么云淡风轻）

import com.alibaba.dubbo.config.annotation.Reference;
@Reference(timeout = 10000, retries = -1, version = "1.0.1")
private IActivePageModule activePageModule;

 

注解这里有个小小的问题，需要注意一哈：

dubbo版本2.7.3修改了一个bug，是什么呐？@Reference(retires=0)retries值会被忽视，注入时走dubbo内部方法，nullSafeEquals方法传入当前属性值和默认值，如果等于默认值0则忽略该值，具体请看

 

负载均衡

1. random 随机，按权重设置随机概率
2. roundRobin 轮询，按公约后权重设置轮询比率
3. leastActive 最少活跃调用数，相同活跃数的看缘分随机，活跃数指调用前后的计数差
4. consistentHash一致性hash，相同参数请求总是发到同一提供者，当某提供者挂了，基于虚拟节点、平摊给其他提供者        

 

内置服务容器

众所周知，有spring、jetty、log4j

 

provider可配置consumer的：

timeout调用超时 ； retries失败重试次数、默认2次

loadbalance负载均衡算法，默认随机 ； actives消费端最大并发调用限制

 

日志管理

accesslog输出到log4j

2、输出到文件，看完会觉得配置大同小异，这算不算dubbo一个特点，太灵活了

 

一个异步调用的大概图例：

默认同步等待结果阻塞的；支持异步调用：基NIO非阻塞实现并行调用

 

https://segmentfault.com/a/1190000019896723  dubbo入门到实践

https://blog.csdn.net/xiaojin21cen/article/details/79834222协议

https://blog.csdn.net/ttxs99989/article/details/81294958 http与soap区别

  http一系列http请求头及其他信息，http纯文本格式

  soap简单对象访问协议，轻量、基于xml在web上交换结构化和固化信息

https://blog.csdn.net/chang_li/article/details/52671489/ 连接方式介绍