构建基于Zig与Playwright的OCI压测代理以诊断读写分离架构性能瓶颈

技术痛点：失真的高并发前端性能测试

在对一个核心交易系统进行大规模性能压测时，我们团队遇到了一个棘手的问题。传统的压测工具，如JMeter或k6，擅长模拟协议层面的负载，但在模拟真实用户行为方面存在天然短板。这些工具无法执行JavaScript、渲染页面或处理复杂的单页应用（SPA）交互，导致测试结果与真实用户体验之间存在巨大鸿沟。

为了弥补这一差距，我们转向了Playwright。它能够以无头模式驱动真实的浏览器内核，完美地模拟了用户操作。初步的方案是使用Node.js编写测试脚本，然后通过Kubernetes Job大规模调度。然而，当我们将并发用户数提升到数千级别时，新的瓶颈出现了：Node.js进程本身以及关联的浏览器实例消耗的内存和CPU资源非常巨大。每个Pod只能稳定运行少数几个Playwright实例，这导致我们需要启动海量的Pod，不仅极大地增加了调度开销和资源成本，更严重的是，压测客户端自身的资源争抢反而成为了干扰测试结果的噪声源。我们需要一个更轻量、更高效的压测代理来“驾驭”Playwright。

初步构想与技术选型

我们的目标是构建一个高性能、低资源占用的压测代理。这个代理的核心职责是接收测试任务、精确地控制一个或多个Playwright实例的生命周期、收集详尽的性能指标，并将所有数据以结构化的格式输出，以便集中分析。

它必须是容器化的（OCI兼容），以便在任何云原生环境中无缝部署和扩展。日志和指标需要能够被ELK Stack轻松采集和解析。

在技术选型上，我们做出了一个非常规的决定：使用Zig作为代理的核心开发语言。

1. 为什么是Zig？ 而不是Go或Rust？

   • 极致的性能与资源控制: Zig提供了与C相媲美的性能和手动内存管理能力，但通过更现代的语言特性（如defer和errdefer）避免了许多C语言的常见陷阱。在我们的场景中，每个代理Pod需要尽可能多地承载并发测试，最大化资源利用率，Zig的低开销是理想选择。
   • 简洁性与C的无缝互操作: 相对于Rust陡峭的学习曲线和复杂的生命周期、所有权概念，Zig的哲学更为直接。它的comptime（编译期执行）能力非常强大，同时与C ABI的兼容性让我们有信心在必要时直接与底层库交互。
   • 编译期保证: Zig的编译器在编译期就能发现许多潜在的运行时错误，例如空指针解引用，这对于构建一个需要在生产环境中大规模运行的稳定性组件至关重要。

2. Playwright: 维持现有的选择，因为它是模拟真实用户行为的最佳工具。

3. OCI (Docker): 行业标准，无需多言。我们将构建一个精简的多阶段Dockerfile来打包我们的Zig应用和Playwright环境。

4. 读写分离架构 (作为被测对象): 我们的目标系统采用了经典的MySQL读写分离架构。这类架构在特定场景下极易出现性能问题，例如主从复制延迟导致的数据不一致、读请求洪峰压垮从库连接池等。我们的压测代理必须能够精确地模拟触发这些问题的用户场景。

5. ELK Stack: 我们已经拥有成熟的ELK基础设施，通过Filebeat采集容器的stdout日志。因此，代理只需将结构化日志输出到标准输出即可。

步骤化实现：从代理核心到数据分析

1. 压测代理核心逻辑 (Zig)

我们的Zig代理并不直接调用Playwright的API，因为Playwright本身是为Node.js、Python等语言设计的。一个务实的方案是，让Zig程序作为父进程，通过进程间通信（IPC）来控制一个轻量的Node.js子进程，由这个子进程来实际执行Playwright操作。这既发挥了Zig的低开销管理优势，也利用了Playwright成熟的生态。我们选择stdio作为最简单的IPC方式。

