dubbo
dubbo 层数
第一层，service层，接口层给服务提供者和消费者来实现。
第二层，config层，配置层，主要是对dubbo进行各种配置。
第三层，proxy层，服务代理层，无论是消费还是提供，dubbo都会生成代理，代理之间进行网络通信。
第四层，registry层，注册层，负责服务注册与发现。
第五层，cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务。
第六层，monitor层，监控层，对rpc接口的调用次数和调用时间进行监控。
第七层，protocal层，远程调用层，封装rpc调用。
第八层，exchange层，信息交换层，封装请求响应模式，同步转异步。
第九层，transport层，网络传输层，抽象mina和netty为统一接口。
第十层，serialize层，数据序列化层。
dubbo序列化协议
默认使用nio通信，基于hessian作为序列化协议。使用的场景是：传输数据量小，但并发高。
rmi协议
走java二进制序列化，多个短连接，适合消费者和提供者数量差不多的情况，适用于文件的传输，一般较少使用。
hessian协议
走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少使用。
http协议
走json序列化
webservice
走soap文本序列化
PB
Protocol Buffer是Google出品的一种轻量高效的结构化数据存储格式，比json、xml要高。
使用了proto编译器，自动进行序列化和反序列化，速度非常快。数据压缩效果好，体积小。
负载均衡策略和集群容错
随机
平均
权重
容错策略
失败自动切换
失败即失败
异常忽略
定时重发
dubbo动态代理
使用了javassist动态字节码生成。可以通过spi扩展机制配置自己的动态代理策略。
dubbo SPI思想
就是spring里面的那种模板架构思想。
幂等性问题
大部分解决思路都是在客户端生成一个ID，服务端通过这个ID值来判断客户端发送的是否是同一个请求。这个ID号可能是订单的ID也可能是别的，后端可以使用redis将其在第一次请求时存储起来，那么第二次请求过来时判断，存在则进行处理。
幂等性的顺序问题
解决思路，使用一致性hash负载均衡策略，将同一个订单的请求发送到同一个机器上。然后内部使用队列，强制进行排队。
标签：dubbo,代理,使用,序列化,ID,hessian 来源： https://blog.csdn.net/a1023934860/article/details/118578625
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。