Login

Chiến lược triển khai: rolling, blue-green và canary khác nhau thế nào?

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Phát hành phiên bản mới mà làm sập trang web giữa giờ cao điểm là cơn ác mộng. Các chiến lược triển khai sinh ra để giảm rủi ro đó: cập nhật mà người dùng không hay biết, và có đường lui nhanh khi gặp lỗi. Ba cách phổ biến nhất là rolling, blue-green và canary.

Triển khai thẳng: đơn giản nhưng rủi ro

Cách cơ bản nhất là dừng bản cũ, chép bản mới, khởi động lại. Dễ làm, nhưng có thời gian ngừng dịch vụ (downtime) và nếu bản mới lỗi thì phải làm lại từ đầu. Với trang web nhỏ ít người dùng thì chấp nhận được, còn hệ thống nghiêm túc thường cần cách tốt hơn.

Rolling update: thay dần từng phần

Giả sử bạn chạy bốn bản sao của ứng dụng. Rolling update thay lần lượt từng bản cũ bằng bản mới: tắt một, bật một bản mới, chờ khỏe, rồi sang bản tiếp theo.

  • Ưu điểm: không cần thêm tài nguyên đáng kể, không downtime nếu còn bản đang chạy.
  • Nhược điểm: trong lúc cập nhật, phiên bản cũ và mới chạy song song, nên cần tương thích ngược (đặc biệt với cơ sở dữ liệu và API). Quay lui cũng chậm hơn.

Blue-green: hai môi trường song song

Bạn duy trì hai môi trường giống hệt nhau. Giả sử xanh dương (blue) đang phục vụ người dùng. Bạn triển khai bản mới vào môi trường xanh lá (green), kiểm tra kỹ, rồi chuyển lưu lượng từ blue sang green trong một thao tác, ví dụ đổi cấu hình cân bằng tải.

  • Ưu điểm: chuyển đổi gần như tức thì, rollback chỉ là chuyển ngược lại, có thể kiểm thử bản mới trong điều kiện thật trước khi mở cho người dùng.
  • Nhược điểm: tốn gấp đôi tài nguyên trong lúc chuyển, và phải xử lý khéo thay đổi cơ sở dữ liệu vì cả hai môi trường thường dùng chung dữ liệu.

Canary: thử với một nhóm nhỏ trước

Tên gọi lấy từ hình ảnh chim hoàng yến trong hầm mỏ. Bạn cho bản mới nhận một phần nhỏ lưu lượng, rồi theo dõi lỗi và độ trễ. Nếu ổn thì tăng dần tỉ lệ; nếu có vấn đề thì rút lại, và chỉ một số ít người dùng bị ảnh hưởng.

  • Ưu điểm: giới hạn thiệt hại, phát hiện lỗi bằng dữ liệu thực tế.
  • Nhược điểm: cần hệ thống giám sát tốt và khả năng chia lưu lượng chính xác, nên phức tạp hơn để thiết lập.

So sánh nhanh

Tiêu chíRollingBlue-greenCanary
Tài nguyên thêmÍtNhiềuÍt đến vừa
Tốc độ rollbackTrung bìnhRất nhanhNhanh
Mức rủi roTrung bìnhThấpThấp nhất
Độ phức tạpThấpVừaCao

Không quên cơ sở dữ liệu

Dù chọn chiến lược nào, thay đổi cấu trúc dữ liệu là chỗ dễ sai nhất. Nguyên tắc an toàn là chia thành nhiều bước tương thích ngược: thêm cột mới trước, cho code mới ghi và đọc cả hai, rồi mới xóa cột cũ ở lần phát hành sau. Đừng đổi tên hoặc xóa cột trong cùng lần với code mới.

Feature flag: một công cụ bổ trợ

Feature flag (cờ tính năng) cho phép đưa code lên production nhưng chưa bật tính năng. Bạn bật dần cho nhóm người dùng nhất định rồi tắt ngay nếu có vấn đề mà không cần triển khai lại. Nó tách việc 'triển khai code' khỏi việc 'phát hành tính năng'.

Chọn cách nào?

  1. Đội nhỏ, hệ thống đơn giản: bắt đầu với rolling update.
  2. Cần rollback tức thì và có ngân sách tài nguyên: blue-green.
  3. Lượng người dùng lớn, có giám sát tốt: canary.

Kết luận

Không có cách tốt nhất tuyệt đối, chỉ có cách phù hợp với quy mô và khả năng vận hành của bạn. Dù chọn gì, hãy luôn chuẩn bị đường lui và theo dõi hệ thống sau mỗi lần phát hành.

Nếu bạn muốn thực hành các kiểu triển khai này trên dự án mẫu, hãy tham khảo thêm tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment