Migrating 300+ namespaces from self-hosted Temporal to Temporal Cloud
Bài tóm tắt Coinbase 2026 4. Điều chỉnh Độ khó: Khó
Coinbase · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc
Site chặn crawler; ghi chú viết từ toàn văn đọc qua trình duyệt.
Bối cảnh
- Temporal là lớp durable execution dưới nhiều luồng của Coinbase: trading, thanh toán, settlement, quy trình pháp lý (xoá dữ liệu GDPR, KYC), ETL, backfill, cấp phát hạ tầng.
- Ban đầu: một cụm Temporal dùng chung với tầng persistence tự viết. Giúp các team áp dụng nhanh, nhưng theo Coinbase bốn vấn đề lớn dần cùng nhau: tail latency phụ thuộc hàng xóm (batch của team này là p95 của team kia), vận hành cụm thành một sản phẩm riêng có on-call riêng và nâng cấp chậm vì persistence tự viết phải theo từng phiên bản, blast radius một cụm cho tất cả, khó bổ sung yêu cầu bảo mật và tuân thủ.
- Đặc thù: một workflow đang chạy thuộc về cụm giữ lịch sử event của nó. Không thể trỏ client sang cụm mới rồi để retry lo; nếu cả hai cụm cùng nhận start cho một workflow ID thì mất bảo đảm duy nhất.
Thay đổi chính
- Chuyển hơn 300 namespace của hơn 300 service sang Temporal Cloud; stack tự host cũ đã gỡ. Ràng buộc: không downtime có kế hoạch cho trading/thanh toán, có đường lui ở mọi bước, rollout dần, ít phiền cho team sản phẩm (ràng buộc này định hình thiết kế nhiều nhất).
- Hai pha: trước tiên chuyển sang Temporal mã nguồn mở trên Aurora do chính Coinbase vận hành (trong lúc Temporal Cloud còn chờ duyệt nhà cung cấp). Theo Coinbase đây là điều hữu ích nhất: runbook, dashboard, cơ chế rollback được kiểm trên traffic thật trước khi có vendor; pha 2 (Aurora → Cloud) gần như chỉ còn là cấu hình.
- Chiến lược 1, drain and switch: tắt tạo workflow mới bằng feature flag, chờ workflow cũ chạy xong, đổi cấu hình, bật lại. Đơn giản, dùng cho phần lớn namespace; nhưng cần dừng tạo mới, không rollout theo %, và rollback hết rẻ khi workflow mới đã chạy bên cụm mới. Với workflow mở nhiều ngày, chờ drain thành kế hoạch nhiều tuần.
- Chiến lược 2, dual workers (trading, thanh toán, workflow dài): không chuyển workflow đang chạy. Worker poll cả hai cụm; chọn cụm là quyết định định tuyến lúc start. Thư viện client Go dùng chung có
MultiClientManager(vẫn đúng interface client của Temporal nên code sản phẩm không đổi) vàMultiClientWorker. Workflow cũ luôn còn worker nên không bị bỏ dở. - Định tuyến theo % cho từng loại workflow, mỗi team tự chọn bậc; rollback là hạ con số, không huỷ, không phát lại. Quyết định phải tất định: băm theo danh tính workflow, không random, để hai lần start cùng ID không vào hai cụm. Lỗi đọc cấu hình thì về cụm cũ.
- Bẫy đã gặp: chính sách reuse workflow ID chỉ có hiệu lực trong một cụm; signal/cancel/terminate gửi tới cả hai cụm; schedule bỏ qua định tuyến %; cron phải chỉ định cụm rõ ràng kẻo chạy hai lần; workflow signal cho nhau phải chuyển cùng nhau; child workflow và continue-as-new đi theo cha; cụm trung gian đã bị thu nhỏ mà quên tăng lại trước khi nhận traffic.
- Bảo mật trước khi chuyển namespace production đầu tiên: PrivateLink; mTLS kèm danh sách SAN/SPIFFE ID cho phép theo namespace (mTLS mặc định chỉ chứng minh cert hợp lệ, không phân quyền service); không cho ghi qua UI/CLI ở production, thay bằng dịch vụ admin có người thứ hai duyệt (chậm hơn CLI khi sự cố, chấp nhận); payload nén và mã hoá trước khi lên Cloud qua codec server tập trung (khoảng 90 triệu request/ngày, encode trung bình 0,29 ms, tháng 5/2026) hoặc mã hoá trong process cho team nhạy latency.
- Quan sát là cổng: mỗi bước chỉ đi tiếp khi số liệu trả lời "an toàn chưa": dashboard chuẩn cho mọi namespace trên cả hai cụm, so sánh tự động, kiểm tra workflow trùng hoặc bị bỏ dở. Dọn dual worker và
replacemodule Go được theo dõi như việc chính thức từ ngày đầu.
Bài học cho SWE
- Hệ có trạng thái gắn với nơi chạy (workflow, session dài) không cutover bằng đổi endpoint; mẫu chung là cho cái cũ chạy hết ở chỗ cũ và định tuyến cái mới bằng quyết định tất định (Migration không downtime).
- Một pha trung gian tự vận hành để luyện quy trình trên traffic thật giảm rủi ro khi bước tiếp theo phụ thuộc vendor.
- Cụm dùng chung giúp áp dụng nhanh lúc đầu rồi thành điểm nghẽn về hiệu năng, vận hành và blast radius; chuyển sang dịch vụ managed là một lựa chọn build vs buy (Nền tảng nội bộ cho service (đường ray chung)).
- Đặt seam vào thư viện client dùng chung là cách cho hàng trăm team tự chuyển theo lịch của mình.
Liên quan
Migration không downtimeNền tảng nội bộ cho service (đường ray chung)Xác thực và phân quyền (authn/authz)
Được nhắc tới trong
Chủ đề (3)
Công ty (1)
Bài tóm tắt (3)