graph TD
    subgraph OCI Container / K8s Pod
        A[Zig Agent Process]
        B[Node.js Playwright Shim]
        C[Headless Browser Process]
    end

    D[Test Orchestrator]
    E[System Under Test]
    F[ELK Stack]

    D -- Test Config JSON --> A
    A -- Spawns & Controls --> B
    B -- Playwright API --> C
    C -- HTTP/S Requests --> E
    A -- Structured JSON Log (stdout) --> F

Zig Agent (agent.zig):

const std = @import("std");
const json = std.json;
const testing = std.testing;

// 定义测试任务的结构体，从外部输入（例如，stdin或配置文件）
const TestTask = struct {
    test_id: []const u8,
    target_url: []const u8,
    user_id: u32,
    scenario: enum { read_after_write, pure_read },
};

// 定义从Playwright Shim返回的结果
const TestResult = struct {
    test_id: []const u8,
    user_id: u32,
    step: []const u8,
    status: enum { success, failure },
    duration_ms: u64,
    error_message: ?[]const u8 = null,

    pub fn toStructuredLog(self: TestResult, writer: anytype) !void {
        var jw = json.Writer(writer, .{ .whitespace = .minified });
        try jw.object();
        try jw.objectField("test_id");
        try jw.string(self.test_id);
        try jw.objectField("user_id");
        try jw.integer(self.user_id);
        try jw.objectField("step");
        try jw.string(self.step);
        try jw.objectField("status");
        try jw.string(if (self.status == .success) "SUCCESS" else "FAILURE");
        try jw.objectField("duration_ms");
        try jw.integer(self.duration_ms);
        if (self.error_message) |msg| {
            try jw.objectField("error");
            try jw.string(msg);
        } else {
            try jw.objectField("error");
            try jw.null();
        }
        // 添加时间戳和其他元数据，对ELK非常重要
        try jw.objectField("@timestamp");
        try jw.string(std.time.timestamp_iso8601);
        try jw.objectField("log_level");
        try jw.string("INFO");
        try jw.endObject();
        try writer.writeByte('\n');
    }
};

fn runPlaywrightShim(allocator: std.mem.Allocator, task: TestTask) !void {
    const shim_path = "./shim.js"; // Node.js脚本路径
    const node_path = "/usr/bin/node"; // 容器内的Node.js路径

    // 将任务序列化为JSON字符串，通过命令行参数传递给shim
    var task_json_buffer = std.ArrayList(u8).init(allocator);
    defer task_json_buffer.deinit();
    try json.stringify(task, .{}, task_json_buffer.writer());

    var child = std.process.Child.init(&[_][]const u8{ node_path, shim_path, task_json_buffer.items }, allocator);
    child.stdout_behavior = .Pipe;
    child.stderr_behavior = .Pipe;

    try child.spawn();

    // 从shim的stdout读取结果
    var out_stream = child.stdout.?.reader();
    var buffer: [8192]u8 = undefined;
    while (try out_stream.readUntilDelimiter(&buffer, '\n')) |line| {
        // 解析每一行JSON结果
        var result_stream = json.TokenStream.init(line);
        const result = try json.parse(TestResult, &result_stream, .{ .allocator = allocator });
        defer json.parseFree(TestResult, result, .{ .allocator = allocator });

        // 将结果格式化为结构化日志并打印到agent的stdout
        try result.toStructuredLog(std.io.getStdOut().writer());
    }

    const term = try child.wait();
    if (term != .Exited or term.Exited != 0) {
        var stderr_out = std.ArrayList(u8).init(allocator);
        defer stderr_out.deinit();
        try child.stderr.?.reader().readAllArrayList(&stderr_out, 1_000_000);
        std.log.err("Playwright shim failed with code {d}: {s}", .{ term.Exited, stderr_out.items });
    }
}

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // 在真实项目中，这里会从一个任务队列（如Redis或Kafka）接收任务
    // 为了演示，我们硬编码一个任务
    const task = TestTask{
        .test_id = "t-12345",
        .target_url = "http://my-service.internal",
        .user_id = 1,
        .scenario = .read_after_write,
    };

    // 运行测试任务
    try runPlaywrightShim(allocator, task);
}

Node.js Shim (shim.js):

