dubbo学习笔记
原文链接:https://www.geek-share.com/detail/2638792708.html
dubbo是一个服务治理框架。用于解决服务之间的依赖及调用问题,也是一种rpc实现。
dubbo中,有三个重要角色,一:注册中心,二:服务提供方,三:服务调用者。
一. 注册中心,可以是zookeeper,redis等,其实就是存放一个服务列表的地方。
推荐使用zookeeper,zookeeper用树状结构来进行存储。如图:
zookeeper存储的根结点是对应 <dubbo:register group="dubbo"/>中的group属性。
二.服务提供方
服务提供方连接上zookeeper并将服务注册到zookeeper上。
三.服务消费者
服务消费者会从zookeeper上拿到一份服务列表,并存储在本地文件中。这里如果一台机子部署多个服务的话,即多个jvm进程,这时有可能会发生这个本地文件发生竞争,而抛出异常。但dubbo对于这块异常是会重试的,所以不用担心。
dubbo的整个设计围绕着这三个角色进行。
对应这三个角色的配置标签分别有:<dubbo:register.../> ,<dubbo:provider.../>,<dubbbo:consumer.../>
在生产运用中,可以设置的参数有超时timeout,重试次数retries,负载均衡算法loadbanlance,容错方式failover等。
对于有些插入这种,非幂等操作,需要注意dubbo的超时重试机制。可以将其设置为0。
在protocal协议的选择上(即选择哪种协议用于实现远程调用)目前有dubbo,rmi,http等。
dubbo是默认推荐的方式,使用长连接,nio的形式。实现上就是服务消费方与服务提供方及注册中心之间使用长连接。
使用默认dubbo协议的话,序列化使用的是修改过的hessian协议,这是一种高效的二进制与具体语言无关的协议。而服务提供者端与服务消费者端使用的是mina nio框架。
而dubbo唯一确认一个服务的是:接口interface+版本号version+分组号group。
因此当业务升级接口时,如果服务调用方不兼容新的服务提供方接口时,这时可以采用version版本控制。
而在设计服务接口时,需要以一个功能为一个接口暴露给调用方。如果这个功能被分成三个接口给调用方,而这个功能必须是原子性的,即要么同时成功,要么同时失败,这里就比较麻烦了,需要引入分布式事务或其它方式解决。
对于性能优化上,如果某个业务需要同时查询多个服务,之后将根据这些服务的数据返回结果再做处理的话,可以用async来实现异步调用请求,加速业务处理。
阅读更多- Dubbo框架学习笔记(二)
- 【学习笔记】dubbo 控制台的部署
- dubbo学习笔记-关于架构
- dubbo源码学习笔记----结合Spring
- Dubbo -- 系统学习 笔记 -- 示例 -- 多注册中心
- dubbo学习概要笔记
- dubbo 源码学习笔记 (六) —— 集群模块
- dubbo源码学习笔记----Provider和Consumer
- Dubbo -- 系统学习 笔记 -- 示例 -- 泛化引用
- dubbo 学习笔记 -- provider端
- dubbo学习笔记 十一 dubbo-rpc之模块
- Dubbo -- 系统学习 笔记 -- 配置参考手册
- Dubbo -- 系统学习 笔记 -- 示例 -- 负载均衡
- Maven+Spring+Dubbo学习笔记
- dubbo学习笔记
- dubbo 源码学习笔记 (八) —— 远程通讯模块
- JAVA学习笔记24——Dubbo、zookeeper相关讲解及实战入门
- dubbo入门学习笔记
- dubbo 学习笔记 -- provider端
- Dubbo -- 系统学习 笔记 -- 示例 -- 服务分组