kỳ phát hành nhanh hơn là một trong những lợi thế chính của kiến trúc microservice. Nhưng nếu không có quy trình CI / CD tốt, bạn sẽ không đạt được sự linh hoạt mà microservice hứa hẹn. Bài viết này mô tả các thách thức và đề xuất một số cách tiếp cận các vấn đề trên.

CI / CD là gì?

Khi chúng ta nói về CI / CD, chúng ta thực sự đang nói về một số quy trình liên quan: Tích hợp liên tục, deliver liên tục và deploy liên tục.

  • Tích hợp liên tục: Các thay đổi vể code thường được nhập vào nhánh chính. Quá trình build và tes tự động đảm bảo rằng code trong nhánh chính luôn được đảm bảo chất lượng.
  • Deliver liên tục: Bất kỳ thay đổi vể code nào vượt qua quy trình “Tích hợp liên tục” đều được tự động xuất bản sang môi trường sát với môi trường gần với môi trường prodcution nhất. Triển khai vào môi trường production có thể yêu cầu phê duyệt thủ công, nhưng hoàn toàn có thể tự động hoá đượ. Mục tiêu của quy trình này là code của bạn phải luôn sẵn sàng để triển khai vào môi trường production.
  • Deploy liên tục: Bất kỳ thay đổi vể code nào vượt qua hai bước trước đó sẽ được tự deploy vào môi trường production.

Dưới đây là một số mục tiêu của quy trình CI / CD mạnh mẽ cho kiến ​​trúc microservice:

  • Mỗi nhóm có thể xây dựng và triển khai các dịch vụ mà họ sở hữu độc lập mà không ảnh hưởng hoặc làm gián đoạn các nhóm khác.
  • Trước khi một phiên bản mới được triển khai vào môi trường production, nó sẽ được triển khai đến các môi trường dev / test / QA để xác thực. Chất lượng đánh giá được thi hành ở từng giai đoạn.
  • Phiên bản mới của các service có thể được triển khai song song với phiên bản trước.
  • Có đủ chính sách kiểm soát truy cập.
  • Đối với các công việc sử dụng container platform, bạn có thể tin tưởng vào các container image được triển khai vào môi trường production.

Tại sao CI / CD lại đóng vai trò quan trọng

Trong một ứng dụng nguyên khối truyền thống, có một chu trình duy nhất với đầu ra là ứng dụng thực thi. Tất cả các công việc phát triển đều là đầu vào của chu trình. Nếu tìm thấy lỗi ưu tiên cao, bản sửa lỗi phải được tích hợp, kiểm tra và xuất bản và có thể trì hoãn việc phát hành các tính năng mới. Bạn có thể giảm thiểu những vấn đề này bằng cách có các mô-đun được cung cấp đầy đủ và sử dụng các nhánh tính năng để giảm thiểu tác động của việc thay đổi code. Nhưng khi ứng dụng phát triển và trở nên phức tạp hơn và nhiều tính năng được thêm vào, quá trình phát hành cho một ứng dụng nguyên khối có xu hướng trở nên dễ bị phá vỡ.

Theo kiến trúc microservice, không bao giờ nên có một chuỗi các phát hành mà các đội phát triển phải xếp vào hang đợi. Nhóm xây dựng dịch vụ “A” có thể phát hành bản cập nhật bất cứ lúc nào mà không cần chờ đợi các thay đổi trong dịch vụ “B” được hợp nhất, thử nghiệm và triển khai.

cicd-monolith

Thách thức của kiến trúc Microservices và giải pháp

Thách thức – nhiều mô hình mã độc lập: Mỗi đội chịu trách nhiệm xây dựng dịch vụ và quy trình riêng của họ. Trong một số tổ chức, các nhóm có thể sử dụng kho lưu trữ mã riêng biệt. Các quy trình  riêng biệt có thể dẫn đến một tình huống trong đó kiến ​​thức về cách xây dựng hệ thống được trải đều giữa các nhóm và không ai trong tổ chức biết cách triển khai toàn bộ ứng dụng

Giải pháp: Có một quy trình thống nhất và tự động để xây dựng và triển khai các dịch vụ, để cách thức triển khai được phổ biến rõ ràng tới các nhóm khác nhau.

Thách thức – Nhiều ngôn ngữ và nền tảng lập trình khác nhau: Với việc mỗi nhóm sử dụng hỗn hợp công nghệ riêng của mình, có thể sẽ để khó tạo ra một quy trình phát triển duy nhất hoạt động trong toàn tổ chức. Quá trình phát triển phải đủ linh hoạt để mọi đội có thể điều chỉnh nó theo lựa chọn ngôn ngữ hoặc nền tảng của họ.

Giải pháp: Ứng dụng container platform cho quá trình xây dựng mỗi dịch vụ.

Thách thức – Tích hợp và kiểm thử: Với việc các nhóm phát hành bản cập nhật theo tốc độ của riêng họ, có thể sẽ khó khăn khi thiết kế thử nghiệm sản phẩm cuối cùng, đặc biệt là khi các dịch vụ có sự phụ thuộc lẫn nhau.

Giải pháp: Quá trình CI / CD của bạn càng tự động và đáng tin cậy thì càng cần phải có một cơ quan trung ương. Điều đó nói rằng, bạn có thể có các chính sách khác nhau để phát hành các bản cập nhật đối với các tính năng chính hay với các bản sửa lỗi nhỏ.

Thách thức – Cập nhật dịch vụ. Khi bạn cập nhật một dịch vụ lên phiên bản mới, nó không nên phá vỡ các dịch vụ khác phụ thuộc vào nó.

Giải pháp: Hãy triển khai phiên bản mới song song với phiên bản trước. Bằng cách đó, các dịch vụ sử dụng API trước đó có thể được cập nhật và kiểm tra API mới.