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&timestamp=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(只注册，不订阅) 
<dubbo:registry protocol="zookeeper"  address="192.168.200.128:2181" register="false" />

2是无注册中心直连

2.1通过配置文件

<!--消费者和提供者都需要这么配置，此处表示不需注册中心-->
<dubbo:registry address="N/A"/>

//但是消费者调用谁呐？消费者需要指定url
    <dubbo:reference id="orderService1" interface="com.gupao.vip.mic.dubbo.order.IOrderServices"
      url="dubbo://192.168.200.126:20880/com.comp.txts.mjx.dubbo.order.IOrderServices" />
//或 酱紫，用id让url省点心
<dubbo:reference interface="cn.itcast.core.service.TbTestService" id="tbTestServiceImpl" 
    url="dubbo://127.0.0.1:20880"/>

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

<dubbo:registry address="multicast://xxx.5x.x.x:1234?unicast=false" />
注意组播地址段: 224.0.0.0 - 239.255.255.255

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

<dubbo:service interface="com.changhf.service.IDubboGroupService" ref="dubboGroup1Service" group="feedback2"/>

//插一句：check启动时检查服务是否可用，false关闭检查，不可用时不报错
<dubbo:reference interface="com.changhf.service.IDubboGroupService" id="dubboGroup1Service" check="false" group="feedback2"/>

 

集群容错

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

<!--服务发布的配置，需要暴露的服务接口，registry="reg1"可灵活配置注册中心-->
    <dubbo:service cluster="failover" retries="2"
            interface="com.sihai.dubbo.provider.service.ProviderService"
            ref="providerService" registry="reg1,reg2"/>

<dubbo:reference cluster="failover" retries="2" check="false" id="providerService"
                     interface="com.sihai.dubbo.provider.service.ProviderService" protocol="rmi"/>

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

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

<dubbo:protocol accesslog="true" name="dubbo" port="20880"/>
<dubbo:protocol accesslog="true" name="rmi" port="1099" />

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

<dubbo:protocol accesslog="http://localhost/log.txt" name="dubbo" port="20880"/>
<dubbo:protocol accesslog="http://localhost/log2.txt" name="rmi" port="1099" />

 

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

默认同步等待结果阻塞的；支持异步调用：基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/ 连接方式介绍