2015-12-08 14 views
9

Tôi có một dự án ASP.NET MVC ASP.NET cần được lưu trữ trên hai máy chủ khác nhau. Tôi biết điều này có vẻ lạ nhưng đây là yêu cầu của khách hàng của tôi.Lưu trữ dự án ASP.NET MVC trong hai máy chủ vật lý

Cụ thể, tôi sẽ có 2 tải máy chủ cân bằng

  • Web Server - phơi bày cho công chúng (miền sẽ trỏ đến ip công cộng của máy chủ này)
  • App Server - giao tiếp với nội cơ sở hạ tầng (Active Directory, Cơ sở dữ liệu, Bảo mật, vv)

Simple diagram

Tôi đang nghĩ đến việc tạo một lớp khác (ASP.NET Web API), để máy chủ web chỉ phục vụ các trang HTML, máy chủ ứng dụng sẽ chứa nhật ký nghiệp vụ và hiển thị điểm cuối cho tất cả khách hàng (web, di động) gọi điện. Máy chủ Web sẽ liên lạc với Máy chủ ứng dụng thông qua các dịch vụ RESTFUL.

Có cách nào tốt hơn để làm không? Bất kỳ giải pháp sẽ được đánh giá rất nhiều.

Cảm ơn trước,

Trả lời

5

Đây là một cách khá bình thường làm việc - để cho các máy chủ web tập trung vào phục vụ các trang và để cho các máy chủ back-end làm công việc khó khăn với logic kinh doanh ứng dụng. Nếu nó được sử dụng nhiều với một thông lượng dữ liệu lớn, tôi sẽ xem xét làm cho nó ba tầng với các máy chủ web, ứng dụng và cơ sở dữ liệu riêng biệt.

API Web là một lựa chọn khá tốt cho giao tiếp giữa hai máy chủ, nhưng có thể đáng xem WCF là một giải pháp thay thế nếu bạn thấy bạn cần vượt ra ngoài các hoạt động REST cơ bản. Đó là một chi phí lớn hơn để có được nó chạy mặc dù, và nó chắc chắn không dành cho những người yếu tim!

EDIT

Vì vậy, những gì bạn cần làm là di chuyển tất cả các logic kinh doanh hiện tại của bạn ra khỏi điều khiển hiện tại của bạn và vào một tập hợp tương ứng của bộ điều khiển Web API mà sẽ ngồi trên máy chủ thứ hai. Nếu bạn cẩn thận, bạn chỉ có thể sao chép các phương thức điều khiển MVC của bạn thẳng vào bộ điều khiển API Web của bạn và thêm các thuộc tính định tuyến thích hợp. Cơ sở dữ liệu của bạn (nếu bạn có) cũng sẽ cần phải ngồi trên máy chủ thứ hai.

Khi bạn đã thực hiện điều đó, tất cả các bộ điều khiển MVC của bạn sẽ thực hiện là thực hiện cuộc gọi đến API Web đang chạy trên máy chủ thứ hai. Các bộ điều khiển MVC không nên thực hiện bất kỳ loại xử lý nào trên dữ liệu của bạn ngoài các chỉnh sửa cơ bản để làm cho nó trông đẹp mắt (giữ cho bộ điều khiển của bạn sạch sẽ là thực hành tốt anyway).

Điều đó sẽ cung cấp cho bạn ý tưởng cơ bản về những gì bạn cần làm. Nếu bạn cần bất cứ điều gì cụ thể hơn về bất kỳ các bước, chỉ cần hét lên và tôi sẽ xem nếu tôi có thể xây dựng.

+0

Tôi hiểu lợi thế của kiến ​​trúc này, nhưng trong tình huống này, ASP.NET MVC sẽ không hoạt động (xem & bộ điều khiển được kết hợp chặt chẽ). Có anyway để tách các dự án MVC mà không sửa đổi tất cả mọi thứ? –

+1

Ah, tôi thấy những gì bạn đang cố gắng làm bây giờ. Không, bạn không thể thực hiện một dự án MVC hiện có và chia nó ra, như bạn nói các bộ điều khiển và khung nhìn được kết hợp chặt chẽ. Tôi sẽ cập nhật câu trả lời của tôi với một lời giải thích chi tiết hơn, nhưng có, bạn sẽ cần phải đưa logic kinh doanh của bạn ra khỏi bộ điều khiển MVC của bạn. – Mourndark

+0

Khi tôi thực hiện cuộc gọi từ bộ điều khiển MVC đến bộ điều khiển webapi, tôi có nên thực hiện cuộc gọi nội bộ hoặc cuộc gọi dịch vụ web không? Tôi cũng gặp khó khăn với việc xác thực mẫu vì logic xác thực hiện tại đang được viết trong lớp MVC, nó sẽ mất rất nhiều nỗ lực để di chuyển nó vào lớp WebAPI. Hơn nữa, tôi sẽ cần phải thực hiện thử lại logic cũng như an toàn API (chỉ cho phép ứng dụng đáng tin cậy kết nối) để làm cho nó mạnh mẽ hơn. Có ý tưởng nào không? Cảm ơn –

4

Chúng tôi đang sử dụng cấu trúc tương tự trong dự án của mình. Một lớp dịch vụ đang trưng ra các API REST đang được nhiều trang web và ứng dụng dành cho thiết bị di động tiêu thụ. Vẻ đẹp của kiến ​​trúc này là tất cả các phức tạp kinh doanh được ẩn đằng sau các API trong khi giao diện người dùng chủ yếu đề cập đến nhu cầu trình bày.

Nhưng bạn cần phải cẩn thận về hai điều trong khi phát triển kiến ​​trúc này:

1. Bảo vệ các điểm kết thúc (API REST) ​​ - Nếu bạn đang có kế hoạch để phát triển ứng dụng di động sẽ tiêu thụ các API sau đó bạn phải phơi bày các điểm cuối thông qua tường lửa và truy cập internet. Một trong các tùy chọn là sử dụng xác thực mã thông báo xác thực để xác thực yêu cầu. Bạn có thể sử dụng giao thức Oauth để bảo mật các điểm cuối.

2. Thách thức khi sắp xếp và Deserializing: Vì REST sử dụng JSON như một định dạng chuẩn truyền dữ liệu và Json không gõ mạnh, thách thức là ánh xạ dữ liệu đến các mô hình thích hợp ở cả hai đầu. Để giải quyết điều này, chúng tôi đã tạo một dự án chung cho các mô hình và được thêm vào cả các dự án (api và web). Khi ở cuối API, chúng tôi đã serilized một mô hình, chúng tôi đã deserilized nó thành cùng một mô hình tại dự án web. Họ lập bản đồ hoàn hảo mà không có trục trặc.

Hy vọng các mẹo ở trên sẽ giúp bạn.

Các vấn đề liên quan