Xin chào, Habr! Tôi trình bày cho bạn chú ý bản dịch của tác giả bài viết .
Vào thời điểm thế giới CNTT đang dần hướng tới các dịch vụ và công cụ microservice như Kubernetes, chỉ có một vấn đề đang ngày càng trở nên đáng chú ý. Vấn đề này - phiên bản microservice. Tuy nhiên, cộng đồng CNTT vẫn tin rằng tình hình hiện tại tốt hơn nhiều so với hiện tại. thế hệ công nghệ trước đó. Tuy nhiên, việc tạo phiên bản cho microservice là một vấn đề rất phức tạp. Một bằng chứng về điều này có thể là những bài viết như .
Nếu bạn vẫn không hiểu vấn đề khi đọc văn bản này, hãy để tôi giải thích. Giả sử sản phẩm của bạn bao gồm 10 microservice. Bây giờ, giả sử rằng có 1 phiên bản mới được phát hành cho mỗi vi dịch vụ này. Chỉ có 1 phiên bản - tôi hy vọng tất cả chúng ta có thể đồng ý rằng đây là một sự thật rất tầm thường và không đáng kể. Tuy nhiên, bây giờ chúng ta hãy nhìn lại sản phẩm của chúng tôi. Chỉ với một phiên bản mới của mỗi thành phần, giờ đây chúng tôi có 2^10 - hoặc 1024 hoán vị về cách tạo ra sản phẩm của chúng tôi.
Nếu vẫn còn có sự hiểu lầm, hãy để tôi chia nhỏ phép toán. Vậy là chúng ta có 10 vi dịch vụ, mỗi vi dịch vụ nhận được một bản cập nhật. Nghĩa là, chúng tôi nhận được 2 phiên bản khả dụng cho mỗi microservice (cũ hoặc mới). Bây giờ, đối với mỗi thành phần của sản phẩm, chúng ta có thể sử dụng một trong hai phiên bản này. Về mặt toán học, nó giống như khi chúng ta có số nhị phân gồm 10 chữ số. Ví dụ: giả sử rằng 1 là phiên bản mới và 0 là phiên bản cũ - khi đó một hoán vị có thể có có thể được biểu thị là 1001000000 - trong đó các thành phần thứ 1 và thứ 4 được cập nhật, còn tất cả các thành phần khác thì không. Từ toán học, chúng ta biết rằng số nhị phân 10 chữ số có thể có 2^10 hoặc 1024 giá trị. Tức là chúng ta đã xác nhận được quy mô của con số mà chúng ta đang giải quyết.
Hãy tiếp tục lý luận sâu hơn - điều gì sẽ xảy ra nếu chúng ta có 100 microservice và mỗi microservice có 10 phiên bản có thể có? Toàn bộ tình huống trở nên khá khó chịu - hiện tại chúng ta có 10^100 hoán vị - một con số khổng lồ. Tuy nhiên, tôi thích gắn nhãn tình huống này theo cách này hơn, bởi vì giờ đây chúng ta không còn trốn đằng sau những từ như “kubernetes” nữa mà thay vào đó là đối mặt với vấn đề như hiện tại.
Tại sao tôi lại bị cuốn hút bởi vấn đề này? Một phần vì trước đây đã từng làm việc trong thế giới NLP và AI nên chúng tôi đã thảo luận rất nhiều về vấn đề bùng nổ tổ hợp khoảng 5-6 năm trước. Chỉ thay vì các phiên bản, chúng tôi có các từ riêng lẻ và thay vì các sản phẩm, chúng tôi có các câu và đoạn văn. Và mặc dù các vấn đề của NLP và AI phần lớn vẫn chưa được giải quyết, nhưng phải thừa nhận rằng đã đạt được những tiến bộ đáng kể trong vài năm qua. (theo ý kiến của tôi, có thể đạt được tiến bộоSẽ tốt hơn nếu mọi người trong ngành ít chú ý hơn đến học máy và nhiều hơn một chút đến các kỹ thuật khác - nhưng điều này đã lạc đề rồi).
Hãy quay trở lại thế giới của DevOps và microservice. Chúng tôi đang phải đối mặt với một vấn đề lớn, giả dạng một con voi ở Kunstkamera - bởi vì điều tôi thường nghe là “chỉ cần lấy kubernetes và helm, rồi mọi thứ sẽ ổn thôi!” Nhưng không, mọi chuyện sẽ không ổn nếu cứ để nguyên như vậy. Hơn nữa, một giải pháp phân tích cho vấn đề này dường như không được chấp nhận do tính phức tạp của nó. Giống như trong NLP, trước tiên chúng ta nên tiếp cận vấn đề này bằng cách thu hẹp phạm vi tìm kiếm — trong trường hợp này là bằng cách loại bỏ các hoán vị lỗi thời.
Một trong những điều có thể hữu ích là điều tôi đã viết năm ngoái . Điều quan trọng cần lưu ý là quy trình CI/CD được thiết kế tốt sẽ giúp ích rất nhiều trong việc giảm thiểu các biến thể. Tuy nhiên, tình trạng hiện tại của CI/CD là không đủ tốt để giải quyết vấn đề hoán vị nếu không có các công cụ bổ sung cho các thành phần kế toán và theo dõi.
Những gì chúng tôi cần là một hệ thống thử nghiệm ở giai đoạn tích hợp, nơi chúng tôi có thể xác định yếu tố rủi ro cho từng thành phần, đồng thời có quy trình tự động để cập nhật các thành phần khác nhau và thử nghiệm mà không cần sự can thiệp của người vận hành - để xem cái gì hoạt động và cái gì không.
Một hệ thống thí nghiệm như vậy có thể trông như thế này:
- Các nhà phát triển viết bài kiểm tra (đây là giai đoạn quan trọng - vì nếu không thì chúng tôi không có tiêu chí đánh giá - nó giống như việc dán nhãn dữ liệu trong machine learning).
- Mỗi thành phần (dự án) nhận được hệ thống CI riêng - quy trình này hiện đã được phát triển tốt và vấn đề tạo hệ thống CI cho một thành phần duy nhất đã được giải quyết phần lớn
- “Hệ thống tích hợp thông minh” thu thập kết quả của các hệ thống CI khác nhau và tập hợp các dự án thành phần thành sản phẩm cuối cùng, chạy thử nghiệm và cuối cùng tính toán đường đi ngắn nhất để đạt được chức năng sản phẩm mong muốn dựa trên các thành phần hiện có và các yếu tố rủi ro. Nếu không thể cập nhật, hệ thống này sẽ thông báo cho nhà phát triển về các thành phần hiện có và thành phần nào gây ra lỗi. Một lần nữa, hệ thống kiểm tra ở đây có tầm quan trọng đặc biệt - vì hệ thống tích hợp sử dụng các bài kiểm tra làm tiêu chí đánh giá.
- Hệ thống CD, sau đó nhận dữ liệu từ Hệ thống tích hợp thông minh và thực hiện cập nhật trực tiếp. Giai đoạn này kết thúc chu kỳ.
Tóm lại, đối với tôi, một trong những vấn đề lớn nhất hiện nay là thiếu “Hệ thống tích hợp thông minh” có thể liên kết các thành phần khác nhau thành một sản phẩm và do đó cho phép bạn theo dõi cách tổng thể sản phẩm được kết hợp với nhau. Tôi sẽ quan tâm đến suy nghĩ của cộng đồng về vấn đề này (spoiler - Tôi hiện đang làm việc trên một dự án , có thể trở thành một hệ thống tích hợp thông minh như vậy).
Một điều cuối cùng tôi muốn đề cập là, đối với tôi, một tảng đá nguyên khối không được chấp nhận đối với bất kỳ dự án nào dù có quy mô trung bình. Đối với tôi, những nỗ lực tăng tốc thời gian thực hiện và chất lượng phát triển bằng cách quay trở lại nguyên khối gây ra sự hoài nghi lớn. Đầu tiên, một khối nguyên khối có một vấn đề tương tự trong việc quản lý các thành phần - tuy nhiên, trong số các thư viện khác nhau mà nó bao gồm, tất cả điều này không quá đáng chú ý và thể hiện chủ yếu qua thời gian mà các nhà phát triển dành ra. Hậu quả của vấn đề nguyên khối là hầu như không thể thực hiện các thay đổi đối với mã - và tốc độ phát triển cực kỳ chậm.
Microservice cải thiện tình hình, nhưng sau đó kiến trúc microservice phải đối mặt với vấn đề bùng nổ tổ hợp ở giai đoạn tích hợp. Đúng, nhìn chung, chúng ta đã chuyển cùng một vấn đề từ giai đoạn phát triển sang giai đoạn hội nhập. Tuy nhiên, theo tôi, cách tiếp cận microservices vẫn dẫn đến kết quả tốt hơn và các nhóm đạt được kết quả nhanh hơn (có thể chủ yếu là do việc giảm quy mô của đơn vị phát triển - hoặc kích thước lô). Tuy nhiên, việc chuyển từ nguyên khối sang microservice vẫn chưa cải thiện đủ quy trình - sự bùng nổ tổ hợp của các phiên bản microservice là một vấn đề lớn và chúng ta có rất nhiều tiềm năng để cải thiện tình hình khi giải quyết nó.
Nguồn: www.habr.com