Nói một cách ngắn gọn, ý tưởng đằng sau các bản phát hành canary là chỉ cung cấp phiên bản phần mềm mới cho một bộ phận người dùng, phân tích kết quả và quyết định xem có nên tiếp tục hay không. Nếu kết quả không phù hợp với mong đợi, hãy quay lại; nếu đúng như vậy, hãy tăng số lượng người dùng tiếp xúc cho đến khi tất cả người dùng được hưởng lợi từ phiên bản mới.  Trong bài đăng này, tôi muốn trình bày chi tiết phần giới thiệu này một cách ngắn gọn, giải thích các cách khác nhau để xác định phân số và chỉ ra cách thực thi nó với  Apache APISIX.  Giới thiệu về phiên bản canary  Thuật ngữ "chim hoàng yến" bắt nguồn từ ngành khai thác than. Khi khai thác, việc thải ra khí độc không phải là hiếm: Trong một không gian kín nhỏ, điều đó có thể dẫn đến cái chết nhanh chóng. Tệ hơn nữa, khí gas có thể không có mùi nên thợ mỏ sẽ hít phải khí này cho đến khi quá muộn mới rời đi. Carbon monoxide khá phổ biến trong các mỏ than và không thể phát hiện được bằng giác quan của con người.  Vì lý do này, những người thợ mỏ đã mang theo chim hoàng yến xuống lòng đất. Nếu con chim hoàng yến đột nhiên chết, rất có thể túi khí đó đã bị thủng và đã đến lúc phải rời khỏi nơi này.  Nhiều năm trước, chúng tôi đã áp dụng phương pháp này để phát hành phiên bản phần mềm mới. Sự tương tự diễn ra như sau: thợ mỏ là nhóm Ops triển khai phiên bản, canary bao gồm tất cả các công cụ để đo lường tác động của việc phát hành và gas là một lỗi (nghiêm trọng).  Phần quan trọng nhất là   của bản phát hành, bao gồm tỷ lệ lỗi, mã trạng thái HTTP, v.v. và so sánh chúng với phiên bản trước. Nó nằm ngoài phạm vi của bài đăng này, nhưng một lần nữa, điều quan trọng là nếu bạn muốn hưởng lợi từ các bản phát hành canary. Phần quan trọng thứ hai là khả năng khôi phục nhanh nếu phiên bản mới có lỗi. bạn cần đo lường tác động  Bản phát hành Canary so với cờ tính năng  Lưu ý rằng các bản phát hành canary không phải là cách duy nhất để quản lý rủi ro khi phát hành mã mới. Ví dụ: cờ tính năng là một cách phổ biến khác:  Phương pháp canary cung cấp bộ tính năng hoàn chỉnh trong phiên bản thành phần mới  Cờ tính năng cũng triển khai thành phần, nhưng các tham số cấu hình chuyên dụng cho phép kích hoạt và hủy kích hoạt từng tính năng riêng lẻ  Cờ tính năng thể hiện một cách tiếp cận linh hoạt hơn (theo đúng nghĩa của từ này) đối với việc khôi phục. Nếu một trong số 10 tính năng bị lỗi, bạn không cần hủy triển khai phiên bản mới; bạn chỉ tắt tính năng lỗi. Tuy nhiên, siêu năng lực này phải trả giá bằng sự phức tạp của cơ sở mã bổ sung, bất kể bạn dựa vào sản phẩm của bên thứ ba hay tự mình triển khai nó.  Mặt khác, canary yêu cầu một quy trình triển khai hoàn thiện để có thể triển khai và hủy triển khai theo ý muốn.  Các phương pháp tiếp cận việc phát hành chim hoàng yến  Ý tưởng đằng sau các bản phát hành canary là chỉ cho phép một phần nhỏ người dùng truy cập phiên bản mới. Hầu hết các định nghĩa canary chỉ định nghĩa "phân số" là phần trăm người dùng. Tuy nhiên, còn nhiều điều hơn thế nữa.  Bước đầu tiên có thể là chỉ cho phép người dùng đã được hiệu đính kiểm tra xem quá trình triển khai trong môi trường sản xuất có hoạt động như mong đợi hay không. Trong trường hợp này, bạn chỉ có thể chuyển tiếp một nhóm người dùng nội bộ cụ thể,   : người thử nghiệm, sang phiên bản mới. Nếu bạn biết trước những người đó và hệ thống xác thực người dùng, bạn có thể định cấu hình nó theo danh tính; nếu không, bạn cần dự phòng theo một số cách chung,   : tiêu đề HTTP -   . ví dụ ví dụ X-Canary: Let-Me-Go-To-v2  Hãy nhớ rằng chúng ta phải theo dõi hệ thống cũ và mới để xem xét những khác biệt. Nếu không có gì hiển thị thì đây là thời điểm tuyệt vời để tăng lượng người dùng được chuyển tiếp sang phiên bản mới. Tôi cho rằng bạn ăn thức ăn cho chó của chính mình,   ; các thành viên trong nhóm sử dụng phần mềm họ đang phát triển. Ví dụ: nếu bạn không có trang web thương mại điện tử dành cho ô tô sang trọng, bạn có thể bỏ qua phần này. tức là  Để tăng tỷ lệ người dùng đồng thời hạn chế rủi ro, giờ đây chúng tôi có thể cung cấp bừa bãi phiên bản mới cho người dùng nội bộ. Chúng ta có thể cấu hình hệ thống chuyển tiếp sang phiên bản mới dựa trên IP máy khách để thực hiện việc này. Vào thời điểm mọi người đang làm việc tại chỗ, điều đó thật dễ dàng vì IP của họ nằm trong một phạm vi cụ thể. Điều khiển từ xa không thay đổi nhiều vì người dùng có thể truy cập mạng của công ty thông qua VPN.  Một lần nữa, hãy theo dõi và so sánh vào thời điểm này.  Toàn bộ chín thước  Tại thời điểm này, mọi thứ sẽ hoạt động như mong đợi đối với người dùng nội bộ, một số hoặc tất cả. Nhưng cũng như không có kế hoạch nào có thể tồn tại khi tiếp xúc với kẻ thù, không có cách sử dụng nào có thể bắt chước toàn bộ sự đa dạng của khối lượng công việc sản xuất. Nói tóm lại, chúng tôi cần cho phép người dùng thường xuyên truy cập phiên bản mới, nhưng theo cách có kiểm soát, giống như cách chúng tôi tăng dần số lượng người dùng cho đến nay: bắt đầu với một phần nhỏ, theo dõi nó và nếu mọi thứ đều ổn, hãy tăng phần đó lên .  Đây là cách thực hiện với Apache APISIX. Apache APISIX cung cấp kiến trúc dựa trên plugin và cung cấp plugin đáp ứng nhu cầu của chúng tôi, cụ thể là plugin   . traffic-split  Plugin   có thể được sử dụng để tự động điều hướng các phần lưu lượng truy cập đến các dịch vụ Thượng nguồn khác nhau. traffic-split  Điều này được thực hiện bằng cách định cấu hình   , là các quy tắc tùy chỉnh để phân chia lưu lượng truy cập và   là một tập hợp các Luồng lên để hướng lưu lượng truy cập đến. match weighted_upstreams  --  phân chia lưu lượng truy cập  Hãy bắt đầu với một số nội dung ngược dòng cơ bản, một nội dung cho mỗi phiên bản:   upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1  Chúng tôi có thể sử dụng plugin   để chuyển tiếp phần lớn lưu lượng truy cập sang v1 và một phần tới v2: traffic-split   routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3  Xác định lộ trình tổng hợp  Định cấu hình cách phân chia lưu lượng; đây, tạ  Chuyển tiếp 99% lưu lượng truy cập sang v1 và 1% tới v1. Lưu ý rằng các trọng số có liên quan với nhau. Để đạt được 50/50, bạn có thể đặt trọng số 1 và 1, 3 và 3, 50 và 50, v.v.  Một lần nữa, chúng tôi giám sát mọi thứ và đảm bảo kết quả như mong đợi. Sau đó, chúng ta có thể tăng tỷ lệ lưu lượng được chuyển tiếp đến v2,   : ví dụ   routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1  Tăng lưu lượng truy cập lên v2 lên 5%  Lưu ý rằng Apache APISIX tải lại các thay đổi đối với tệp ở trên mỗi giây. Do đó, bạn phân chia lưu lượng truy cập theo thời gian gần như thực. Ngoài ra, bạn có thể sử dụng API quản trị để đạt được điều tương tự.  Nhiều bản phát hành được kiểm soát hơn  Ở phần trên, tôi đã chuyển từ người dùng nội bộ sang một bộ phận người dùng bên ngoài. Có lẽ việc phát hành cho mọi người dùng nội bộ là một rủi ro quá lớn trong tổ chức của bạn và bạn thậm chí còn cần kiểm soát nhiều hơn. Lưu ý rằng bạn có thể định cấu hình thêm plugin   trong trường hợp này. traffic-split   routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95  Chỉ phân chia lưu lượng truy cập nếu tiêu đề HTTP   có giá trị được định cấu hình. X-Canary  Lệnh sau luôn chuyển tiếp tới v1:   curl http://localhost:9080  Lệnh sau cũng luôn chuyển tiếp tới v1:   curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080  Lệnh sau chia lưu lượng truy cập theo trọng số được định cấu hình,   là 95/5: tức   curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080  Phần kết luận  Bài đăng này giải thích các bản phát hành canary và cách bạn có thể định cấu hình một bản phát hành thông qua Apache APISIX. Bạn có thể bắt đầu với một số tuyến đường với mức độ ưu tiên khác nhau và chuyển sang plugin   . Cái sau thậm chí có thể được cấu hình thêm để cho phép các trường hợp sử dụng phức tạp hơn. traffic-split  Mã nguồn hoàn chỉnh cho bài đăng này có thể được tìm thấy trên   . GitHub   Để đi xa hơn:   Triển khai giải pháp phát hành canary dựa trên Apache APISIX   Bản phát hành Canary trong Kubernetes với Apache APISIX Ingress   Phát hành Canary mượt mà bằng cách sử dụng Bộ điều khiển xâm nhập APISIX với Trình gắn cờ  Được xuất bản lần đầu tại   vào ngày 3 tháng 12 năm 2023 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Triển khai các bản phát hành Canary với Apache APISIX

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

581 Stories To Learn About Non Fiction

147 Stories To Learn About Reading Books Online

178 Stories To Learn About Essay

309 Stories To Learn About Smart Contracts

581 Stories To Learn About Non Fiction

147 Stories To Learn About Reading Books Online

178 Stories To Learn About Essay

309 Stories To Learn About Smart Contracts

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps