美文网首页互联网科技程序员Java成长之路
Dubbo的这些坑,你有没有遇到过?

Dubbo的这些坑,你有没有遇到过?

作者: Java_老男孩 | 来源:发表于2019-03-29 15:33 被阅读27次

    前言

    微服务架构在如今的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使用过程中遇到坑,以及需要注意的地方吧。

    那些年我们一起踩过的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。

    <pre style="-webkit-tap-highlight-color: transparent; box-sizing: border-box; font-family: Consolas, Menlo, Courier, monospace; font-size: 16px; white-space: pre-wrap; position: relative; line-height: 1.5; color: rgb(153, 153, 153); margin: 1em 0px; padding: 12px 10px; background: rgb(244, 245, 246); border: 1px solid rgb(232, 232, 232); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">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;
    }
    </pre>
    

    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的源码,这个过程会比较痛苦,但是对于排查问题跟个人能力的提高是有很有帮助的。


    文末彩蛋

    针对于上面所涉及到的知识点我总结出了有1到5年开发经验的程序员在面试中涉及到的绝大部分架构面试题及答案做成了文档和架构视频资料免费分享给大家(包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料),希望能帮助到您面试前的复习且找到一个好的工作,也节省大家在网上搜索资料的时间来学习,也可以关注我一下以后会有更多干货分享。

    资料获取方式 QQ群搜索“708-701-457” 备注“简书” 即可免费领取

    相关文章

      网友评论

        本文标题:Dubbo的这些坑,你有没有遇到过?

        本文链接:https://www.haomeiwen.com/subject/nlmlbqtx.html