第3章节点通信测试

第3章：节点通信测试——RPC调用与消息队列实战

节点通信，说白了就是多节点系统的「血管」。血管堵了，系统就瘫了。我在做分布式交易系统测试时，最怕的就是通信环节出问题——因为问题往往藏得很深，表面上看一切正常，一到高并发就原形毕露。

这一章，我们聚焦两个核心：RPC调用测试和消息队列测试。再加上网络延迟与丢包模拟，这三板斧砍下去，节点通信的坑基本能填平七八成。

3.1 RPC调用测试：gRPC与Dubbo

RPC测试，我个人的习惯是「先接口，后压力，再异常」。别一上来就搞并发，先把单次调用的正确性吃透。

3.1.1 gRPC测试要点

gRPC基于HTTP/2和ProtoBuf，性能确实好。但测试起来有几个坑，我踩过不止一次。

核心测试维度：

ProtoBuf兼容性：前后端proto文件是否一致？字段编号变了没？
双向流测试：服务端流、客户端流、双向流，每种模式都要覆盖
超时与重试：默认超时是无穷大？别信，一定要显式设置
拦截器测试：认证、日志、限流拦截器是否正常工作

举个例子，我曾经遇到一个线上问题：客户端和服务端的proto文件版本不一致，新增了一个字段，但编号冲突了。结果数据解析出来全是乱码。嗯，从那以后我要求每次发布前必须跑一遍proto兼容性检查。

# gRPC基础测试示例（Python）
import grpc
import order_pb2
import order_pb2_grpc

def test_create_order():
    channel = grpc.insecure_channel('localhost:50051')
    stub = order_pb2_grpc.OrderServiceStub(channel)
    
    # 正常请求
    request = order_pb2.CreateOrderRequest(
        user_id="U10001",
        product_id="P20002",
        quantity=1,
        price=99.99
    )
    response = stub.CreateOrder(request, timeout=5)
    assert response.order_id != ""
    print(f"订单创建成功: {response.order_id}")
    
    # 异常场景：超时测试
    try:
        stub.CreateOrder(request, timeout=0.001)  # 故意设极短超时
    except grpc.RpcError as e:
        assert e.code() == grpc.StatusCode.DEADLINE_EXCEEDED
        print("超时异常捕获正确")

我的小技巧：gRPC测试一定要开grpc.max_receive_message_length，默认4MB，大消息直接挂。我吃过这个亏，一个批量查询接口返回了5MB数据，客户端直接报错，排查了半天。

3.1.2 Dubbo测试要点

Dubbo在Java生态里用得很多。测试时我重点关注两点：服务发现和负载均衡。

测试项	测试方法	常见问题
服务注册与发现	启动/停止Provider，观察Consumer能否感知	注册中心抖动导致短暂不可用
负载均衡策略	多Provider实例，验证请求分布	一致性哈希偏斜
集群容错	模拟Provider宕机，验证Failover/Failfast	重试风暴
隐式参数传递	通过RpcContext传递，验证透传	线程上下文丢失

Dubbo的SPI扩展机制很灵活，但也容易出问题。我记得有一次，团队自定义了一个负载均衡策略，结果没注册到SPI文件里，运行时一直走默认策略，压测数据对不上。排查了两天才发现是少写了一行配置。

警告：Dubbo的线程池隔离一定要测。我曾经见过一个慢接口把整个Dubbo线程池占满，导致所有RPC调用都超时。建议给不同接口配置独立的线程池，压测时重点观察线程池耗尽场景。

3.2 消息队列测试：Kafka与RabbitMQ

消息队列测试，说白了就是「生产-消费」链条的可靠性验证。我习惯从三个角度切入：消息不丢、消息不乱、消息不重复。

3.2.1 Kafka测试要点

Kafka的吞吐量确实高，但测试起来要注意的细节也不少。

分区顺序性：同一个key的消息是否发到同一分区？顺序是否保证？
Exactly Once语义：幂等生产者+事务，是否真的不重复？
消费者Rebalance：消费者加入/退出时，分区重分配是否平滑？
消息积压：生产速度 > 消费速度时，积压多久会触发报警？

# Kafka消息可靠性测试示例
from kafka import KafkaProducer, KafkaConsumer
import json