这个脚本非常轻量，它的唯一职责是接收命令行参数，执行Playwright，然后把结果以JSON Lines的格式输出到stdout。

const { chromium } = require('playwright');

// 从stdout输出结构化结果
function emitResult(baseInfo, step, status, duration, error = null) {
    const result = {
        ...baseInfo,
        step,
        status: status ? 'success' : 'failure',
        duration_ms: duration,
        error_message: error ? error.message : null,
    };
    // 使用JSON Lines格式，每条结果占一行，便于Zig父进程解析
    process.stdout.write(JSON.stringify(result) + '\n');
}

async function runTest(task) {
    const browser = await chromium.launch();
    const context = await browser.newContext();
    const page = await context.newPage();
    const baseInfo = { test_id: task.test_id, user_id: task.user_id };

    try {
        if (task.scenario === 'read_after_write') {
            // 场景1：模拟写后读，这是诊断读写分离延迟的关键
            const uniqueData = `user_${task.user_id}_${Date.now()}`;
            
            // 步骤：写入
            let startTime = performance.now();
            try {
                await page.goto(`${task.target_url}/write`, { waitUntil: 'networkidle' });
                await page.fill('#data-input', uniqueData);
                await page.click('#submit-btn');
                await page.waitForSelector('#write-success');
                emitResult(baseInfo, 'write_operation', true, performance.now() - startTime);
            } catch (e) {
                emitResult(baseInfo, 'write_operation', false, performance.now() - startTime, e);
                throw e; // 写入失败，后续步骤没有意义
            }

            // 人为引入一个极小的延迟，模拟用户操作间隔
            // 在高并发下，即使是这个微小的间隔，也可能因为主从延迟而失败
            await page.waitForTimeout(50); 

            // 步骤：读取
            startTime = performance.now();
            try {
                await page.goto(`${task.target_url}/read/${uniqueData}`, { waitUntil: 'networkidle' });
                const content = await page.textContent('#data-display');
                if (content.includes(uniqueData)) {
                    emitResult(baseInfo, 'read_after_write_check', true, performance.now() - startTime);
                } else {
                    throw new Error('Read-after-write consistency failed: data not found');
                }
            } catch (e) {
                emitResult(baseInfo, 'read_after_write_check', false, performance.now() - startTime, e);
            }
        }
        // 可以添加其他场景...

    } finally {
        await browser.close();
    }
}

(async () => {
    try {
        // 从命令行参数第二个位置获取JSON任务配置
        const task = JSON.parse(process.argv[2]);
        await runTest(task);
    } catch (err) {
        // 将严重错误输出到stderr，以便Zig父进程捕获
        console.error(`Shim execution failed: ${err}`);
        process.exit(1);
    }
})();

2. 容器化 (OCI)

一个常见的错误是直接在一个包含所有构建工具的巨大镜像中运行应用。生产级的做法是使用多阶段构建，最终镜像只包含必要的运行时。

Dockerfile:

# --- Stage 1: Zig Builder ---
FROM ziglang/zig:0.11.0 as builder

WORKDIR /src

# 复制Zig源代码
COPY agent.zig .
COPY build.zig .
COPY build.zig.zon .

# Zig在交叉编译方面非常出色，这里我们为Linux amd64构建一个静态链接的发布版本
# 这使得最终镜像可以基于一个极小的基础镜像，如scratch或alpine
RUN zig build -Dtarget=x86_64-linux-musl -Doptimize=ReleaseSafe


# --- Stage 2: Playwright Installer ---
FROM mcr.microsoft.com/playwright:v1.39.0-jammy as playwright-base

WORKDIR /app

# 复制Node.js shim
COPY shim.js .
# 复制package.json并安装依赖
COPY package.json .
COPY package-lock.json .
RUN npm ci


# --- Stage 3: Final Image ---
FROM mcr.microsoft.com/playwright:v1.39.0-jammy

WORKDIR /app

# 从builder阶段复制编译好的Zig agent
COPY --from=builder /src/zig-out/bin/zig-playwright-agent .

# 从playwright-base阶段复制Node.js shim和其依赖
COPY --from=playwright-base /app/shim.js .
COPY --from=playwright-base /app/node_modules ./node_modules

