内行透底：3步调优，让gRPC服务吞吐量飙200%

　　2025年3月某周三下午三点，我蹲在机房走廊的临时折叠凳上，盯着电脑里的gRPC服务指标，旁边是刚从测试组跑过来的老周，他手里攥着半杯凉透的美式，咖啡渍在纸杯外洇出不规则的圈——这场景我哪年都忘不掉，跟去年某个冬天在另一个机房蹲了六小时调Java服务的样子简直如出一辙，那一次是Netty的线程池配错了，这次是我自己手里的gRPC。

　　我原以为gRPC吞吐量调优是按网上抄的那套来，改改流式设置、调调服务发现的超时，反正都是别人踩过的坑，照着填就行。结果那天测了快俩小时，吞吐量跟我前一周测的基线比，连十分之一的提升都没有，老周把纸杯往走廊垃圾桶一塞，啧了一声说“你这是把gRPC当HTTP玩呢”——后来才发现我把三个核心调整项的顺序搞反了，还漏了最关键的那个。

　　头一个调整项，是把原来每个客户端的并发数从默认值往上提。我一开始没敢提太狠，只提了个小幅度，结果测下来只涨了一点，后来才敢把并发数拉满，那时候才突然反应过来，gRPC的并发不是HTTP的连接数，是每个客户端能发的未完成请求，之前我一直把这俩概念混得稀里糊涂。

　　第二个调整项，是改服务端的线程池参数。我之前看网上说gRPC服务端线程池要设大，就直接把核心线程数和最大线程数都拉得很高，结果测出来吞吐量反而掉了，还多了好多超时请求。后来才懂，gRPC默认用的是内部自己的线程模型，不是Java的那种线程池，改参数得跟着它的线程模型来，不能瞎抄通用配置，这点好多人都没说透，网上的教程全是抄来抄去的。

　　第三个调整项，是把gRPC的压缩级别从默认的“无压缩”改成“中等压缩”。我之前嫌压缩占CPU，不敢开，后来才发现，现在的服务器CPU利用率本来就不高，这点压缩开销完全可以接受，反而能省下来大量的网络带宽，减少跨机房的调用延迟，这对微服务集群的吞吐量影响比线程池大多了——我当时测的时候，还特意拉了监控看CPU利用率，确实只涨了一点点，完全在阈值以内。

　　调完这三个之后，吞吐量直接飙了上去，老周当时凑过来盯着屏幕，眼镜都快贴到显示器上，说这比他之前调的任何一个gRPC服务涨得都多。不过我得说，这里头有个小插曲，我中间改并发数的时候，忘了把客户端的连接池大小也同步改，导致并发请求都挤在少数几个连接上，测出来的吞吐量虚高，后来发现这个问题之后，又把连接池调大了一些，才得到最终的稳定数据。

　　现在回头看，gRPC的调优真不是什么高大上的活，就是把那些别人没说透的细节抠出来，别拿HTTP或者REST的思路套。我之前在别的地方也调过gRPC，那时候踩的坑比这次还多，比如把流式RPC当成一元RPC用，结果吞吐量掉得厉害，后来把流式的窗口调大，才解决问题——所以说，同一个东西，换个场景用，就得换个调法，不能生搬硬套。

　　对了，还有个点，我之前一直没注意，就是gRPC的服务端负载均衡策略，我之前用的是默认的round-robin，后来改成了ring-hash，跨机房调用的延迟降了不少，这也间接提升了吞吐量，老周说这是他调gRPC以来第一个敢改负载均衡的，之前怕改了出问题，不敢动。不过这个是不是真的有用，我还得再测两次，毕竟那天只测了一次，怕有偶然因素。

　　我之前总觉得，调服务吞吐量就得靠加机器、堆资源，没想到gRPC靠这三个调整项就能涨这么多，这事儿给我提了个醒，以后再遇到性能问题，先把自己手里的东西摸透，别上来就抄网上的配置，也别盲目加机器——当然，要是业务量真的涨了，该加还是得加，但调优总比瞎加机器省钱，这是真的。

　　不过我也没敢说这三个步骤就一定通用，毕竟每个服务的场景不一样，比如有的服务是纯CPU密集型，那压缩可能就没用，有的服务是跨机房调用多，那负载均衡就很重要，我现在只敢说，我那天测的这个场景下，这三个步骤确实有用，而且涨的幅度还不小，同行要是遇到类似的问题，倒是可以照着试试，要是没用，那可能是你哪里没调对，不是方法不对。

　　还有个小矛盾，我测完之后，把这三个调整项分享给了另外一组的同事，他们说他们之前调的时候，并发数和线程池的调整顺序跟我反的，结果也涨了不少，看来顺序也不是绝对的，可能得看具体情况——所以说，调优这事儿，真没什么定数，得自己试，别人的经验只能当参考，不能全信。

　　我现在打算下周再测一次，把压缩级别再往上调一档，看看会不会影响CPU利用率，要是CPU还能扛，那说不定还能再涨点吞吐量，老周说要跟我一块测，他手里还有个gRPC服务，也能调调，到时候我们一块测，互相抄抄配置——同行之间，该交流还是得交流，别藏着掖着，不然最后大家都踩坑。

　　对了，我之前在哪个群里见过有人说gRPC调优是玄学，我之前还不信，现在有点信了，不过不是真的玄学，是没摸透它的底层，等摸透了，就会发现其实就是那几个细节的问题，没什么难的——我那天蹲在走廊里，突然就明白过来，之前绕了那么大弯，就是因为没把gRPC的基本原理搞懂，光看配置不看原理，怎么调都白搭。

　　还有个跑题的话，我那天测的时候，旁边的测试组还在测另一个微服务，他们调的是Dubbo，那家伙调起来更复杂，又是序列化又是线程池的，还不如gRPC简单，所以说，选对框架也很重要，要是一开始用gRPC，可能就不会踩那么多坑了——不过现在说这些也晚了，已经走到这一步了，只能慢慢调。

　　最后说一句，调优的时候一定要盯着监控，别光看吞吐量，也要看CPU、内存、延迟这些指标，要是吞吐量涨了，但延迟也涨了，那其实是没用的，我那天测的时候，延迟降了，吞吐量也涨了，这才是真的有用，老周当时还说，这才是调优该有的样子，不是为了吞吐量牺牲别的指标。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!