グローバル展開を支える基盤の裏側 (Behind the Infrastructure Powering Global Expansion)

Mercari · 2025 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài thứ hai của series Global App (ngoài sheet), do kiến trúc sư kiêm SRE của đội viết. Bối cảnh chiến lược ở Mercari 2025.

Bối cảnh

• Hệ sinh thái microservices của Mercari đã trưởng thành: template service, SDK Go, module Terraform "starter kit", SDK trừu tượng hoá cấu hình Kubernetes, và quy trình Production Readiness Check (PRC). Nhưng hệ sinh thái phức tạp và PRC phình to nên dựng một microservice mới mất ít nhất 3 tháng; một mảng kinh doanh mới với ít người lại phải dựng hàng chục service.
• CI/CD của công ty giả định 1 repo, 1 binary, 1 container, 1 Deployment; lệch khỏi khuôn đó thì phải tự viết và tự bảo trì workflow.

Thay đổi chính

• Modular monolith tách được: cả hệ build thành một binary (đi lọt khuôn CI sẵn có), nhưng file cấu hình bật/tắt từng module, giao diện giữa module định nghĩa bằng Protobuf và gọi bằng gRPC. Local và môi trường dev: mọi module trong một process, gọi localhost. Production: nhiều Deployment GKE, mỗi cái bật một tập module và trỏ địa chỉ module kia sang Deployment khác. Phụ thuộc vào microservice còn lại của Mercari thì dev nối vào cụm từ xa bằng mirrord.
• Cấu hình bằng CUE thay biến môi trường: giá trị mặc định một nguồn, mỗi môi trường chỉ ghi phần khác; ConfigMap YAML ghi đè theo Deployment. Hạ tầng (Terraform) cũng viết bằng CUE; ý định tiếp theo là sinh hạ tầng từ cấu hình của framework.
• Database: monolith cũ dùng chung một DB không giới hạn join hay quyền giữa domain; thời microservices mỗi service một DB HA riêng, độc lập nhưng lãng phí với service ít request. Nay: AlloyDB, dùng chung cụm để tiết kiệm, nhưng mỗi module một service account chỉ truy cập được DB của mình; không có transaction xuyên module.
• Monorepo cho backend, frontend, Protobuf và Terraform (deploy Kubernetes vẫn qua monorepo chung của công ty). Theo khảo sát năng suất DX (dùng từ 2024), nhóm này đạt điểm cao hơn trung bình công ty.
• Tầng (tier) và luật phụ thuộc: BFF/Gateway (API cho mobile/web, đổi ngôn ngữ và tiền tệ) → Tier 1 (điều phối luồng nghiệp vụ) → Tier 2 (domain lõi: Product, Order) → Tier 3 (chung, không phụ thuộc marketplace: Search, Notification) → Tier 4 (yêu cầu đặc biệt, như module dữ liệu cá nhân). Request chỉ đi từ trên xuống, được nhảy tầng, cấm gọi ngang cùng tầng; cần gọi ngang được coi là tín hiệu ranh giới domain sai. Gom các service quá nhỏ (ví dụ Like) thành module lớn hơn (Social). Kết quả: 18 module (10/2025), dùng lại Payment và IdP sẵn có.
• Vấn đề còn mở: deploy riêng từng module dựa vào file version tăng tay, không hợp với GitHub Flow (main là nhánh phát hành) nên có thể kéo theo thay đổi ngoài ý muốn. Chi phí dựng ban đầu cao, đang làm cùng đội Platform để áp cho mảng kinh doanh mới.

Vì sao

• Giữ lợi ích vận hành kiểu microservice (tách deploy, chịu lỗi) khi cần, nhưng bỏ chi phí khởi động và vận hành của hàng chục service cho một đội nhỏ; đi lọt khuôn hạ tầng sẵn có để không phải bảo trì hạ tầng riêng như monorepo của Shops.

Bài học cho SWE

• Ranh giới module + luật phụ thuộc một chiều + DB tách theo quyền thay được phần lớn cái microservices mang lại, mà không cần tách process ngay từ đầu.
• Thiết kế để vừa khuôn CI/CD của công ty quan trọng hơn kiến trúc lý tưởng: lệch khuôn là tự gánh chi phí.
• Mỗi service một DB HA là chi phí cố định nhân theo số service; dùng chung cụm với phân quyền theo module là điểm giữa.

Liên quan

• Monolith và microservices — đi và quay lại · Chi phí hạ tầng và build vs buy
• Cùng series: Mercari 2025 · Mercari 2025 · Mercari 2025
• Cùng ý gom service: Segment 2018 · Shopify 2020