Ý chính: Phần lớn thời gian gián đoạn xuất hiện khi hệ thống đang thay đổi, không chỉ khi hệ thống thiếu máy chủ.
Thuật ngữ trong bài: Readiness: máy chủ đã sẵn sàng nhận lưu lượng; drain: ngừng nhận việc mới và hoàn tất việc đang chạy; canary: đưa phiên bản mới cho một phần nhỏ người dùng.
Bài toán thực tế
Máy chủ mới có thể nhận lưu lượng trước khi các thành phần phụ thuộc sẵn sàng. Máy chủ cũ cũng có thể bị dừng khi vẫn còn yêu cầu đang xử lý. Chỉ theo dõi CPU trung bình sẽ không phát hiện được hai rủi ro này.
Điểm dễ bị bỏ qua
Độ sẵn sàng không chỉ phụ thuộc vào số lượng máy chủ. Khi triển khai, hệ điều phối, bộ cân bằng tải và ứng dụng phải thống nhất lúc nào một tiến trình được nhận lưu lượng và lúc nào nó đã xử lý xong để có thể dừng.
Readiness quá lỏng sẽ đưa lưu lượng vào máy chưa sẵn sàng; readiness phụ thuộc quá nhiều dịch vụ bên ngoài lại có thể loại toàn bộ máy khỏe khỏi hệ thống.
Luồng xử lý
P99 và mức bão hòa→Autoscaler
Thêm năng lực sớm→Readiness
Kiểm tra dịch vụ phụ thuộc→Bộ cân bằng tải
Chuyển lưu lượng an toàn
Thiết kế và triển khai
Mở rộng trước khi bão hòa
Theo dõi p95/p99 độ trễ, số yêu cầu đang xử lý, tuổi queue và mức điểm bão hòa (mức bão hòa tài nguyên) của dịch vụ phụ thuộc.
Readiness có ý nghĩa nhưng nên cục bộ
Chỉ kiểm tra cấu hình và các dịch vụ phụ thuộc cục bộ thật sự cần để phục vụ lưu lượng.
Drain trước khi kết thúc
Khi nhận SIGTERM, hãy chuyển tiến trình sang trạng thái unready và chờ bộ cân bằng tải cập nhật.
Đi sâu vào thiết kế
Kiểm tra trạng thái mô tả vòng đời, không phải sức khỏe chung
Startup kiểm tra trạng thái (kiểm tra giai đoạn khởi động) bảo vệ quá trình khởi tạo chậm khỏi bị liveness restart. Liveness nên trả lời process còn tiến triển được hay không, và thường chỉ kiểm tra cục bộ: một cơ sở dữ liệu sự cố gián đoạn không nên khiến toàn bộ application replica restart cùng lúc.
Lập kế hoạch năng lực phải tính cả lúc thay đổi
Lưu lượng bình thường cộng thêm một rolling cập nhật sẽ cần surge năng lực dự phòng (phần năng lực dự phòng cho lúc thay đổi). Hãy tính minimum healthy replica từ peak mức xử lý đồng thời, safe mức xử lý đồng thời của mỗi tiến trình và trường hợp mất một miền sự cố (vùng có thể hỏng cùng nhau).
Cách triển khai
- Mở rộng dựa trên mức bão hòa, độ trễ P99 và tuổi hàng đợi thay vì chỉ một chỉ số trung bình.
- Giữ liveness đơn giản; dùng readiness để quyết định một tiến trình có được nhận lưu lượng hay không.
- Khi dừng, ngừng nhận lưu lượng mới, hoàn tất các yêu cầu đang xử lý rồi mới đóng kết nối phụ thuộc.
Mã minh họa: Máy trạng thái khi dừng ứng dụng
RUNNING --SIGTERM--> DRAINING
DRAINING: readiness = false
DRAINING: ngừng nhận queue job mới
DRAINING: chờ loadBalancerPropagation
DRAINING: await inFlightRequests == 0
DRAINING: đóng database và broker pool
DRAINING --deadline--> TERMINATED
terminationGrace >= propagation + maxRequest + cleanupThời hạn dừng phải dài hơn phần lớn yêu cầu hợp lệ nhưng vẫn hữu hạn để một yêu cầu kẹt không giữ tiến trình mãi mãi.
Rủi ro cần tính trước
- Readiness báo sẵn sàng trước khi cấu hình, migration hoặc nhóm kết nối bắt buộc đã hoàn tất.
- Bộ cân bằng tải tiếp tục gửi lưu lượng trong một khoảng thời gian sau khi readiness đổi.
- Tự động mở rộng và cập nhật cuốn chiếu cùng lúc rút bớt quá nhiều năng lực.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Tỷ lệ thành công phía người dùng và P99 | Bản phát hành chỉ khỏe khi yêu cầu thật vẫn thành công trong mục tiêu độ trễ. |
| Số tiến trình đang khởi động, sẵn sàng và đang drain | Cho thấy rõ từng trạng thái vòng đời thay vì coi mọi tiến trình đang chạy là năng lực dùng được. |
| Số yêu cầu còn xử lý lúc tiến trình bị dừng | Mọi lần buộc dừng với giá trị lớn hơn 0 đều cho thấy thời gian drain chưa đủ. |
| Tốc độ tiêu hao ngân sách lỗi khi triển khai | Cho phép tự động tạm dừng hoặc quay lui trước khi lỗi lan ra toàn bộ hệ thống. |
Cách kiểm chứng
- Gửi yêu cầu thật liên tục trong suốt một rolling cập nhật, và kiểm tra rằng success rate, p99 cùng số connection reset đều nằm trong mục tiêu.
- Làm dịch vụ phụ thuộc khởi động chậm hơn thời gian warm-up thường lệ để chứng minh startup kiểm tra trạng thái ngăn được restart loop mà không nhận lưu lượng quá sớm.
- Dừng một tiến trình khi vẫn còn cả yêu cầu ngắn lẫn dài đang chạy, và xác nhận bộ cân bằng tải ngừng gán yêu cầu mới trước thời hạn.
- Gỡ một availability zone trong lúc đợt triển khai, và xác nhận disruption giới hạn vẫn giữ được minimum healthy năng lực xử lý.
- Tạo một tín hiệu phát hành xấu, rồi đo xem cơ chế tự động tạm dừng hoặc rollback có hoàn tất trong ngân sách lỗi hay không.
Đưa vào production từng bước
Đo thời gian khởi động, thời gian bộ cân bằng tải cập nhật và thời lượng của yêu cầu dài nhất trước khi đổi hành vi dừng tiến trình. Sau đó bật drain trên một nhóm nhỏ, kiểm tra các lần buộc dừng và chỉ tự động quay lui khi cảnh báo theo SLO đã đủ đáng tin.
Checklist trước khi vận hành
- Readiness kiểm tra quá nhiều thứ có thể dao động và loại nhầm cả tiến trình đang khỏe.
- Ngưỡng mở rộng phải tính cả thời gian warm-up.
- Hãy kiểm thử rolling cập nhật ở mức đồng thời sát thực tế trước khi lên production.
Điều cần nhớ
Triển khai không gián đoạn là quản lý trọn vòng đời lưu lượng: chuẩn bị, nhận việc, ngừng nhận việc mới, hoàn tất việc đang chạy rồi mới kết thúc tiến trình.