Tái xuất bản ứng dụng web ASP.NET Trong khi trang web đang hoạt động

Question

Tôi đang cố nắm bắt cách xử lý các bản cập nhật cho ứng dụng ASP.NET (2.0 hoặc cao hơn), trong khi có người dùng trên trang web.

Ví dụ: giả sử SO là dự án Ứng dụng web ASP.NET. Mã dự án biên dịch xuống thành duy nhất .DLL trong thư mục BIN. Bây giờ, có những người dùng liên tục trên SO, vì vậy điều gì sẽ xảy ra với hành động/phiên của người dùng nếu bạn sử dụng tính năng Visual Studio .NET "Publish" (hoặc chỉ tất cả mọi thứ bằng FTP) trong khi họ đang sử dụng trang web?

Tạo một trang web ASP.NET, thay vào đó, giảm bớt bất kỳ vấn đề nào có thể có hoặc không tồn tại với kịch bản trên? Tôi bắt đầu phát triển một trang web như một ứng dụng Web hướng người dùng và tôi muốn đảm bảo rằng sự thiếu kinh nghiệm của tôi với điều này sẽ không làm phiền những người dùng [tiềm năng] mà tôi [muốn] có 24/7.

EDIT: Rất tiếc, tôi phải đặt điều này trong ngữ cảnh chính xác hơn. Giả sử rằng trang web này đang được lưu trữ bởi dịch vụ lưu trữ web với phí hàng tháng. Tôi sẽ không tự quản lý máy chủ, chỉ những gì máy chủ lưu trữ web cho phép với tư cách là người dùng dịch vụ của họ.

Answer 1

Thay đổi sang mô hình trang web asp.net sẽ không có bất kỳ ảnh hưởng nào, vì quá trình tái chế cũng sẽ xảy ra, một số thay đổi kích hoạt nó chắc chắn: web.config, global.asax, app_code.

Sau khi tái chế, người dùng sẽ vẫn được đăng nhập vì asp.net sẽ chỉ xác thực cú pháp. Đó là cho bạn sử dụng một phím máy cố định, nếu không nó sẽ thay đổi trên mỗi tái chế. Đây là một cái gì đó bạn muốn làm anyway như các công cụ khác có thể phá vỡ nếu thay đổi quan trọng trên các yêu cầu tức là xác nhận ViewState, tài nguyên nhúng (giải mã url không thành công).

Nếu bạn có thể đặt phiên quá trình, như trong máy chủ sql, bạn sẽ tránh mất phiên. Nếu bạn không thể, mã của bạn sẽ phải xem xét điều đó. Có rất nhiều kịch bản mà bạn có thể tránh sử dụng phiên, và những người khác là bạn có thể quấn nó và lấy lại thông tin nếu phiên được làm sạch. Điều này sẽ để lại cho bạn một số trường hợp cụ thể mà bạn biết có thể gây rắc rối cho người dùng, vì vậy đối với những người bạn thực hiện một số đề xuất mà người khác đã thực hiện.

Answer 2

Một giải pháp có thể là triển khai ứng dụng của bạn vào môi trường cân bằng tải (trang trại).
Khi triển khai phiên bản mới, bạn sẽ sử dụng trình cân bằng tải để chuyển hướng các yêu cầu đến máy chủ mà bạn không triển khai.

Answer 3

Tôi không chắc chắn cách SO xử lý nó .. Nhưng chúng tôi thường đặt một trang giữ. Vì vậy, những gì bao giờ người dùng đã làm (thêm câu hỏi hoặc trả lời câu hỏi) không được cập nhật. Ngay sau khi anh ta cập nhật một cái gì đó anh ta sẽ thấy một trang đang nắm giữ yêu cầu anh ta thử sau một thời gian.

Và nếu tôi là người dùng, tôi thường nhấn nút quay lại để đảm bảo những gì tôi đã nhập được lưu trong lịch sử trình duyệt để tôi có thể đăng sau.

