那些年我们一起踩过的Dubbo"坑"

前言

 

微服务架构在如今的9102年已经不是什么新鲜的话题了，但是怎么做好微服务架构，却又是一个永恒的话题。比如服务粒度的划分，怎么控制好粗细？服务划分后，对于项目的部署会有什么改变？...  这会是一个很大的话题，以后可以分开篇章探讨一翻，但是我们本篇并不打算聊这个，而是讨论一下具体的实现技术--dubbo。

 

dubbo历史

 

2011 年末，阿里巴巴在 github 上开源了基于 java 的分布式服务治理框架 dubbo，之后它成为了国内该类开源项目的佼佼者，许多开发者对其表示青睐。同时，先后有不少公司在实践中基于 dubbo 进行分布式系统架构，目前在 github 上，它的 fork、star 数均已破万。2014 年 10 月 30 号发布版本 dubbo-2.4.11，修复了一个小 bug，版本又陷入漫长的停滞到2017年九月份。

在dubbo停滞的期间呢，当当网 fork 了阿里的一个 dubbo 版本开始维护，并命名为 dubbox-2.8.0。值得注意的是，当当网扩展 dubbo 服务框架支持 rest 风格远程调用，并且跟随着 zookeepe 和 spring 升级了对应的版本。之后 dubbox 一直在小版本维护，2015 年 3 月 31 号发布了最后一个版本 dubbox-2.8.4。笔者公司用的也是这个版本，并稍微改造了下源码，下面会有提及。

其实在当前说到微服务，可能大家第一反应是springcloud，spring全家桶带来的便捷是显而易见的，然而为什么我们这里聊的是dubbo呢？原因之一是因为笔者公司只用了dubbo（别扔鸡蛋....）,其二呢其实rpc框架很多原理是相通的，当我们理解了其中一个，再去看其他的框架，会有一种似曾相识的感觉，最后也没必要去争论xx框架的好与坏，选择最适合自己业务的就是最好的。

先交代下背景，我们这边是从2016年开始使用dubbo，使用的是dubbox-2.8.4 版本，然后因为一些场景不合适改了下代码，重新打包成2.8.5提交至公司的私服使用。好了，接下来就开始进入正文，聊聊这几年在dubbo使用过程中遇到坑，以及需要注意的地方吧。

 

正文

 

1、超时重试

 

这是一个很经典的坑，当时由于刚使用dubbo，很多配置都是基于默认的。刚好此时在项目中，有一个机器人送礼的逻辑比较复杂，当遇到某些特定的条件时，该逻辑的耗时会比正常情况下变长，这时候就出现了一个很神奇的现象，为何我只触发了一次送礼的请求，而线上却送了三次？

 

刚遇到这种情况可我惊呆了，重新审视了代码，发现并无问题。这就奇怪了，哪里来的3次？后来掉了几根头发以后，才在dubbo的文档中发现了服务这块有timeout跟retry属性，默认timeout=1000ms,retry=2。这下就豁然开朗，原来是第一次调用超时，导致又重试了2次，一共就是3次了。

 

找到问题的原因，我们就有办法解决了。由于我们这个接口不是幂等性的，而且也不用返回什么信息给调用者，所以我们可以通过一个线程池来执行这段耗时的逻辑，让rpc调用可以比较快的返回给调用者。这样就不存在超时的问题了。或者可以配合增加timeout时间跟retry=0也能实现，具体的业务逻辑需要自己找到合适的解决方案。

 

2、dubbo使用内网ip

 

正常情况下，我们的服务调用推荐走内网连接的方式，效率是比较高的。但是有些特殊的情况，我们需要dubbo注册服务的时候使用外网ip，该怎么修改呢？这时候就需要修改我们的服务器上 /etc/hosts 文件了，新增一条 “外网ip  主机名”的记录，restart我们的服务即可。

 

3、docker里面注册宿主机内网ip

 

说到微服务，当然也少不了docker了，我们当前用的是docker+overlay网络一个结构，直接把dubbo服务丢进容器里面跑的话，注册进zk的ip是容器ip。所以我们采取了一种折中的方式。

 

利用docker的特性，我们在创建容器的时候，把宿主机的ip以及需要暴露的端口写进容器的环境变量里面。然后就是修改dubbox的源码了，源码的com.alibaba.dubbo.registry.integration.registryprotocol类的getregistedproviderurl

方法，此方法用于返回注册到注册中心的url。

 

private url getregistedproviderurl(final invoker<?> origininvoker){
        //targeturl 注册中心看到的地址
        url targeturl;
        url providerurl = getproviderurl(origininvoker);
        //配置的容器环境变量
        string envparameterhost=system.getenv(env_host_key);
        string envparameterport=system.getenv(env_port_key);
        if (stringutils.isblank(envparameterhost)||stringutils.isblank(envparameterport)){//非容器环境：执行原来的注册逻辑
            targeturl=providerurl.removeparameters(getfilteredkeys(providerurl)).removeparameter(constants.monitor_key);
        }else {//容器环境，如果环境变量中docker_nat_host和docker_nat_port两个值都不为空则直接将这两个值作为url注册到zk
            //执行重新拼接url的操作，涉及敏感代码这里不展示了
            targeturl=dockerregurlwithhostandport;
        }
        return targeturl;
    }

 

 

4、未注意服务重名

 

其实这是我们开发人员粗心大意出现的情况，开发的时候注册了2个相同签名的服务，但是业务逻辑是完全不同的，这会导致一个之前运行的正常的业务会偶尔调用失败，原因是因为dubbo的负载均衡策略，把一部分流量转移到我们新注册上来的服务上了，但是处理逻辑不同，导致错误。

 

5、版本的一致性

 

dubbo当前的releases版本已经去到2.7.1了，项目中要注意一下不同项目间版本的一致性，或者是dubbo跟dubbox的一些差别，最好做到统一，不然出现问题解决的成本会比较高。

 

6、属性配置的优先级

 

我们在dubbo的过程中会发现，提供者跟消费者中，很多属性是一样的，我们该怎么配呢？在dubbo的文档当中其实有推荐的用法。

在提供者端尽量多提供消费者端的属性。

参考文档，原因如下：

• 作服务的提供方，比服务消费方更清楚服务的性能参数，如调用的超时时间、合理的重试次数等

• 在 provider 端配置后，consumer 端不配置则会使用 provider 端的配置，即 provider 端的配置可以作为 consumer 的缺省值 。否则，consumer 会使用 consumer 端的全局设置，这对于 provider 是不可控的，并且往往是不合理的

provider 端尽量多配置 consumer 端的属性，让 provider 的实现者一开始就思考 provider 端的服务特点和服务质量等问题。

结语

其实在dubbo的使用过程中，还有挺多问题这里没列出来的，但是解决方法都差不多，首先文档要熟，做到心中有数，比如dubbo功能的成熟度，有些是不推荐在线上使用的，这时你就要谨慎了。然后文档里面确实是有遗漏的问题，我们有必要可以debug dubbo的源码，这个过程会比较痛苦，但是对于排查问题跟个人能力的提高是有很有帮助的。

大家在dubbo的使用过程中有什么问题也可以交流一下~

 

github：https://github.com/apache/incubator-dubbo

中文使用手册http://dubbo.apache.org/zhcn/docs/user/preface/background.html