Hệ thống ngày thường phục vụ khoảng 500 người dùng đồng thời, nhưng vào cao điểm nhảy lên 8.000–10.000 trong vài phút. Mua phần cứng theo mức cao điểm thì lãng phí, giữ nguyên cấu hình thường ngày thì sập đúng lúc quan trọng nhất.
Đây là kiến trúc tham khảo, không phải hồ sơ khách hàng. Trang này không chứa tên khách hàng hay số liệu của dự án cụ thể nào.
Bài toán
Hệ thống phục vụ ổn định khoảng 500 người dùng đồng thời trong ngày thường. Vào đợt cao điểm — khuyến mãi, mở cổng đăng ký, hạn nộp hồ sơ — con số này vọt lên 8.000 đến 10.000 trong vòng vài phút, kéo dài vài giờ rồi trở về bình thường.
Mua phần cứng cho mức đỉnh nghĩa là 95% thời gian trong năm nuôi hạ tầng nằm không. Giữ nguyên cấu hình ngày thường thì hệ thống sập đúng lúc quan trọng nhất, và đó thường là lúc doanh thu tập trung.
Kiến trúc đề xuất
Tách tầng để mở rộng độc lập
Ba tầng tách rời: tầng phục vụ nội dung tĩnh, tầng ứng dụng xử lý nghiệp vụ, tầng cơ sở dữ liệu. Mỗi tầng mở rộng theo nhu cầu riêng, vì chúng chịu áp lực khác nhau.
Đẩy tối đa ra biên
Ảnh, CSS, JavaScript, và cả những trang có nội dung ít đổi được phục vụ từ mạng phân phối nội dung. Phần lớn lưu lượng cao điểm không bao giờ chạm tới máy chủ ứng dụng. Đây là biện pháp cho hiệu quả cao nhất trên chi phí bỏ ra.
Tầng ứng dụng tự nhân bản
Máy chủ ứng dụng không lưu trạng thái, cho phép thêm bớt tùy ý. Ngưỡng kích hoạt đặt theo độ trễ phản hồi chứ không theo mức dùng CPU — độ trễ mới là thứ người dùng cảm nhận được.
Cơ sở dữ liệu tách đọc và ghi
Đây là nút thắt khó nhất, vì cơ sở dữ liệu không nhân bản dễ như tầng ứng dụng. Cách xử lý: một máy chủ nhận ghi, nhiều bản sao chỉ đọc chia tải truy vấn. Bổ sung tầng đệm cho các truy vấn lặp lại nhiều.
Hàng đợi cho việc không cần tức thời
Gửi email xác nhận, xuất báo cáo, đồng bộ sang hệ thống khác — đẩy hết vào hàng đợi xử lý dần. Lúc cao điểm, người dùng nhận phản hồi ngay còn việc nặng chạy sau.
Điểm dễ vỡ và cách xử lý
| Điểm yếu | Cách xử lý |
|---|---|
| Mở rộng không kịp tốc độ tăng tải | Nâng trước theo lịch nếu biết giờ cao điểm; giữ sẵn một phần dự phòng |
| Tầng đệm rỗng sau khi khởi động lại | Nạp trước dữ liệu nóng vào đệm trước giờ cao điểm |
| Cơ sở dữ liệu hết kết nối | Dùng bộ gộp kết nối, đặt giới hạn cho từng dịch vụ |
| Một dịch vụ chậm kéo sập cả hệ thống | Đặt thời gian chờ tối đa và cơ chế ngắt mạch |
| Hoá đơn cloud vượt dự toán | Đặt trần chi phí và cảnh báo ngân sách theo ngày |
Lộ trình triển khai
- Đo hiện trạng. Không tối ưu khi chưa biết nút thắt nằm ở đâu. Thường kết quả đo làm nhiều người bất ngờ — nút thắt hay nằm ở một truy vấn cơ sở dữ liệu chứ không phải ở CPU máy chủ.
- Sửa phần rẻ trước. Thêm chỉ mục cho truy vấn chậm, bật nén, đẩy nội dung tĩnh ra CDN. Nhiều hệ thống chỉ cần bước này đã đủ.
- Tách trạng thái khỏi tầng ứng dụng. Điều kiện bắt buộc để nhân bản được.
- Dựng cơ chế tự mở rộng và kiểm thử tải. Bắn tải giả lập bằng 1,5 lần đỉnh dự kiến.
- Diễn tập trước ngày cao điểm. Chạy thử toàn bộ kịch bản, gồm cả kịch bản hỏng.
Điều thường bị bỏ qua
Kiểm thử tải phải mô phỏng hành vi thật, không phải gọi liên tục một đường dẫn. Người dùng thật đăng nhập, tìm kiếm, xem chi tiết, thêm giỏ hàng, thanh toán — mỗi bước tạo áp lực khác nhau lên hệ thống. Một bài kiểm thử tải sai cách sẽ cho kết quả đẹp rồi hệ thống vẫn sập vào ngày thật.
Bạn cần chuẩn bị gì
- Số liệu tải thực tế ít nhất 6 tháng gần nhất, nếu có
- Ước lượng đỉnh dự kiến và thời điểm xảy ra
- Ngưỡng chấp nhận được: hệ thống chậm bao nhiêu thì coi là hỏng
- Ngân sách trần cho hạ tầng lúc cao điểm
Bài viết được biên soạn từ kinh nghiệm triển khai hạ tầng và phần mềm của đội ngũ. Không nhận tài trợ, không quảng cáo sản phẩm.