Tại sao nên sử dụng IIS hoặc apache tomcat thay vì tự lưu trữ?

Tôi là một nhà phát triển .NET. Tôi thấy khung MVC MVC bây giờ bắt đầu cung cấp tính năng tự lưu trữ. Nó có rất nhiều ý nghĩa (với tôi). Một ứng dụng tự lưu trữ cảm thấy đầy đủ mà không phụ thuộc bên ngoài.

Câu hỏi tôi có trong đầu bây giờ là tại sao mọi người KHÔNG muốn tự lưu trữ? Ý tôi là, có bất kỳ lợi thế nào mà IIS sẽ mang lại cho tôi so với việc tự lưu trữ không. Tôi chắc chắn có một số lợi thế bởi vì nếu không, Microsoft sẽ không bận tâm đến việc tạo tích hợp IIS với lõi asp.net.

Tôi không muốn câu hỏi của mình cụ thể với .NET. Vì vậy, tôi sẽ đi với - tại sao đi với lý do tại sao sử dụng IIS hoặc apache tomcat thay vì tự lưu trữ?

— fazlani song phương
nguồn

Ở cấp độ cao, các máy chủ web lớn đi kèm với rất nhiều chức năng bạn cần để xây dựng lại hoàn toàn, mà bạn có thể định cấu hình hoặc đơn giản là bỏ qua , nếu bạn "tự lưu trữ". Những điều đơn giản, như phục vụ các tệp tĩnh, cấu hình Expiresvà ETagcác tiêu đề. Và sau đó, những điều phức tạp hơn, như phân tách lưu lượng bằng cách host, giữ các ứng dụng cách xa bộ nhớ của nhau, SSL và quản lý hàng ngàn yêu cầu đồng thời ...

— svidgen

Bạn chỉ có thể viết dịch vụ HTTP của riêng bạn bằng cách sử dụng ổ cắm C ++.

— Matthew Whited

dotnetfunda.com/interviews/exinating/show/755/ từ

— Matthew Whited

Nhiều ứng dụng .net tự gọi mình là "tự lưu trữ" trong khi chúng vẫn sử dụng http.sys, IMO khá sai lệch.

— CodeInChaos

Theo quan điểm của tôi, đó chỉ là hậu quả lịch sử của sự phát triển của các trường hợp sử dụng cho ngăn xếp dịch vụ và giao thức TCP / HTTP. Ví dụ, trong trường hợp HTTP, trình nền hoặc dịch vụ đã từng ngồi trên hệ điều hành như một loại trung tâm trung tâm của bất kỳ nội dung web nào, mà các ứng dụng cục bộ hoặc từ xa khác sẽ ủy thác việc tiêu thụ hoặc cung cấp siêu văn bản / hypermedia Nội dung.

— YSharp

IIS cung cấp một số khả năng phổ biến không có sẵn theo mặc định trong các dịch vụ web tự lưu trữ. Người giám sát: nó theo dõi sức khỏe của ứng dụng web và sẽ giết / hồi sinh ứng dụng nếu ứng dụng bắt đầu trông không lành mạnh (sử dụng quá nhiều bộ nhớ, CPU, v.v. - có thể định cấu hình). Các giới hạn tài nguyên như sử dụng CPU, giới hạn kết nối, v.v. Chạy như một người dùng nhất định để bảo mật đặc quyền tối thiểu. Quản lý chứng chỉ / SSL. Lưu trữ / quản lý nhiều ứng dụng thông qua một cổng / giao diện. Đảo ngược proxy để ứng dụng giao diện điều khiển. Nhiều thứ khác tôi không đề cập đến như đăng nhập yêu cầu.

Tôi không quen thuộc với Tomcat, nhưng tôi cho rằng đó là câu chuyện tương tự. Bạn nhận được các tính năng lưu trữ bổ sung mà tự lưu trữ không cung cấp cho bạn theo mặc định và có thể khá khó để tự thực hiện.

Thông thường các sản phẩm phơi bày dịch vụ web tự lưu trữ vẫn sẽ khuyên bạn nên đặt chúng phía sau một proxy ngược hoặc người giám sát khác trong sản xuất. Điều này có thể là để đảm bảo nó sẽ sống sót sau các sự cố hoặc duyên dáng trong thời gian gián đoạn mạng. Tôi đang nghĩ về NGINX cho các dịch vụ Docker chẳng hạn. Trong không gian .NET, tôi tin rằng Kestrel được ủy quyền ngược thông qua IIS dưới dạng thông lệ tiêu chuẩn (hoặc có thể NGINX trên Linux / Mac).

Theo truyền thống, các ứng dụng ASP.NET chỉ được lưu trữ trên windows trên Máy chủ Thông tin Internet (IIS). Cách được đề xuất để chạy các ứng dụng ASP.NET Core trên Windows vẫn là sử dụng IIS, nhưng là một máy chủ proxy ngược. Mô-đun ASP.NET Core trong IIS quản lý và ủy quyền các yêu cầu đến máy chủ Kestrel HTTP được lưu trữ ngoài quy trình.

— Kasey nói
nguồn