工商银行分布式服务 C10K 场景解决方案

原创

于 2021-05-14 14:54:22 发布 · 280 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#监控 #Dubbo #网络协议 #Cloud Native #架构师 #Java #应用服务中间件 #Linux #微服务 #容器

本文详细分析了在C10K场景下，基于Dubbo的分布式服务平台遇到的交易超时问题。通过场景复现和深入分析，发现问题是由于心跳机制导致的线程忙碌和全连接队列容量不足。提出了优化方案，包括降低心跳处理耗时、增加全连接队列长度等，并验证了优化效果，显著提升了交易成功率和系统稳定性。

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

头图.png

作者 | 颜高飞
来源 | 阿里巴巴云原生公众号

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 服务调用超时失败情况我们进行了详细分析。