dubbo使用

dubbo使用

• 概念：

  • dubbo是什么？
    Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
    其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

  • dubbo产生的背景
    随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。而dubbo正是这样一个在大型互联网下的因需求催生的产物。

  • dubbo能做什么？
    其实从从上面的概念已经可以看出dubbo所做的工作，这里再简单介绍一下：

    1. 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
    2. 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
    3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
    4. Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
       

• 架构：

  在使用dubbo之前需要简单了解一下dubbo的节点属性，

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

  更详细的说明请参考链接。

• 结合项目介绍：

  1. 快速启动：

     以下实例使用maven构建。

     • 第一步：添加依赖的jar包
       请参看dubbo依赖说明

     • 第二步：安装注册中心
       如果使用zookeeper作为注册中心，请参考相关文档进行安装配置，zookeeper的安装配置较为简单这里不做介绍。

     • 第三步：服务提供者

       • 定义服务接口: (该接口需单独打包，在服务提供方和消费方共享) DemoService.java

         ---

         package com.alibaba.dubbo.demo;
         public interface DemoService{
         String sayHello(String name);
         }

       • 在服务提供方实现服务接口：(对服务消费方隐藏实现)

         ---

         package com.alibaba.dubbo.demo.provider;
         import com.alibaba.dubbo.demo.DemoService;
         public class DemoServiceImpl implements DemoService {
         public String sayHello(String name) {
         return “Hello ” + name;
         }
         }

       • 用Spring配置声明暴露服务： provider.xml

         ---

碰到的问题

1.事件处理死循环

**问题描述：**dubbo支持较低版本的spring，较低版本的spring存在一个bug,即当bean存在循环依赖，spring容器启动时则会出现死循环，这并不是dubbo的bug。
**解决方案：**spring升级

2.异常处理

**问题描述：**dubbo有一个异常过滤类，如果是以下异常直接抛出：1.checked异常，2.在方法签名上有声明，3.异常类和接口类在同一jar包里，4.是JDK自带的异常，5、Dubbo本身的异常。否则Wrap一层RuntimeException异常抛出。由于我们系统中自定义的异常对抛出的异常信息格式有一定要求（包含异常码），需要实现ocean.core.exception.ExceptionInfoGetter接口，如果Wrap一层RuntimeException异常，会影响异常信息的友好性。
解决方案：修改dubbo异常过滤类，判断是否实现ocean.core.exception.ExceptionInfoGetter接口，如果是，则直接抛出。

3.显式引用zkclient异常

**问题描述：**dubbo支持两个zookeeper的客户端，一个是zkclient，另一个是curator。dubbo在ZookeeperRegistry类中显式import了zkclient包中的异常类，导致将zookeeper客户端换成curator时报ClassNotFoundException异常。
解决方案：方案一，在使用curator的时候也添加zkclientjar包。方案二，修改ZookeeperRegistry，去掉显式引用。

4.curator客户端版本问题

问题描述： dubbo依赖的curator版本是Netflix/curator,该版本一年前已经停止更新，现在curator在apache/curator中进行维护。现在curator客户端的应用比zkclient更多，使用前景更好，因此打算将dubbo的zookeeper客户端换成curator，为了保持跟ocean.config依赖的curator版本保持一致，只需要修改dubbo依赖的curator版本。
解决方案：将dubbo依赖的curator从Netflix/curator改为apache/curator，修改CuratorZookeeperClient，将对Netflix/curator的import改为对apache/curator的import.

读者如果想要对dubbo的使用有更深的了解，可访问提供的参考资料"dubbo用户指南"进行了解；
开发人员如果想要对dubbo的实现原理进行了解，可访问参考资料提供的"dubbo开发者指南"；  
运维人员可访问"dubbo管理员指南"。

评价

• 自身优点：

  强大的策略成熟度和功能成熟度、支持用户自定义功能扩展、自动发现机制、集群容错以及软负载均衡等。具体可参考：dubbo用户指南的相关章节。

• 与淘宝HSF相比：

  1. Dubbo比HSF的部署方式更轻量，HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，如果你要运行在Weblogic或Websphere等其它容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。

  2. Dubbo比HSF的扩展性更好，很方便二次开发，一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。

  3. HSF依赖比较多内部系统，比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干清所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。

  4. Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

     • 瑕疵

       
       
       1. dubbo的安全机制较弱，原因：dubbo属于阿里巴巴的一个开源框架，而阿里巴巴有开放平台来处理安全和流控，所以Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。补偿：令牌验证
       2. 不支持分布式，但支持分布式事务的扩展实现，其实照dubbo负责人梁飞的观点，这点不算瑕疵，可参考他的一篇博客。
       3. 多语言支持较弱，目前支持Java和c++（c++实现开源验证不够）

参考资料

dubbo用户指南

dubbo开发者指南

dubbo管理员指南

当当网开源了Xdubbo，支持rest等新特性，以后研究

其他

目前dubbo最新版本为2.5.3，dubbo的官方版本已经停止更新维护，dubbo的开发团队早已解散。但这并不影响dubbo的使用和普及，dubbo支持用户自定义的业务扩展，用户可以结合实际项目中的需求对dubbo进行改造和扩展使用。