Tôi hiện đang xây dựng một ứng dụng bằng cách sử dụng khung TrustedActors trên Azure ServiceFabric. Khi chúng tôi mở rộng quy mô, tôi đang xem xét triển khai xanh/xanh lục. Tôi có thể thấy cách làm điều này bằng cách sử dụng một hệ thống không quốc tịch. Có cách nào để làm điều này bằng cách sử dụng diễn viên statefull?Triển khai Xanh/Xanh với Azure ServiceFabric
Dịch vụ Vải là tất cả về nâng cấp, thay vì triển khai hoán đổi, như trao đổi VIP. Cả hai dịch vụ không trạng thái và trạng thái đều được nâng cấp theo cùng một cách, nhưng có một vài sắc thái bổ sung cho trạng thái mà tôi sẽ đề cập sau đó.
Bằng cách nâng cấp, tôi có nghĩa là nâng cấp ứng dụng được thực hiện tại chỗ, một miền nâng cấp tại một thời điểm, để không có thời gian chết và không chuyển đổi đột ngột. Việc nâng cấp cuộn trong Service Fabric có thể được thực hiện ở chế độ "được quản lý" an toàn nơi nền tảng sẽ thực hiện kiểm tra sức khỏe trước khi chuyển sang miền nâng cấp tiếp theo và sẽ tự động quay lại nếu kiểm tra tình trạng không thành công.
OK, tất cả đều nghe hay. Nhưng làm cách nào để bạn triển khai xanh/xanh khi nâng cấp luôn nâng cấp? Thay vì có hai "môi trường" có thể chứa hai ứng dụng đang chạy, Service Fabric có khái niệm về các kiểu ứng dụng được phiên bản mà từ đó các cá thể ứng dụng có thể được tạo ra. Dưới đây là ví dụ về cách hoạt động:
Giả sử tôi muốn tạo một ứng dụng có tên là Foo. Ứng dụng Foo của tôi được định nghĩa là một loại ứng dụng, gọi nó là FooType. Điều này tương tự như việc định nghĩa một lớp trong C#. Và giống như lớp trong C#, tôi có thể tạo các thể hiện kiểu của tôi. Mỗi cá thể có một tên duy nhất, tương tự như cách mỗi cá thể đối tượng của một lớp có một tên biến duy nhất. Nhưng không giống như các lớp trong C#, FooType của tôi có một số phiên bản. Sau đó, tôi có thể "đăng ký" các loại ứng dụng và phiên bản trong cluster của tôi:
FooType 1.0
Với điều đó đã đăng ký, tôi có thể tạo ra một thể hiện của ứng dụng:
"fabric:/FooApp" of FooType 1.0
Bây giờ, chúng ta hãy nói rằng tôi phát triển phiên bản 2.0 ứng dụng của tôi. Vì vậy, tôi đăng ký phiên bản 2.0 của FooType tôi trong cụm:
FooType 1.0
FooType 2.0
Bây giờ tôi đã cả hai phiên bản FooType đăng ký, và tôi vẫn còn có một thể hiện của 1.0 chạy:
"fabric:/FooApp" of FooType 1.0
Đây là nơi nó được vui vẻ . Tôi có thể làm một số điều thú vị:
Tôi có thể lấy "vải:/FooApp" - một phiên bản của FooType 1.0 - và nâng cấp nó lên FooType 2.0. Đây sẽ là bản nâng cấp của ứng dụng đang chạy.
Hoặc .. Tôi có thể để lại "vải:/FooApp" một mình, và tạo ra một mới thể hiện của ứng dụng phiên bản 2.0 của tôi:
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
Bây giờ tôi có hai ứng dụng, chạy side-by-side , trong cùng một cụm. Một là một thể hiện của 1.0 và một là phiên bản 2.0. Với một số cấu hình của các cổng và các điểm cuối ứng dụng, tôi có thể đảm bảo rằng người dùng vẫn đang đi tới cá thể 1.0 trong khi tôi thử nghiệm phiên bản 2.0.
Tuyệt vời, vì vậy tất cả các thử nghiệm của tôi đều vượt qua phiên bản 2.0, vì vậy bây giờ tôi có thể an toàn thực hiện 1.0 bản sao và nâng cấp lên 2.0 của FooType. Một lần nữa, đây là bản nâng cấp cuộn của cá thể đó (vải:/FooApp), nó không di chuyển người dùng sang cá thể mới (vải:/FooAppv2Test). Sau đó tôi sẽ đi và xóa vải:/FooAppv2Test vì đó chỉ là để thử nghiệm.
Một trong những lợi ích của màu xanh dương/xanh lục là có thể hoán đổi lại cho triển khai khác nếu triển khai mới không thành công. Vâng, bạn vẫn có cả 1.0 và 2.0 của FooType đã đăng ký. Vì vậy, nếu ứng dụng của bạn bắt đầu hoạt động sai sau khi nâng cấp từ 1.0 lên 2.0, bạn chỉ có thể "nâng cấp" nó trở lại 1.0! Trong thực tế, bạn có thể "nâng cấp" một cá thể ứng dụng giữa nhiều phiên bản khác nhau của kiểu ứng dụng của nó như bạn muốn! Và bạn không cần phải có phiên bản của tất cả các phiên bản ứng dụng đang chạy giống như trong môi trường hoán đổi, bạn chỉ có các phiên bản khác nhau được đăng ký và một phiên bản ứng dụng duy nhất có thể "nâng cấp" giữa các phiên bản.
Tôi đã đề cập đến sự cẩn trọng với các dịch vụ trạng thái. Điều quan trọng cần nhớ với các dịch vụ trạng thái là trạng thái ứng dụng - dữ liệu của người dùng - được chứa trong cá thể ứng dụng (fabric:/FooApp), để người dùng xem dữ liệu của họ, bạn cần giữ chúng trên cá thể đó. Đó là lý do tại sao chúng tôi thực hiện nâng cấp thay vì triển khai hoán đổi.
Đây chỉ là ý tưởng cơ bản. Có nhiều cách khác bạn có thể chơi xung quanh với các loại ứng dụng, phiên bản và trường hợp tùy thuộc vào mục tiêu của bạn và cách ứng dụng của bạn hoạt động, nhưng đó là thời gian khác.
Điều đó hữu ích, cảm ơn bạn Vaclav. Một trong những lợi ích, trong tâm trí của tôi, về triển khai kiểu xanh/xanh là tôi có thể thực hiện thông qua dịch vụ thứ hai để đảm bảo nó hoạt động trước khi tôi thực hiện toàn bộ trao đổi, thường bằng cách hướng nó qua bộ cân bằng tải. Có cách nào để thực hiện xác nhận tương tự trên SF không? – blackSphere
Đối với dịch vụ không trạng thái, chắc chắn, bạn có thể thiết lập việc này tạo một phiên bản v1.0 và v2.0, và thông qua một số định tuyến của riêng bạn, bạn có thể chuyển lưu lượng truy cập sang v2.0 trong khi tăng dần và mở rộng tỷ lệ v1.0 . Đối với các dịch vụ stateful thì nó phức tạp hơn một chút vì bản thân trạng thái nằm bên trong một cá thể ứng dụng, vì vậy nếu bạn gửi cho người dùng một cá thể mới của ứng dụng, dữ liệu của họ sẽ không có ở đó. Đây chỉ đơn giản là bản chất của những thứ nhà nước nói chung, và đó là lý do tại sao Service Fabric có các bản nâng cấp nâng cấp rất tiên tiến. –
Tôi cũng cho rằng việc nâng cấp lên máy bay có ý nghĩa "nhỏ gọn" vì toàn bộ ứng dụng của bạn không được nâng cấp cùng một lúc. Nó nâng cấp một lát tại một thời điểm, và nếu tại bất kỳ điểm nào kiểm tra sức khỏe không thành công (bạn có thể làm kiểm tra sức khỏe tùy chỉnh), nó sẽ quay trở lại. Vì vậy, bạn có thể nghĩ về nó như là một triển khai tự động thông qua, và chúng tôi yêu chúng tôi một số tự động hóa! –