个人网站免费制作,如何在网上推广产品,软件开发视频,应用之星制作app软件官网简介#xff1a; 未来#xff0c;中国工商银行将持续致力于 Dubbo 的金融级规模化应用。
作者#xff1a;颜高飞#xff0c;微服务领域架构师#xff0c;主要从事服务发现、高性能网络通信等研发工作#xff0c;擅长 ZooKeeper、Dubbo、RPC 协议等技术方向。 Dubbo是一款…简介 未来中国工商银行将持续致力于 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监控中心以监控服务调用情况。 定制验证场景观察验证结果 操作步骤 观察内容 验证结果 场景1 先启动服务提供方后分批启动消费方 调用1小时观察交易情况 存在零星交易超时失败。消费方分散在多台服务器上。 场景2 在服务正常调用一段时间后重启提供方 观察提供方重启后的表现 在提供方重启后1-2分钟内存在大量交易超时失败后逐渐恢复。消费方分散在多台服务器上。 验证情况不尽如人意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线程。因提供方服务器为8Cdubbo默认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内核的参数默认值是128backlog在创建Socket时设置dubbo2.5.9中默认backlog值是50。因此生产环境全连接队列是50。通过ss命令Socket Statistics也查得全连接队列大小为50。 观察TCP连接队列情况证实存在全连接队列溢出的现象。 即全连接队列容量不足导致大量单边连接产生。因在本验证场景下订阅提供方的消费方数量过多当提供方重启后注册中心向消费方推送提供方上线通知所有消费方几乎同时与提供方重建连接导致全连接队列溢出。 分析单边连接影响范围
单边连接影响范围多为消费方首笔交易偶发为首笔开始连续失败2-3笔。 建立为单边的连接下交易非必然失败。三次握手全连接队列满后若半连接队列空闲提供方创建定时器向消费方重传synack重传默认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场景下交易处理效率提升服务调用的性能容量。 优化内容包括以下方面 具体涉及优化的框架层如下 经对各优化内容逐项验证各措施均有不同程度的提升效果分别如下 优化内容 优化效果 tcp全连接队列扩容 提供方重启后交易超时失败现象消除 epoll模型调整 提供方重启后全连接队列溢出次数明显降低连接accept速度有所提升 心跳绕过序列化 提供方在心跳周期无CPU毛刺CPU峰值降低20% 消费方与提供方之间平均处理时差由27ms降低至3ms 前99%的交易耗时从191ms下降至133ms 增加Iothreads线程数 将默认的iothreads线程数9调整为20后消费方与提供方之间平均处理时差由27ms降低至14ms 前99%的交易耗时从191ms下降至186ms 提供方心跳打散 从提供方网络抓包分析心跳数据包的毛刺峰值从1.5万/秒压降至3000/秒 消费方心跳打散 从提供方网络抓包分析心跳数据包几乎不再有毛刺峰 综合优化验证效果 综合运用以上优化效果最佳。在此1个提供方连接7000个消费方的验证场景下重启提供方后、长时间运行无交易超时场景。对比优化前后提供方CPU峰值下降30%消费方与提供方之间处理时差控制在1ms以内P99交易耗时从191ms下降至125ms。在提升交易成功率的同时有效减少了消费方等待时间、降低了服务运行资源占用、提升了系统稳定性。 线上实际运行效果 基于以上验证结果中国工商银行在分布式服务平台中集成了以上优化内容。截至发文日期线上已存在应用一个提供方上连接上万个消费方的场景。落地该优化版本后在提供方版本升级、及长时间运行下均无异常交易超时情况实际运行效果符合预期。 未来展望 中国工商银行深度参与Dubbo社区建设在Dubbo金融级规模化运用的过程中遇到了诸多技术挑战为满足金融级高敏交易的苛刻运行要求开展了大规模自主研发并通过对Dubbo框架的扩展和定制持续提升服务体系的稳定性以“源于开源、回馈开源”的理念将通用增强能力不断贡献至开源社区。未来我们将持续致力于Dubbo的金融级规模化应用协同社区继续提升Dubbo的性能容量和高可用水平加速金融行业数字化创新和转型及基础核心关键的全面自主可控。
原文链接
本文为阿里云原创内容未经允许不得转载。
