干货 | 携程一次Dubbo连接超时问题的排查

作者简介

 

顾海洋，携程框架架构研发部技术专家，负责携程分布式服务化领域的工作。目前主要负责 Dubbo 在携程的二次开发和推广工作。

李伟，携程云平台技术专家，2012年加入携程，目前专注于云原生方向技术的研究和落地，先后参与负责过携程部署架构改造、接入层架构升级等项目的设计和推广。

工作中，常常会遇到连接超时的问题，一般都是先检查端口状态，然后再检查CPU、Memory、GC、Connection等机器指标是否正常。如果都在合理范围内就会怀疑到网络或者容器上，甩手丢给网络组同事去排查。

今天，我们想分享一个高并发场景导致的connect timeout，对原因以及过程的分析或许可以帮助大家从容地面对类似问题。

 

一、问题背景

携程度假事业部的某个核心服务在两个机房一共有80台机器，每台机器都是4C8G的docker容器。这个服务的调用方比较多，几十个调用方的机器加起来大概有1300多台。

SOA over CDubbo是将现有SOA框架的HTTP传输协议切换到TCP协议，能够解决长尾问题以及提供更好的稳定性。大概实现原理是，服务端通过CDubbo启动代理服务，客户端在服务发现后与服务端同步建立TCP长连接，请求也会在TCP通道传输。

但是，度假事业部的这个服务每次发布总是会有部分客户端报connect timeout，触发大面积的应用报警。

com.alibaba.dubbo.rpc.RpcException: Fail to create remoting client for service(dubbo://ip:port/bridgeService)  failed to connect to server /ip:port, error message is:connection timed out:  /ip:port at  com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.initClient(DubboProtocol.java:364) at  com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.getSharedClient(DubboProtocol.java:329) at  com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.getClients(DubboProtocol.java:306) at  com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.refer(DubboProtocol.java:288)

从日志分析，是CDubbo代理服务TCP连接失败，还好当初设计的时候考虑到降级机制，没有影响到用户流量。有同事提到既然没有影响，是否可以考虑把日志降级。这么诡异的问题，不知道是否会有其他层面的问题需要去优化的呢，作为执着的技术人员，我们决定排查到底。

二、服务的端口是否异步打开

调用方的每台机器都要跟160个服务端实例建立连接，但是客户端看到的报错量只有几个。所以，最开始怀疑客户端的连接发到服务端，但是端口没有来得及打开，导致少量的连接失败了。

翻了下SOA框架在处理实例注册的代码，启动CDubbo代理是在注册之前，而且是同步启动的，这样的话就否定了端口没打开的可能。

三、怀疑注册中心推送出现了问题

正常情况下的注册发现机制是在服务端健康检查通过后，再把实例推送到客户端。是否注册中心推送出了问题，服务没注册完就把实例推送到客户端了？或者，客户端实例缓存出现问题导致的呢？

这类问题还是要从日志入手，翻了下Dubbo的代码，如果Netty打开端口之后，是会记录端口打开时间的。