在YARP反向代理中实现响应体大小日志记录的技术方案

背景与需求分析

在现代微服务架构中，反向代理作为流量入口承担着关键作用。YARP（Yet Another Reverse Proxy）作为微软开源的灵活反向代理解决方案，开发者经常需要扩展其功能以满足特定业务需求。一个常见的需求是记录完整的请求/响应日志，特别是响应体大小这一关键指标。

技术挑战

传统基于Content-Length头部的方案存在明显局限性：

1. 当服务端采用分块传输编码（Transfer-Encoding: chunked）时，响应头中不会包含Content-Length
2. 直接读取响应流会带来性能问题，特别是在高并发场景下
3. 需要确保日志记录不影响正常的请求处理流程

核心解决方案

流装饰器模式

通过创建自定义的Stream实现类来包装原始响应流，在数据写入时进行字节计数：

public class CountingStreamDecorator : Stream
{
    private readonly Stream _innerStream;
    public long BytesWritten { get; private set; }

    public override ValueTask WriteAsync(ReadOnlyMemory<byte> buffer, 
        CancellationToken cancellationToken = default)
    {
        BytesWritten += buffer.Length;
        return _innerStream.WriteAsync(buffer, cancellationToken);
    }
    
    // 其他必要方法实现...
}

中间件实现要点

1. 执行顺序：必须确保中间件在YARP之前执行
2. 流管理：正确处理流生命周期
3. 性能优化：使用ValueTask减少异步开销

public async Task Invoke(HttpContext context)
{
    var originalStream = context.Response.Body;
    using var countingStream = new CountingStreamDecorator(originalStream);
    
    context.Response.Body = countingStream;
    await _next(context);
    
    // 记录日志
    LogResponseSize(countingStream.BytesWritten);
    
    // 恢复原始流
    context.Response.Body = originalStream;
}

关键技术细节

1. 数据完整性保证：当中间件的next调用完成时，所有响应数据都已写入计数流
2. 分块传输处理：字节计数反映的是实际应用数据，不包含分块编码的开销
3. 资源管理：只释放自定义装饰器，原始流由框架管理

性能优化建议

1. 优先实现ValueTask版本的方法
2. 避免不必要的await操作
3. 考虑使用内存池技术减少分配
4. 对于高频场景，可使用结构体替代类

扩展思考

该方案不仅适用于日志记录，还可应用于：

• 流量监控
• 请求限流
• 数据校验等场景

通过这种非侵入式的流装饰器模式，开发者可以在不修改核心代理逻辑的情况下，灵活扩展YARP的功能，同时保持系统的高性能和稳定性。