一次C10K场景下的线上Dubbo问题排查及优化转

导语

Dubbo 是一款轻量级的开源 Java 服务框架，是众多企业在建设分布式服务架构时的首选。中国工商银行自 2014 年开始探索分布式架构转型工作，基于开源 Dubbo 自主研发了分布式服务平台。

Dubbo 框架在提供方消费方数量较小的服务规模下，运行稳定、性能良好。随着银行业务线上化、多样化、智能化的需求越来越旺盛，在可预见的未来，会出现一个提供方为数千个、甚至上万个消费方提供服务的场景。

在如此高负载量下，若服务端程序设计不够良好，网络服务在处理数以万计的客户端连接时、可能会出现效率低下甚至完全瘫痪的情况，即为 C10K 问题。那么，基于 Dubbo 的分布式服务平台能否应对复杂的 C10K 场景？为此，我们搭建了大规模连接环境、模拟服务调用进行了一系列探索和验证。

正文

C10K 场景下 Dubbo 服务调用出现大量交易失败
 

1、准备环境

使用 Dubbo2.5.9（默认 netty 版本为 3.2.5.Final）版本编写服务提供方和对应的服务消费方。提供方服务方法中无实际业务逻辑、仅 sleep 100ms；消费方侧配置服务超时时间为 5s，每个消费方启动后每分钟调用1次服务。

准备 1 台 8C16G 服务器以容器化方式部署一个服务提供方，准备数百台 8C16G 服务器以容器化方式部署 7000 个服务消费方。

启动 Dubbo 监控中心，以监控服务调用情况。

2、定制验证场景，观察验证结果

验证情况不尽如人意。C10K 场景下 Dubbo 服务调用存在超时失败的情况。

如果分布式服务调用耗时长，从服务消费方到服务提供方全链路节点都会长时间占用线程池资源，增加了额外的性能损耗。而当服务调用并发突增时，很容易造成全链路节点堵塞，从而影响其他服务的调用，并进一步造成整个服务集群性能下降甚至整体不可用，导致发生雪崩。服务调用超时问题不可忽视。因此，针对该 C10K 场景下 Dubbo 服务调用超时失败情况我们进行了详细分析。

C10K场景问题分析
 

根据服务调用交易链路，我们首先怀疑交易超时是因为提供方或消费方自身进程卡顿或网络存在延迟导致的。

因此，我们在存在交易失败的提供方、消费方服务器上开启进程 gc 日志，多次打印进程 jstack，并在宿主机进行网络抓包。

1、观察 gc 日志、jstack

提供方、消费方进程 gc 时长、gc 间隔、内存使用情况、线程堆栈等无明显异常，暂时排除 gc 触发 stop the world 导致超时、或线程设计不当导致阻塞而超时等猜想