Khả năng triển khai độc lập là toàn bộ mục đích, nên mỗi service cần pipeline CI/CD riêng cộng với một chiến lược release rủi ro thấp — thường là canary hoặc blue-green — để ship an toàn nhiều lần mỗi ngày.
Mỗi service build, test, và triển khai theo nhịp riêng. Một thay đổi ở một service không bao giờ kích hoạt một đợt release toàn hệ thống.
commit ─▶ build ─▶ unit + contract test ─▶ image ─▶ deploy (một service)
| Chiến lược | Cách làm | Ưu | Nhược |
|---|---|---|---|
| Rolling | Thay thế instance dần dần | Đơn giản, mặc định | Lẫn version trong chốc lát |
| Blue-green | Hai môi trường, chuyển lưu lượng | Rollback tức thì | Hạ tầng gấp đôi |
| Canary | Gửi % nhỏ sang version mới | Giới hạn phạm vi ảnh hưởng | Cần metric tốt |
v1 ████████████████ 95% ← theo dõi tỷ lệ lỗi / độ trễ
v2 █ 5% ← thăng cấp nếu khỏe, rollback nếu không
└─ kiểm tra tự động trên SLO quyết định thăng cấp hay hủy
[ Blue v1 ] ◀─ đang chạy ──┐
[ Green v2 ] ◀─ nhàn rỗi ├─ lật router ─▶ Green chạy; Blue là rollback tức thì
Không có schema tương thích ngược, canary/blue-green sẽ vỡ vì hai version chạy đồng thời. Luôn thiết kế thay đổi sao cho tương thích xuyên các version.
Triển khai thường xuyên, rủi ro thấp là thứ làm cho microservices đáng với độ phức tạp của chúng — các đợt release chậm, rủi ro sẽ xóa sạch lợi ích về sự tự chủ.
Canary và blue-green giới hạn phạm vi ảnh hưởng của một lần deploy tồi và cho rollback gần như tức thì, biến việc triển khai từ một sự kiện đáng sợ thành một hoạt động thường nhật, tự động, hằng ngày.