Tìm cách xây dựng một ứng dụng web chạy trên MVC4 tại AppHarbor. Vì lợi ích của sự đáp ứng và hiệu suất, các nhiệm vụ chạy lâu hơn một chút (thông thường, tạo/gửi email, thay đổi kích thước hình ảnh, xử lý giao dịch thanh toán, vv) sẽ được xử lý bằng cách đặt một thông báo trên hàng đợi tin nhắn.Thiết kế giao diện tốt để sử dụng RabbitMQ từ ASP.NET MVC và ứng dụng của nhân viên
Cũng sẽ có một hoặc nhiều người lao động, một nơi nào đó ở ngoài đó, xử lý các thông điệp và xử lý mọi thứ cần được xử lý. Cơ chế xếp hàng trung tâm sẽ là RabbitMQ, đặc biệt là dịch vụ CloudAMQP được lưu trữ trên AppHarbor. Về lý thuyết, kiến trúc này sẽ cho phép khả năng mở rộng "vô hạn" bằng cách thêm nhiều công nhân hơn.
Bây giờ, vì lợi ích của kiến trúc tốt, khả năng kiểm tra, v.v., tôi muốn đặt RabbitMQ phía sau một hoặc nhiều giao diện có thể dễ dàng được chế nhạo. Tôi có một vài cân nhắc để xem xét khi xác định các giao diện này.
- Cho đến khi tôi nhận được bất kỳ người dùng trả tiền nào, tôi bị giới hạn trong cung cấp CloudAMQP miễn phí. Điều đó có nghĩa là tối đa ba kết nối đồng thời.
- Với ràng buộc trước đó, tôi muốn cố gắng giới hạn bản thân mình với một kết nối cho mỗi ứng dụng. Một cho ứng dụng MVC, một cho mỗi công nhân. Đó là nó.
- Kết nối trong RabbitMQ được thiết kế để tồn tại trong một thời gian dài. Tuy nhiên, nhiều ví dụ hiển thị mã mở một kết nối rõ ràng (sau đó là một kênh), gửi một tin nhắn, sau đó đóng lại.
- Để đa luồng, người dùng có thể sử dụng cùng một kết nối nhưng không thể sử dụng cùng một kênh. Theo tôi hiểu, bạn có thể chia sẻ kết nối trong một ứng dụng đa luồng, sau đó mở một số kênh, ví dụ một kênh cho mỗi luồng.
- Ứng dụng MVC của tôi thường sẽ chỉ là một nhà xuất bản. Ứng dụng công nhân sẽ là cả người tiêu dùng và nhà xuất bản - ví dụ, nhân viên có thể nhận được thông báo để xử lý thanh toán, điều này sẽ dẫn đến việc xuất bản thư để gọi thông báo email cho người dùng cho biết thành công hay thất bại.
- Đối với ứng dụng MVC, các kết nối thường sẽ chỉ được sử dụng trong một thời gian rất ngắn - để xếp hàng một tin nhắn.
- Đối với người lao động, tôi nghĩ rằng các kết nối dài hạn, ít nhiều sẽ mở vĩnh viễn suốt đời của người lao động.
Ok, tuyệt, rất nhiều thứ. Không có kinh nghiệm với RabbitMQ trước dự án này, tôi bị ám ảnh bởi một số điểm đạn bổ sung.
- Nguyên tắc phân tách giao diện. Tôi có nên phân chia điều này thành hai giao diện riêng biệt - như IQueueServiceConsumer và IQueueServiceProducer - hay là lấy những thứ quá xa? Tôi thấy tôi luôn có thể sử dụng SRP vv để phân chia nhiều thứ hơn thành nhiều đơn vị nguyên tử hơn và tôi không muốn chú Bob săn tôi xuống (nhiều hơn tôi trong tên giao diện), nhưng tôi tự hỏi mình phải đi bao xa thực hiện việc này.
- Vì tôi sẽ chỉ có một máy chủ web duy nhất, ít nhất là ở lần đầu tiên, liệu ý tưởng thực sự có kết nối lâu dài với hàng đợi trong ứng dụng web không? Việc mở và đóng chúng cho một cơ hội lý thuyết về một số xảy ra cùng một lúc, có nghĩa là các xung đột và các thông điệp tiềm ẩn bị mất. Tin nhắn bị mất không được chấp nhận.
- Làm cách nào để xử lý tuổi thọ của kết nối trong trường hợp này? Mở nó bên trong mô-đun Ninject của tôi (nơi giao diện của tôi thực sự bị ràng buộc với việc thực hiện cụ thể RabbitMQ), và ngắt kết nối nó bằng cách nào đó khi ứng dụng được ... tái chế? Làm thế nào tôi có thể làm một cái gì đó như thế?
- Đối với người lao động, cuộc sống có vẻ dễ dàng hơn.Đặt một phương thức trên giao diện để mở kết nối, sau đó phân phát các kênh tới các chủ đề để nhận tin nhắn. Đảm bảo ứng dụng phát đẹp bằng cách gọi CloseConnection là phù hợp. Hoặc triển khai IDisposable.
- Có một cơ hội - tuy nhiên nhỏ - rằng RabbitMQ có thể được thay thế bằng một cái gì đó khác trong tương lai, do đó tôi không muốn giao diện của mình quá cụ thể đối với xe buýt dịch vụ cụ thể đó (theo nghĩa là đây là cách tôi sử dụng nó) thực hiện.
Có ai khác đã làm việc thông qua những thách thức tương tự khi xây dựng một ứng dụng tương tự không? Bạn có lời khuyên nào về kiến trúc và triển khai thực tế của một giao diện cho hàng đợi tin nhắn không? Tôi có bị thần kinh về điều này hay là những lo lắng của tôi đáng được ghi nhận?
Nếu điều quan trọng, nhu cầu nhắn tin hiện tại của tôi được bao gồm bởi các thông điệp một chiều, không cần phản hồi ngoài việc xác nhận các tin nhắn đã nhận khi quá trình xử lý hoàn tất.
Cảm ơn mọi thông tin chi tiết!
Thú vị, sẽ xem xét điều này, cảm ơn! –