简介：将来，中国工商银行将继续致力于 Dubbo 的金融级规模化利用。
作者：颜高飞，微服务畛域架构师，次要从事服务发现、高性能网络通信等研发工作，善于 ZooKeeper、Dubbo、RPC 协定等技术方向。
Dubbo是一款轻量级的开源Java服务框架，是泛滥企业在建设分布式服务架构时的首选。中国工商银行自2014年开始摸索分布式架构转型工作，基于开源Dubbo自主研发建设了分布式服务平台。Dubbo框架在提供方生产方数量较小的服务规模下，运行稳固、性能良好。
随着银行业务线上化、多样化、智能化的需要越来越旺盛，在可预感的将来，会呈现一个提供方为数千个、甚至上万个生产方提供服务的场景。在如此高负载量下，若服务端程序设计不够良好，网络服务在解决数以万计的客户端连贯时、可能会呈现效率低下甚至齐全瘫痪的状况，即为C10K问题。那么，基于dubbo的分布式服务平台是否应答简单的C10K场景？为此，咱们搭建了大规模连贯环境、模仿服务调用进行了一系列摸索和验证。
C10K场景下Dubbo服务调用呈现大量交易失败
筹备环境：
应用dubbo2.5.9（默认netty版本为3.2.5.Final）版本编写服务提供方和对应的服务生产方。提供方服务办法中无理论业务逻辑、仅sleep 100ms；生产方侧配置服务超时工夫为5s，每个生产方启动后每分钟调用1次服务。
筹备1台8C16G服务器以容器化形式部署一个服务提供方，筹备数百台8C16G服务器以容器化形式部署7000个服务生产方。
启动dubbo监控核心，以监控服务调用状况。
定制验证场景，察看验证后果：
验证状况不尽如人意，C10K场景下dubbo服务调用存在超时失败的状况。
如果分布式服务调用耗时长，从服务生产方到服务提供方全链路节点都会长工夫占用线程池资源，减少了额定的性能损耗。而当服务调用并发突增时，很容易造成全链路节点梗塞，从而影响其余服务的调用，并进一步造成整个服务集群性能降落甚至整体不可用，导致产生雪崩。服务调用超时问题不可漠视。因而，针对该C10K场景下dubbo服务调用超时失败状况咱们进行了详细分析。
C10K场景问题剖析
依据服务调用交易链路，咱们首先狐疑交易超时是因为提供方或生产方本身过程卡顿或网络存在提早导致的。
因而，咱们在存在交易失败的提供方、生产方服务器上开启过程gc日志，屡次打印过程jstack，并在宿主机进行网络抓包。
察看gc日志、jstack
提供方、生产方过程gc时长、gc距离、内存应用状况、线程堆栈等无显著异样，临时排除gc触发stop the world导致超时、或线程设计不当导致阻塞而超时等猜测。
针对以上两种场景下的失败交易，别离察看网络抓包，对应有以下两种不同的景象：
针对场景1：提供方稳固运行过程中交易超时。
跟踪网络抓包及提供方、生产方交易日志。生产方发动服务调用申请发动后，在提供方端迅速抓到生产方申请报文，但提供方从收到申请报文到开始解决交易耗时2s+。
同时，察看交易申请响应的数据流。提供方业务办法处理完毕后到向生产方发送回包之间也耗时2s+，尔后生产方端迅速收到交易返回报文。但此时交易总耗时已超过5s、超过服务调用超时工夫，导致抛出超时异样。
由此，判断导致交易超时的起因不在生产方侧，而在提供方侧。
针对场景2：提供方重启后大量交易超时。
服务调用申请发动后，提供方迅速收到生产方的申请报文，但提供方未失常将交易报文递交给应用层，而是回复了RST报文，该笔交易超时失败。
察看在提供方重启后1-2分钟内呈现大量的RST报文。通过部署脚本，在提供方重启后每隔10ms打印established状态的连接数，发现提供方重启后连接数未能迅速复原到7000，而是通过1-2分钟后连接数才复原至失常数值。而在此过程中，逐台生产方上查问与提供方的连贯状态，均为established，狐疑提供方存在单边连贯状况。
咱们持续别离剖析这两种异样场景。
场景1：提供方理论交易前后均耗时长、导致交易超时
细化收集提供方的运行状态及性能指标：
- 在提供方服务器上每隔3s收集服务提供方jstack，察看到netty worker线程每60s左右频繁解决心跳。
- 同时打印top -H，察看到占用cpu工夫片较多的线程排名前10中蕴含9个netty worker线程。因提供方服务器为8C，dubbo默认netty worker线程数为9个，即所有9个netty worker线程均较繁忙。
- 部署服务器零碎性能采集工具nmon，察看到cpu每隔60秒左右产生毛刺；雷同工夫网络报文数也有毛刺。
- 部署ss -ntp间断打印网络接管队列、发送队列中的数据积压状况。察看到在耗时长的交易工夫点左近队列沉积较多。
- Dubbo服务框架中提供方和生产方发送心跳报文（报文长度为17）的周期为60s，与以上距离靠近。联合网络抓包，耗时长的交易工夫点左近心跳包较多。
依据Dubbo框架的心跳机制，当生产方数量较大时，提供方发送心跳报文、需应答的生产方心跳报文将会很密集。因而，狐疑是心跳密集导致netty线程繁忙，从而影响交易申请的解决，继而导致交易耗时减少。
进一步剖析netty worker线程的运行机制，记录每个netty worker线程在解决连贯申请、解决写队列、解决selectKeys这三个关键环节的解决耗时。察看到每距离60s左右（与心跳距离统一）解决读取数据包较多、耗时较大，期间存在交易耗时减少的状况。同一时间察看网络抓包，提供方收到较多的心跳报文。
因而，确认以上狐疑。心跳密集导致netty worker线程繁忙，从而导致交易耗时增长。
场景2：单边连贯导致交易超时
剖析单边连贯产生的起因
TCP建设连贯三次握手的过程中，若全连贯队列满，将导致单边连贯。
全连贯队列大小由零碎参数net.core.somaxconn及listen(somaxconn,backlog)的backlog取最小值决定。somaxconn是Linux内核的参数，默认值是128；backlog在创立Socket时设置，dubbo2.5.9中默认backlog值是50。因而，生产环境全连贯队列是50。通过ss命令（Socket Statistics）也查得全连贯队列大小为50。
察看TCP连贯队列状况，证实存在全连贯队列溢出的景象。
即：全连贯队列容量有余导致大量单边连贯产生。因在本验证场景下，订阅提供方的生产方数量过多，当提供方重启后，注册核心向生产方推送提供方上线告诉，所有生产方简直同时与提供方重建连贯，导致全连贯队列溢出。
剖析单边连贯影响范畴
单边连贯影响范畴多为生产方首笔交易，偶发为首笔开始间断失败2-3笔。
建设为单边的连贯下，交易非必然失败。三次握手全连贯队列满后，若半连贯队列闲暇，提供方创立定时器向生产方重传syn+ack，重传默认5次，重传距离以倍数增长，1s..2s..4s..共31s。在重传次数内，若全连贯队列复原闲暇，生产方应答ack、连贯建设胜利。此时交易胜利。
在重传次数内，若全连贯队列依然繁忙，新交易达到超时工夫后失败。
达到重传次数后，连贯被抛弃。尔后生产方发送申请，提供方应答RST。后交易达到超时工夫失败。
依据Dubbo的服务调用模型，提供方发送RST后，生产方抛出异样Connection reset by peer，后断开与提供方的连贯。而生产方无奈收到以后交易的响应报文、导致超时异样。同时，生产方定时器每2s检测与提供方连贯，若连贯异样，发动重连，连贯复原。尔后交易失常。
C10K场景问题剖析总结
总结以上造成交易超时的起因有两个：
- 心跳机制导致netty worker线程繁忙。在每个心跳工作中，提供方向所有1个心跳周期内未收发过报文的生产方发送心跳；生产方向所有1个心跳周期内未收发过报文的提供方发送心跳。提供方上所连贯的生产方较多，导致心跳报文沉积；同时，解决心跳过程耗费较多CPU，影响了业务报文的解决时效。
全连贯队列容量有余。在提供方重启后该队列溢出，导致大量单边连贯产生。单边连贯下首笔交易大概率超时失败。
下一步思考
针对以上场景1：如何能升高单个netty worker线程解决心跳的工夫，减速IO线程的运行效率？初步构想了如下几种计划：
• 升高单个心跳的解决耗时
• 减少netty worker线程数，升高单个IO线程的负载
• 打散心跳，防止密集解决
针对以上场景2：如何躲避首笔大量半连贯导致的交易失败？构想了如下计划：
• 减少TCP全连贯队列的长度，波及操作系统、容器、Netty
• 进步服务端accept连贯的速度交易报文解决效率晋升
逐层优化
基于以上构想，咱们从零碎层面、dubbo框架层面进行了大量的优化，以晋升C10K场景下交易解决效率，晋升服务调用的性能容量。
优化内容包含以下方面：
具体波及优化的框架层如下：
经对各优化内容逐项验证，各措施均有不同水平的晋升，成果别离如下：
综合优化验证成果
综合使用以上优化成果最佳。在此1个提供方连贯7000个生产方的验证场景下，重启提供方后、长时间运行无交易超时场景。比照优化前后，提供方CPU峰值降落30%，生产方与提供方之间解决时差管制在1ms以内，P99交易耗时从191ms降落至125ms。在晋升交易成功率的同时，无效缩小了生产方等待时间、升高了服务运行资源占用、晋升了零碎稳定性。
线上理论运行成果
基于以上验证后果，中国工商银行在分布式服务平台中集成了以上优化内容。截至发文日期，线上已存在利用一个提供方上连贯上万个生产方的场景。落地该优化版本后，在提供方版本升级、及长时间运行下均无异样交易超时状况，理论运行成果合乎预期。
将来瞻望
中国工商银行深度参加Dubbo社区建设，在Dubbo金融级规模化使用的过程中遇到了诸多技术挑战，为满足金融级高敏交易的刻薄运行要求，发展了大规模自主研发，并通过对Dubbo框架的扩大和定制继续晋升服务体系的稳定性，以“源于开源、回馈开源”的理念将通用加强能力一直奉献至开源社区。将来，咱们将继续致力于Dubbo的金融级规模化利用，协同社区持续晋升Dubbo的性能容量和高可用程度，减速金融行业数字化翻新和转型及根底外围要害的全面自主可控。
原文链接
本文为阿里云原创内容，未经容许不得转载。