Microservice Architecture at Medium

Medium · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

• Medium bắt đầu năm 2012 bằng một monolith Node.js; có vài service vệ tinh nhưng chưa có chiến lược.
• Đầu 2018 chuyển sang microservice một cách có hệ thống, vì monolith thành điểm nghẽn theo bốn cách (theo Medium, xếp theo độ gấp):
  1. Hiệu năng: việc nặng CPU và I/O không hợp Node.js; tối ưu dần trong monolith không hiệu quả.
  2. Tốc độ phát triển: mọi người sửa chung một app, sợ thay đổi lớn; một commit xấu chặn deploy của tất cả.
  3. Scale theo loại việc: phải scale cả app cho vài tác vụ nặng; đã thử tách loại request ra process Node.js riêng nhưng các "monolith thu nhỏ" vẫn dính nhau.
  4. Thử công nghệ mới khó.

Thay đổi chính

• Định nghĩa microservice bằng ba nguyên tắc: một mục đích, ghép lỏng, gắn kết cao (hành vi và dữ liệu liên quan nằm cùng chỗ). Thiếu cái thứ ba thì thành "distributed monolith", theo Medium tệ hơn monolith tập trung.
• Bảy chiến lược:
  • Chỉ tạo service mới khi có giá trị sản phẩm hoặc kỹ thuật rõ; "mười năm nữa vẫn còn monolith cũng được".
  • Không chia sẻ persistent storage giữa service: một loại dữ liệu chỉ một service sở hữu; service khác gọi API, nhận sự kiện qua queue, hoặc giữ bản sao chỉ đọc qua ETL. Ví dụ: service gợi ý không đọc thẳng bảng post trong DynamoDB.
  • Tách "xây service" khỏi "chạy service": Istio + Envoy sidecar cho mạng, gRPC cho giao tiếp, container trên ECS chuyển dần sang Kubernetes, hệ build/deploy riêng BBFD (service khai cổng, lệnh build/test/start, phần còn lại do nền tảng lo).
  • Observability đồng nhất ngay từ đầu: mỗi service tự có dashboard, alert, log search Datadog; LightStep cho tracing.
  • Không phải service nào cũng viết lại từ đầu: nếu Node.js hợp và code tốt thì bóc khỏi monolith.
  • Tôn trọng lỗi: test lỗi là một mục trong checklist service mới.
  • Tránh "microservice syndromes" từ ngày đầu: quá nhiều ngôn ngữ, service mô hình hoá kém, dữ liệu vẫn dùng chung, thiếu bức tranh toàn hệ.
• Kết quả theo Medium: thay đổi lên production trong vòng một giờ.

Vì sao

• Monolith của Medium đã được module hoá tốt: mỗi loại dữ liệu có tầng data (CRUD) và tầng service (logic, API công khai), service không dùng chung store. Nhờ vậy bóc từng phần ra service khá an toàn.
• Theo Medium: team nhỏ nên bắt đầu bằng monolith, nhưng thiết kế nó theo đúng ba nguyên tắc trên, chỉ khác là chạy chung process.

Bài học cho SWE

• Hỏi "vì sao bây giờ?", không chỉ "vì sao" (Monolith và microservices — đi và quay lại).
• Database dùng chung là cách nhanh nhất để có distributed monolith; quyền sở hữu dữ liệu quan trọng hơn kích thước service.
• Nền tảng lo mạng, RPC, deploy, observability để team chỉ viết logic (Nền tảng nội bộ cho service (đường ray chung)).
• Monolith module hoá tốt là tiền đề rẻ nhất cho việc tách sau này.

Liên quan

• Medium 2015 (cùng công ty, DynamoDB) · Medium 2020 (hai năm sau: hàng đợi và service không do mình sở hữu)
• Monolith và microservices — đi và quay lại · Nền tảng nội bộ cho service (đường ray chung)