# 测试消息不丢失
def test_message_durability():
    producer = KafkaProducer(
        bootstrap_servers=['localhost:9092'],
        acks='all',  # 所有副本确认
        retries=3,
        enable_idempotence=True
    )
    
    # 发送1000条消息
    for i in range(1000):
        future = producer.send('test-topic', 
                               value=json.dumps({'seq': i}).encode())
        record_metadata = future.get(timeout=10)
        assert record_metadata.offset >= 0
    
    producer.flush()
    
    # 消费验证
    consumer = KafkaConsumer(
        'test-topic',
        bootstrap_servers=['localhost:9092'],
        auto_offset_reset='earliest',
        enable_auto_commit=False
    )
    
    received = set()
    for msg in consumer:
        data = json.loads(msg.value)
        received.add(data['seq'])
        if len(received) == 1000:
            break
    
    assert len(received) == 1000
    print(f"消息完整性验证通过，共{len(received)}条")

避坑指南：我曾经在生产环境遇到过Kafka消息重复消费的问题。原因是消费者处理时间过长，超过了max.poll.interval.ms默认值（5分钟），触发了Rebalance。解决方案是调大这个参数，或者缩短单条消息的处理时间。你想想看，一个批处理任务跑了6分钟，结果被判定为「死亡」，多冤。

3.2.2 RabbitMQ测试要点

RabbitMQ基于AMQP协议，路由灵活，但测试时重点在交换机-队列绑定和死信处理。

测试场景	验证点	工具/方法
Direct交换机	路由键精确匹配	发送不同routing_key，验证队列接收
Topic交换机	通配符匹配规则	发送 order.create, order.update 等
死信队列	消息被拒绝/过期后是否进入DLQ	设置TTL，观察死信流转
消费者确认	手动ACK vs 自动ACK	模拟消费者崩溃，观察消息是否重新入队

RabbitMQ的死信队列是个好东西。我有个项目，订单超时未支付就自动取消，就是靠死信队列实现的。测试时一定要验证：消息过期后，是否真的进入了正确的死信队列？死信队列的消费者是否正常处理？

注意：RabbitMQ的prefetch_count设置不当会导致消息倾斜。比如你设置了prefetch=1，但某个消费者处理特别慢，其他消费者就会空闲。我建议压测时监控每个消费者的处理速率，确保负载均衡。

3.3 网络延迟与丢包模拟

网络模拟，说白了就是「把真实环境的问题提前暴露出来」。我在测试环境里用tc（Traffic Control）模拟各种网络状况，效果很好。

3.3.1 使用tc模拟网络

# 模拟网络延迟 100ms
sudo tc qdisc add dev eth0 root netem delay 100ms

# 模拟丢包 5%
sudo tc qdisc add dev eth0 root netem loss 5%

# 模拟延迟+丢包+抖动
sudo tc qdisc add dev eth0 root netem delay 50ms 20ms loss 3% 25%

# 清除模拟规则
sudo tc qdisc del dev eth0 root

为什么要模拟网络抖动？因为真实网络不是稳定的。我记得有一次线上故障，两个机房之间的专线偶尔出现200ms的延迟抖动，导致RPC超时重试，重试又加剧了负载，最终雪崩。如果提前在测试环境模拟过这种场景，就能提前发现并优化超时策略。

3.3.2 混沌工程与网络故障注入

除了tc，我还会用混沌工程工具做更复杂的网络故障注入。比如：

随机断开连接：模拟网络闪断
带宽限制：模拟网络拥塞
DNS故障：模拟服务发现失败

网络模拟测试清单：

正常网络：验证基线性能
高延迟（100ms/200ms/500ms）：验证超时机制
丢包（1%/5%/10%）：验证重试和幂等性
延迟抖动：验证自适应算法
网络分区：验证集群容错

嗯，这里要注意：网络模拟一定要在隔离环境做，别影响到其他团队。我一般用Docker容器做网络模拟，每个容器独立配置tc规则，互不干扰。

小结

节点通信测试，核心就三件事：RPC调用的正确性与稳定性、消息队列的可靠性与顺序性、网络异常的容错性。这三件事做好了，分布式系统的通信层就稳了八成。

我个人习惯把通信测试做成自动化回归用例，每次代码变更都跑一遍。别等到上线了才发现通信有问题，那时候排查成本就高了。

📚 课程目录