微服务——Dubbo学习

---

为什么要学习Dubbo？

  有人说微服务已经有Spring Cloud可以实现，那么我们为什么要学习Dubbo呢？为了卷，啊不，dubbo框架使用了RPC传输协议，相比于Spring Cloud的HTTP传输协议，不会造成消息封装的臃肿。从而使得dubbo的网络消耗小于Spring Cloud，从而节约一些成本。(其实好像造成不了什么影响，但多学一点总是好的。)

dubbo的架构

  通过查阅官方文档，我们对Dubbo的架构有了初步的了解。其中虚线都是异步访问，实线都是同步访问蓝色虚线:在启动时完成的功能红色虚线(实线)都是程序运行过程中执行的功能。

节点	角色名称
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

调用关系的进一步说明：

0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

服务注册中心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在发布服务前进行包匹配时无法完成匹配，进而没有进行服务的发布。

踩坑实录：

那么如何解决这个棘手的问题呢？
解决方案：

1. 修改applicationContext-service.xml配置文件，开启事务控制注解支持时指定proxy-target-class属性，值为true。其作用是使用cglib代理方式为Service类创建代理对象。(诶！你以为这就结束了吗？查看Dubbo管理控制台发现，Dubbo给我们发布了一个名为SpringProxy的接口。就是玩儿！)。
   
2. 那我们只能手动修改这个接口的类型了！！！好在修改不繁琐，那就选择原谅他吧。我们只需要修改服务类，在Service注解汇总加入interfaceClass的属性，值为指定接口的类，来指定服务的接口类型即可。

加油！继续努力！！冲冲冲！！！