Tối ưu CI/CD cho Hệ thống Microservices - Bài 1 - Từ Monolith lên Microservices: Pipeline CI/CD của bạn đã lỗi thời?

I. Đặt vấn đề: Cuộc khủng hoảng khi chuyển mình

Ở kiến trúc Monolith, vòng đời CI/CD rất đơn giản: Một Repository duy nhất -> Git Push -> Build 1 khối -> Run Test -> Deploy lên Server. Tuy nhiên, khi hệ thống "vỡ" ra thành 10, 20 hay thậm chí hàng trăm microservices, nếu bạn vẫn bê nguyên tư duy CI/CD của Monolith sang, hệ thống sẽ phải đối mặt với các "thảm họa":

• Hiệu ứng domino: Sửa một dòng code ở Service A (ví dụ: User Service) nhưng pipeline lại bắt build lại và deploy cả Service B, C, D không liên quan.

• Thời gian chờ đợi tồi tệ: Pipeline nghẽn hàng đợi (Queue) vì có quá nhiều người commit cùng lúc vào các service khác nhau, khiến việc build mất hàng chục phút.

• Ác mộng Rollback: Khi release một cụm services mới lên production và phát hiện lỗi, việc rollback trở lại version cũ trở nên lộn xộn vì không nắm rõ service nào đang ở version nào.

II. Bài toán đầu tiên: Chọn Mono-repo hay Poly-repo?

Trở ngại lớn nhất của CI/CD cho microservices nằm ở cách bạn quản lý mã nguồn. Mỗi phương pháp có một "nỗi đau" riêng và cách setup pipeline hoàn toàn khác nhau:

1. Poly-repo (Mỗi Service một Repository riêng biệt)

   • Ưu điểm: Tính độc lập cao tuyệt đối. CI/CD pipeline của service nào chạy riêng cho service đó. Dễ dàng phân quyền cho từng team.

   • Nỗi đau CI/CD: Bạn sẽ phải copy/paste file cấu hình CI/CD (như .gitlab-ci.yml hay bitbucket-pipelines.yml) cho hàng chục repo. Khi có thay đổi chuẩn CI/CD chung (ví dụ thêm bước scan bảo mật), bạn phải sửa thủ công ở hàng chục nơi.

2. Mono-repo (Tất cả Microservices nằm chung một Repository)

   • Ưu điểm: Dễ quản lý các thư viện dùng chung (Shared libraries), dễ refactor code xuyên suốt các services.

   • Nỗi đau CI/CD: Push code lên nhánh main và toàn bộ pipeline của 20 services cùng chạy một lúc.

   • Giải pháp tối ưu: Áp dụng Path-based Filtering (Chỉ trigger pipeline cho một thư mục service cụ thể nếu thư mục đó có file bị thay đổi trong commit).

III. Những "Nút thắt cổ chai" cần phá vỡ trong Microservices CI/CD

Để biết pipeline hiện tại của bạn đã lỗi thời hay chưa, hãy đối chiếu với 3 nút thắt sau:

1. Sự phụ thuộc lẫn nhau (Coupling Pipeline): Bạn có đang phải chờ Service A deploy xong mới dám deploy Service B vì database chung? Một hệ thống CI/CD chuẩn microservices phải cho phép các service deploy hoàn toàn độc lập mà không sợ sập hệ thống (Backward compatibility).

2. Thiếu cơ chế đánh dấu phiên bản tự động (Automated Versioning): Quản lý version bằng tay bằng cách sửa file package.json hay go.mod là tự sát. CI/CD hiện đại cần tự động đọc log commit, sinh ra Semantic Versioning (v1.0.1, v1.1.0) và tự động gắn tag cho Docker Image.

3. Tốn tài nguyên Build vô ích: Cứ mỗi lần push code là tải lại toàn bộ dependencies (node_modules, vendor) từ đầu.

IV. Tổng kết bài học

Pipeline CI/CD cho Microservices không đơn thuần là việc viết các lệnh build/deploy, mà là giải quyết bài toán: Tính độc lập, Tốc độ và Khả năng quản lý phiên bản. Ở bài học sau, chúng ta sẽ bắt tay vào giải quyết thực tiễn vấn đề đầu tiên: Chuẩn hóa Git Workflow để điều phối các nhánh tự động hóa cho hàng chục services.