Một số trang sử dụng sử dụng trong môi trường nhóm nên tôi có một máy chủ ngoại tuyến và thông báo cho cân bằng tải mà cô ấy sẽ không có sẵn và khi tôi đảm bảo rằng phiên bản mới đang hoạt động tốt. điều tương tự cho máy chủ tiếp theo.

Chúng tôi có tùy chọn nào khác không?

Answer 4

App_offline.htm là giải pháp tuyệt vời cho điều này tôi nghĩ.

trong SO, chúng tôi thấy trang ứng dụng hiện không khả dụng khi triển khai bắt đầu.

Answer 5

Tôi tạo hai trang Web trong IIS. Một là trang Web sản xuất và trang còn lại là một trang Web tĩnh với HttpHandler gửi tất cả các yêu cầu đến một trang tĩnh "Chúng tôi đang cập nhật" được cung cấp với Dịch vụ HTTP 503 không khả dụng. Thông thường, trang Web cập nhật bị tắt. Khi đó là thời gian để cập nhật, chúng ta sẽ ngừng trang Web sản xuất, bắt đầu trang Web cập nhật, và bây giờ chúng ta có thể tạo trang web sản xuất tất cả những gì chúng ta muốn mà không lo lắng về các DLL bị khóa hoặc các quy trình công việc cần được kéo xuống.

tôi bắt đầu làm điều này vì

• app_offline.htm thực sự không làm việc tốt trong Web Gardens, mà chúng tôi sử dụng.
• App_Offline.htm phục vụ trang của nó là 404, điều này rất tệ nếu bạn ngừng hoạt động trong một khoảng thời gian có ý nghĩa.
• Chúng tôi có thể bắt đầu trang Web sản xuất được nâng cấp với cài đặt sửa đổi (chỉ nghe trên máy chủ cục bộ), nơi chúng tôi có thể thực hiện việc xác nhận/xác minh vào phút chót rằng mọi thứ đang hoạt động trước khi chúng tôi lật công tắc, tắt trang web cập nhật và -cho phép trang web sản xuất.

Những điều này không giải quyết bao gồm

• Bất kỳ bảo trì đòi hỏi phải khởi động lại máy chủ - bạn vẫn có thời gian chết nơi không có trang được phục vụ.
• Bất kỳ bảo trì nào đã làm việc với thời gian chạy .NET, như nâng cấp lên gói dịch vụ mới nhất.

cách tiếp cận khác tôi đã nhìn thấy bao gồm

• Có hai máy chủ. Gửi tất cả các yêu cầu cân bằng tải tới một máy chủ, nâng cấp một yêu cầu khác; sau đó rửa sạch và lặp lại. Hầu hết chúng ta không có sự sang trọng này.
• Tạo nhiều thư mục bin, như bin-1.0.0.0 và bin-1.1.0.0 và thông báo cho ASP.NET thư mục bin nào sẽ sử dụng trong tệp web.config. (Một lợi thế của việc này là hoàn nguyên về một tệp nhị phân trước đó chỉ là chỉnh sửa tệp cấu hình. Một bất lợi là khó khôi phục các tài nguyên không kết thúc trong tệp nhị phân của bạn, chẳng hạn như mẫu và hình ảnh.) hãy nhớ làm thế nào điều này thực sự làm việc - Tôi nghĩ rằng các ứng dụng đã làm một số tải lắp ráp muộn trong Global.asax của nó dựa trên phần web.config riêng của mình (kể từ khi bạn chạm vào web.config, ứng dụng đã khởi động lại, vì vậy nó đã được okay).

Nếu bạn tìm thấy cách tốt hơn, hãy cho tôi biết!

Answer 6

Nó không phải là một giải pháp kỹ thuật, nhưng thiết lập một cửa sổ bảo trì theo lịch trình. Bạn có thể thông báo trước cho cảnh báo cơ sở người dùng của bạn rằng có khả năng ứng dụng sẽ không có sẵn trong khung thời gian đó.