Scaling up your microservice testing with Apache Spark, Part 2

Stripe · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Phần 2; phần 1 (vì sao replay): Stripe 2026.

Bối cảnh

• Câu hỏi của phần này: dựng harness replay thế nào mà không tạo ra bản thứ hai của service (bản đó sẽ lệch production và cho sự tự tin giả).

Thay đổi chính

• Biến phụ thuộc thành dữ liệu: service thật đọc DB, cấu hình, feature flag, gọi service khác. Trong harness: đọc trực tiếp thành join với snapshot lịch sử; luật có phiên bản nạp như đầu vào; cấu hình merchant join theo merchant và ngày hiệu lực; điều kiện chương trình là trạng thái theo thời gian; lời gọi service khác thay bằng cặp request/response đã log; tác dụng phụ ghi thành dòng output thay vì thực thi. Độ trung thực chỉ cần đủ cho quyết định đang kiểm (đổi bảng giá cần đúng phiên bản luật; đổi điều kiện chương trình cần trạng thái đủ điều kiện).
• Tách lõi quyết định khỏi điều phối: trước đó hàm call vừa nạp ngữ cảnh, tính phí, ghi storage, publish, phát metric. Sau khi tách: service map request + ngữ cảnh sống thành ReplayInput, gọi decisionEngine.evaluate(input) (một thư viện), rồi tự lo ghi, publish, metric. Spark dựng cùng ReplayInput từ dataset lịch sử và gọi cùng engine.
• Wrapper Spark mỏng: đọc bảng sự kiện, snapshot luật, ngữ cảnh merchant → dựng input → với mỗi input chạy engine hiện tại và engine ứng viên → ghi bảng diff. Spark lo nạp dữ liệu, join, phân tán, ghi; luật nghiệp vụ chỉ nằm trong thư viện dùng chung.
• Schema output để debug, không chỉ để so: định danh để truy về đầu vào gốc, output hiện tại và ứng viên, giá trị trung gian, đường luật đã đi, chiều phân tích cho người đọc nghiệp vụ. "Phí đã đổi" là chưa đủ; diff phải nói vì sao.
• Giới hạn được nói rõ: replay chỉ tốt bằng trạng thái quyết định dựng lại được, thiếu ngữ cảnh thì kết quả trông chính xác mà sai. Service có trạng thái phân tán, sự kiện bất đồng bộ, phụ thuộc thay đổi theo thời gian có tác dụng phụ làm đổi đầu vào tương lai; hành vi của bên ngoài (ngân hàng phát hành, tỉ lệ duyệt) không dự đoán được. Replay là một lớp bằng chứng, không phải mô phỏng toàn bộ production.

Vì sao

• Theo Stripe, migration là lúc tốt nhất để dựng harness: đội đã đang viết bản mới và vạch lại ranh giới, harness lập tức giảm rủi ro cho chính migration đó (replay traffic lịch sử qua bản cũ và mới, lấy diff), rồi tiếp tục dùng cho refactor, đổi bảng giá, viết lại có AI hỗ trợ.

Bài học cho SWE

• Muốn kiểm offline một service, ép logic quyết định thành hàm thuần nhận đầu vào đầy đủ; việc này cũng làm unit test, migrate và review dễ hơn.
• Bắt đầu nhỏ: một đường quyết định đắt khi hồi quy, một golden dataset an toàn về riêng tư trong CI, rồi mới mở rộng mô hình phụ thuộc cho replay lớn.

Liên quan

• Stripe 2026 · Stripe 2026 · GitLab 2021 (thí nghiệm chạy hai đường song song trước khi đổi)
• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) · Migration không downtime