How we built the Tinder API Gateway

Tinder · 2022 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Tinder có hơn 500 microservice (2022) nói chuyện với nhau qua service mesh (Envoy); dùng ở 190 quốc gia, nhận cả traffic thật lẫn traffic của kẻ xấu.
Trước TAG: mỗi team ứng dụng dùng một API gateway bên thứ ba khác nhau, trên các stack khác nhau. Hậu quả: khó bảo trì, không chia sẻ được thành phần, chậm ra production, quản lý session không thống nhất giữa các API.
Đã xét AWS API Gateway, Apigee, Tyk, Kong, Express Gateway, KrakenD. Theo Tinder: một số không hợp với mesh Envoy, một số nặng cấu hình và plugin, khó học, ít hỗ trợ ngôn ngữ Tinder dùng; Tinder cũng muốn tự viết plugin nhanh.

Framework JVM trên Spring Cloud Gateway. Mỗi team tự dựng instance gateway của mình chỉ bằng cấu hình YAML/JSON theo môi trường ("Route As Configuration"), scale độc lập, chạy như một service Kubernetes.
Thành phần: route khai báo bằng cấu hình; service discovery qua mesh; filter dựng sẵn (weighted routing, biến đổi request/response, HTTP → gRPC); filter tuỳ biến theo route; filter toàn cục (auth, metric) áp cho mọi route.
Route và filter được dựng hết lúc khởi động, nên không tốn thời gian xử lý cấu hình lúc chạy.
Luồng một request: tra quốc gia từ IP (dùng cho rate limit, chặn) → quét schema request/response gửi bất đồng bộ qua Amazon MSK (không gửi dữ liệu, chỉ schema; dùng sinh tài liệu API, phát hiện bot) → session management là một filter chung → khớp route → tìm backend qua Envoy → pre-filter → backend → post-filter.
TAG được các thương hiệu khác của Match Group (Hinge, OkCupid, PlentyOfFish…) dùng lại. Đang làm cập nhật route động không cần deploy lại.

Mọi API công khai đi qua một framework chung thì bắt buộc qua review bảo mật trước khi lộ ra ngoài, và các chính sách chung (session, phát hiện bot) chỉ cần viết một lần.
Theo Tinder, cấu hình thay cho code giúp các team ra tính năng nhanh hơn (Recommendations, Match, Revenue API thay đổi thường xuyên).

Mẫu "framework chung, instance riêng": nền tảng giữ phần chung (auth, session, quan sát), team giữ quyền scale và cấu hình riêng (Nền tảng nội bộ cho service (đường ray chung)).
Khi microservice nhiều lên, sự phân mảnh ở rìa (mỗi team một gateway) là một dạng nợ cần gom lại (Monolith và microservices — đi và quay lại).