为什么要学习Dubbo?
? 有人说微服务已经有Spring Cloud可以实现,那么我们为什么要学习Dubbo呢?为了卷,啊不,dubbo框架使用了RPC传输协议,相比于Spring Cloud的HTTP传输协议,不会造成消息封装的臃肿。从而使得dubbo的网络消耗小于Spring Cloud,从而节约一些成本。(其实好像造成不了什么影响,但多学一点总是好的😁。) 
dubbo的架构
 ? 通过查阅官方文档,我们对Dubbo的架构有了初步的了解。其中虚线都是异步访问,实线都是同步访问蓝色虚线:在启动时完成的功能红色虚线(实线)都是程序运行过程中执行的功能。
节点 | 角色名称 |
---|
Provider | 暴露服务的服务提供方 | Consumer | 调用远程服务的服务消费方 | Registry | 服务注册与发现的注册中心 | Monitor | 统计服务的调用次数和调用时间的监控中心 | Container | 服务运行容器 |
调用关系的进一步说明:
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
服务注册中心Zookeeper
? 和Spring Cloud类似,Dubbo框架也同样拥有自己的服务注册中心——Zookeeper。通常我们都会将Zookeeper配置云端服务器或者虚拟机上。Dubbo官方也推荐使用Zookeeper作为服务注册中心。 
配置中产生的一些思考
? 基本配置建议参考官方文档,在此不进行一一赘述。
思考一
? 在配置Dubbo的过程中,consumer为了去调用provide在Zookeeper中的接口服务,同样需要在自身工程中建立接口类进行调用,虽说不用进行实现,但依旧不符合高质量代码的美观要求,而且也不利于后期的维护。更好的方式是单独创建一个maven工程,将此接口创建在这个maven工程中。需要依赖此接口的工程只需要在自己工程的pom.xml文件中引入maven坐标即可。
思考二
? Dubbo是如何实现远程调用的呢?Dubbo底层是基于代理技术为接口创建代理对象,远程调用是通过此代理对象完成的。可以通过开发工具的debug功能查看此代理对象的内部结构。另外,Dubbo实现网络传输底层是基于Netty框架(听说最近要卷这个?在学了在学了😭)完成的。
思考三
? 我们使用Zookeeper作为服务注册中心,服务提供者需要将自己的服务信息注册到Zookeeper,服务消费者需要从Zookeeper订阅自己所需要的服务,此时Zookeeper服务就变得非常重要了,那如何防止Zookeeper单点故障呢? 答:Zookeeper其实是支持集群模式的,可以配置Zookeeper集群来达到Zookeeper服务的高可用,防止出现单点故障。
!!!Dubbo官方提供了管理控制台的war文件,导入本地tomcat的webapps目录下即可本地访问Zookeeper注册了哪些服务!!!
踩坑😭
? 我们在配置Dubbo的时候,在服务类上添加@Service(是Dubbo包中的!!!不是spring包中的)就可以被发布为服务。但是我们如果在服务提供者类上加入@Transactional事务控制注解后,服务就发布不成功了。原因是事务控制的底层原理是为服务提供者类创建代理对象,而默认情况下Spring是基于JDK动态代理方式创建代理对象,而此代理对象的完整类名为com.sun.proxy.$Proxy42(最后两位数字不是固定的),导致Dubbo在发布服务前进行包匹配时无法完成匹配,进而没有进行服务的发布。
踩坑实录:  那么如何解决这个棘手的问题呢? 解决方案:
- 修改applicationContext-service.xml配置文件,开启事务控制注解支持时指定proxy-target-class属性,值为true。其作用是使用cglib代理方式为Service类创建代理对象。(诶!你以为这就结束了吗?查看Dubbo管理控制台发现,Dubbo给我们发布了一个名为SpringProxy的接口😭。就是玩儿!)。
 - 那我们只能手动修改这个接口的类型了😡!!!好在修改不繁琐,那就选择原谅他吧。我们只需要修改服务类,在Service注解汇总加入interfaceClass的属性,值为指定接口的类,来指定服务的接口类型即可。

加油!继续努力!!冲冲冲!!! 
|