The Stack That Helped Medium Drive 2.6 Millennia of Reading Time

Medium · 2016 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bài tổng quan stack của trưởng nhóm kỹ thuật Medium, đăng lại từ StackShare. Toàn văn lấy từ Wayback. Số liệu ở thời điểm đăng (khoảng 2016).

Bối cảnh

• Khoảng 25 triệu người đọc mỗi tháng, hàng chục nghìn bài mỗi tuần, tổng 1,4 tỉ phút đọc.
• Stack ban đầu: EC2, app server Node.js, chuyển sang DynamoDB trước khi ra mắt công khai; một server Node xử lý ảnh (gọi GraphicsMagick), một server xử lý hàng đợi SQS cho việc nền; SES, S3, CloudFront, nginx, Datadog, PagerDuty.

Thay đổi chính

• Khoảng một chục service (kiến trúc hướng service). Tiêu chí tách một service: công việc đủ riêng, ít khi phải đổi đồng thời qua ranh giới, và đặc điểm dùng tài nguyên khác.
• App chính vẫn Node (chia sẻ code giữa server và client cho editor). Khi việc nặng chặn event loop, chạy nhiều instance mỗi máy và định tuyến endpoint đắt sang instance riêng để cô lập. Dịch vụ phụ viết bằng Go (dễ build, đóng gói, deploy).
• CDN nhiều nhà cung cấp: CloudFlare cho tài nguyên tĩnh, nhưng gửi 5% sang Fastly và 5% sang CloudFront để giữ cache của họ nóng phòng khi phải chuyển gấp; CloudFlare cho cả traffic ứng dụng để chống DDoS.
• Dữ liệu: DynamoDB vẫn là kho chính, với vấn đề khoá nóng khi bài viral hay fan-out cho người có triệu follower, nên có cụm Redis đứng trước; Aurora cho dữ liệu mới cần truy vấn/lọc linh hoạt; Neo4j (1 master, 2 replica) cho quan hệ người–bài–tag–collection, đi đồ thị để gợi ý.
• Dữ liệu phân tích: Redshift; nạp liên tục dữ liệu lõi từ Dynamo và event log từ S3. Bộ lập lịch nội bộ Conduit chạy job theo điều kiện phụ thuộc đã thoả (ví dụ đủ log một ngày), tách người sản xuất dữ liệu khỏi người dùng. Spark dần thay cho ETL.
• Schema bằng Protocol Buffers cho mọi tầng (app mobile, web, warehouse), có option tuỳ biến cho tên bảng, index, ràng buộc; sinh tài liệu từ .proto.
• Ảnh: server Go, groupcache giảm việc trùng giữa các máy, sau đó là cache S3 bền, cuối cùng mới xử lý theo yêu cầu.
• Mọi client dùng feature flag do server cấp (variants) cho A/B test và che tính năng dở.

Vì sao

• Stack tiến hoá theo vấn đề cụ thể (event loop bị chặn, khoá nóng, cần truy vấn linh hoạt, cần đồ thị) chứ không thay toàn bộ.

Bài học cho SWE

• Tiêu chí tách service nên nói về tần suất thay đổi chung và đặc điểm tài nguyên, không phải về kích thước.
• Dự phòng nhà cung cấp phải được "tập" liên tục: một phần nhỏ traffic giữ cache của nhà cung cấp phụ nóng.
• Thêm kho dữ liệu theo kiểu truy vấn (Aurora, Neo4j) cạnh kho chính thay vì ép mọi thứ vào một DB.

Liên quan

• Pipeline dữ liệu và analytics
• Chọn database theo workload · Monolith và microservices — đi và quay lại
• Cùng công ty: Medium 2015 (khoá nóng của DynamoDB) · Medium 2016 · Medium 2018