dubbo在网络异常情况下的踩坑经历

背景

先交代下问题背景，因为某种原因，我们需要在dubbo中使用多注册中心模式，整体上的网络拓扑类似下图。

• 服务A通过注册中心A向外提供rest接口
• 服务A通过注册中心B引用注册在中心中心B的服务BCD
• 服务BCD通过注册中心B向外提供dubbo接口

抽丝剥茧排查问题

• 服务A原本在X机房已经正常在运行的，只不过服务A和服务BCD同时注册在同一个注册中心而已。现在服务A换到了Y机房，但是服务却始终注册不到注册中心当中。

• 如何发现服务A没有注册到注册中心呢，熟悉dubbo的应该都懂如果用zookeeper作为注册中心，那么在zookeeper的节点(/dubbo/server_interface/provider)下会有对应的服务

• 一开始服务没有注册，完全没有排查思路只是隐隐地感觉tomcat的服务应该没有完全启动起来，后来请公司的大神海军一起过来看，通过使用jstack命令发现有一些连接zookeeper的线程等待，但是不确定什么原因。

• 开始尝试将服务A从注册中心A引用的服务BCD，也就是虽然服务BCD没有发布在注册中心A，但是可以通过设置<dubbo:reference check="false"/>来设置不检查服务BCD是否存在，这个时候发现tomcat的服务起来了当然服务A依然没有成功注册到注册中心A，但是这个时候有更关键的日志打印出来了，直接让我定位到网络不通的问题。

• 打电话直接给运维沟通是否机房A和机房B是否网络不通，当然我肯定也尝试ping的过程，最终确认机房网络不通。

• 短暂在机房A临时搭建依赖的redis和zookeeper，尝试启动服务后发现服务A已经成功注册到注册中心A，至此整个过程已经结束。

我的收获

• 首先我成功的错过了一场电影，浪费了一张电影票，到时候向运维的同学去索要补偿。

• 明白当没有日志可以供参考的时候，多尝试用jstack去查看线程占用的情况。

• 排查过程中，发现自己心态挺有意思的，经历了困惑、平稳、自信能够定位问题，整个过程中不停的提醒自己，一般人很难遇到这种问题，所以要为自己能够遇到问题而庆幸，最后很庆幸的解决了，对于重复的事情没什么热情

• 在做事情的过程中需要在完成目标的同时为自己的技术找一点技术目标，在过去的一个星期的时候我就做了一件很简单的事情，梳理服务的降级开关以及压测对应的服务。本职工作就是以一个系统的思维去整理这些东西，同时在压测过程中顺带把jmeter熟悉了一下，通过自己的使用和跟压测大拿的都都交流也算了解了一门新技能。

我的不屑

• 最近听到过两种自己比较反感的声音，第一种是说自己改写代码多么累的声音，第二种是说自己开会多么累的声音，突然有一种感觉格局这种东西除了去经历也只有通过看书去提高了，切记进入自high型的状态。

• 想想我们组还是非常务实的，果然一个项目组的风格完全是由领队的风格决定的，我觉得现在的状态挺有意思的。