# 设置入口点
ENTRYPOINT ["./zig-playwright-agent"]

package.json 只需要一个依赖：

{
  "name": "playwright-shim",
  "version": "1.0.0",
  "dependencies": {
    "playwright": "^1.39.0"
  }
}

这个构建过程的产物是一个包含了Zig可执行文件、Node.js脚本和完整Playwright浏览器环境的OCI镜像。它轻量且自包含，可以被部署到任何Kubernetes集群。

3. ELK数据分析

当成百上千个这样的代理Pod运行时，它们的stdout会产生海量的结构化JSON日志。这些日志被Filebeat捕获，发送到Logstash进行简单的预处理（如果需要），最终索引到Elasticsearch中。

在Kibana中，我们不再是查看杂乱无章的文本日志，而是可以对结构化数据进行强大的聚合分析。我们创建了一个仪表盘，专门用于诊断读写分离架构的性能瓶颈：

1. P95/P99 响应时间趋势图 (分操作类型):

   • X轴: 时间 (@timestamp)
   • Y轴: 响应时间 (duration_ms)
   • 聚合方式: Percentiles (95th, 99th)
   • 拆分序列: 按step.keyword字段拆分 (例如, write_operation, read_after_write_check)。
   • 观察点: 在高并发下，write_operation的延迟可能保持稳定，但read_after_write_check的延迟会急剧上升。这直接暴露了主从复制的延迟成为了瓶颈。

2. 读写一致性失败率饼图:

   • 聚合方式: Count
   • 拆分扇区: 按status.keyword字段拆分 (SUCCESS, FAILURE)
   • 过滤条件: step.keyword IS read_after_write_check
   • 观察点: 这个图表直观地显示了有多少比例的“读后写”操作因为数据不一致而失败。在真实项目中，这个比例是衡量用户体验的一个关键SLI。

3. 错误信息排行榜:

   • 类型: Data Table
   • 聚合方式: Count
   • 拆分行: 按error.keyword字段拆分
   • 观察点: 可以快速定位最常见的失败原因，是“数据未找到”，还是“页面超时”，或是“数据库连接池耗尽”等被测系统返回的错误。

通过这个仪表盘，我们清晰地看到，当并发用户超过5000时，尽管主库写入性能依然良好，但从库的复制延迟开始超过50ms，导致约15%的读写一致性检查失败。同时，从库的CPU使用率也达到了瓶颈。这是传统压测工具极难发现的、与业务场景强相关的性能问题。

局限性与未来迭代路径

这个方案虽然解决了我们最初的核心痛点，但并非完美。一个务实的工程师必须认识到它的边界：

1. IPC开销: 当前基于stdio的IPC机制虽然简单，但在极高吞吐量的场景下（例如单个Zig Agent控制数十个并发Playwright），其序列化和管道通信的开销可能会成为新的瓶颈。未来的版本可以考虑使用更高效的IPC，如Unix Domain Sockets或gRPC，但这会增加实现的复杂性。

2. 任务调度与分发: 本文专注于“压测代理”本身，并未实现一个完整的“压测平台”。一个成熟的系统需要一个中心化的任务调度器，负责向Kubernetes集群动态地分发、启动和停止测试任务，并聚合最终的测试报告。

3. 指标与日志分离: 将性能指标（如响应时间）和诊断日志混合在一起，并通过ELK进行分析，对于中等规模的测试是可行的。但在更大规模的系统中，更理想的架构是将指标（Metrics）通过Prometheus这样的时序数据库进行收集和告警，而将详细的错误日志（Logs）和链路追踪（Traces）保留在ELK或类似系统中。我们的Zig Agent可以被扩展，以支持向Prometheus Pushgateway或本地Agent暴露指标。

4. 资源隔离: 当前模型是一个Pod运行一个Zig Agent进程。可以探索在单个、资源更充足的Pod中运行一个Zig Agent，并由它管理多个Node.js Shim子进程，这需要Zig程序内部实现更复杂的并发管理和资源调度逻辑，但有可能进一步提高部署密度。