RPC故障排查指南：三分钟恢复服务
当终端用户突然反馈系统卡死、关键业务无法提交，而运维后台监控面板上亮起刺眼的红色告警时，绝大多数情况下，问题都指向一个令人头疼的元凶：rpc 服务器不可用。这个错误提示往往伴随着超时重试、连接重置以及日志中堆叠的E_CONNREFUSED异常。对于依赖微服务架构或分布式系统的团队而言，每一分钟的停滞都意味着真金白银的损失。与其慌乱地重启所有节点，不如掌握一套系统化的排查逻辑，在黄金三分钟内让服务重回正轨。
首先需要明确的是，rpc 服务器不可用这个表象背后，通常隐藏着四种截然不同的故障类型：网络链路问题、服务进程假死、注册中心失联以及资源耗尽。在开始任何操作之前，请先执行一次“冷观察”。打开你的RPC调用端日志，寻找最近一次成功的调用时间戳。如果失败是断崖式的（即前一秒还在正常，后一秒全部失败），那么优先检查网络层；如果是渐进式的（成功率逐渐下降），则大概率是服务端资源瓶颈或连接池被占满。
第一分钟：快速定位网络与端口状态
不要急于去查看复杂的分布式追踪链路。先用最基础的工具验证物理连通性。在调用端服务器上执行telnet或nc命令，检查目标服务IP的RPC端口（常见如Dubbo的20880，gRPC的50051，或自定义端口）是否能够建立TCP握手。如果连接直接拒绝或超时，请立刻检查防火墙规则、安全组策略以及是否发生了IP漂移。很多情况是云环境下的安全组配置在滚动更新时被意外覆盖。如果端口处于监听状态，但业务请求依然报错，则继续向下排查。
此时，需要关注一个高频陷阱：半连接队列溢出。在Linux系统中，如果服务端进程的backlog参数设置过小，或者应用程序没有及时调用accept()函数，内核会丢弃新的连接请求。你可以通过ss -lnt查看当前监听套接字的Send-Q和Recv-Q。如果Recv-Q的数值持续堆积且接近队列上限，说明服务端线程已经无法及时接收新任务。这并非网络故障，而是应用层调度出了问题。
第二分钟：检查进程健康与GC压力
当确认端口可达后，rpc 服务器不可用的另一个常见诱因是进程假死或长时间Full GC。进入服务端主机，执行top查看进程CPU占用率。如果CPU一直处于高位且占用核心被锁定，而请求却无响应，极有可能是代码中出现了死循环或锁竞争。对于Java技术栈，必须立即抓取线程快照（jstack）和堆内存快照（jmap -heap）。重点关注是否存在BLOCKED状态的线程大量堆积在某个业务锁上，或者老年代内存使用率是否逼近100%导致GC停顿过长。
更隐蔽的一个问题是异步线程池耗尽。许多RPC框架（如gRPC或Thrift）使用独立的Worker线程池处理请求。如果某个下游调用缓慢，导致线程池中所有线程都在等待I/O返回，新进入的请求就会在队列中排队，最终表现为客户端超时并报出“服务器不可用”。此时查看监控中的ThreadPool活跃线程数，若一直等于最大线程数，请立即降级或熔断该下游依赖，让主链路恢复呼吸。
第三分钟：注册中心与连接池的隐性故障
如果服务端进程本身运行平稳，但客户端依然无法找到可用节点，那么问题很可能出在注册中心（如Nacos、Zookeeper、Eureka）上。检查服务提供者是否在注册中心中依然保留了心跳。有时候服务端进程还在，但它的心跳线程因为DNS解析故障或网络分区而中断，导致注册中心将其从可用列表中摘除。此时，客户端拿到的服务列表是空的，自然报出rpc 服务器不可用。解决方式不是重启服务，而是修复服务端到注册中心之间的心跳链路。
此外，客户端侧的连接池管理机制也值得怀疑。部分RPC框架会缓存长连接并定期保活。如果服务端因负载过高而主动断开了空闲连接，但客户端未能及时感知并剔除坏连接，那么在下次调用时就会尝试使用一个已失效的socket，导致资源泄漏和调用失败。建议查看框架的health-check参数，确保其配置了合理的空闲连接扫描周期。
实战技巧：三分钟内的紧急止血动作
若以上排查步骤过于繁琐，而你仅剩最后30秒，请执行以下两个应急操作来快速恢复服务。第一，检查是否近期有发布变更。如果有，请立即在负载均衡器上摘除故障节点的权重，使其流量归零，然后回滚代码版本。第二，在客户端开启RPC失败自动重试的开关，并设置重试次数为1或2。但务必注意，重试必须针对幂等接口，否则会引发数据重复写入的风险。
为了防止rpc 服务器不可用问题再次发生，建议在事后复盘时构建一套完整的“网络-线程-GC”三层指标看板。网络层监控TCP重传率与连接数；线程层监控活跃线程数与队列深度；JVM层监控老年代占用与GC耗时。只有当这三层数据全部健康时，RPC调用才能保持足够的韧性。同时，务必为所有接口配置合理的超时时间（建议默认300ms），并区分连接超时与读取超时，避免因单个慢服务拖垮整个调用链。
记住，绝大数此类故障并非服务彻底宕机，而是系统在极端压力下表现出的一种“假死”状态。保持冷静，按照网络、进程、注册中心的顺序进行二分法排除，你就能在黄金三分钟内精准地切开问题，让业务恢复如初。
写回答
全部评论