Ứng dụng ASP.NET có thể xử lý các sự kiện NServiceBus không?

Question

Hầu hết nếu không phải tất cả các ví dụ của NSB cho ASP.NET (hoặc MVC) đều có ứng dụng web gửi một tin nhắn bằng cách sử dụng Bus.Send và có thể đăng ký gọi lại đơn giản, chủ yếu là cách tôi sử dụng nó trong ứng dụng của mình.

Điều tôi đang tự hỏi là nếu có thể và/hoặc có ý nghĩa gì đối với xử lý thư trong cùng một ứng dụng ASP.NET.

Lý do chính tôi yêu cầu là bộ nhớ đệm. Quá trình có thể diễn ra như sau:

1. Người dùng bắt đầu yêu cầu từ ứng dụng web.
2. Ứng dụng web gửi tin nhắn đến một máy chủ ứng dụng độc lập và ghi lại thay đổi trong cơ sở dữ liệu cục bộ.
3. Trong các yêu cầu trang trong tương lai từ cùng một người dùng, ứng dụng web nhận thức được sự thay đổi và liệt kê nó trong trạng thái "đang chờ xử lý".
4. Một loạt nội dung xảy ra trên back-end và cuối cùng các yêu cầu được chấp thuận hoặc bị từ chối. Sự kiện được xuất bản tham chiếu đến yêu cầu ban đầu.
5. Tại thời điểm này, ứng dụng web phải bắt đầu hiển thị thông tin mới nhất.

Bây giờ, trong ứng dụng web thực sự, gần như chắc chắn rằng yêu cầu đang chờ xử lý này sẽ được lưu vào bộ nhớ cache, có thể trong một thời gian dài, bởi vì ứng dụng phải truy vấn cơ sở dữ liệu để thay đổi đang chờ xử lý mỗi lần người dùng yêu cầu thông tin hiện tại. Vì vậy, khi yêu cầu cuối cùng hoàn thành trên back-end - có thể mất một phút hoặc một ngày - ứng dụng web cần, ở mức tối thiểu, để vô hiệu hóa mục nhập bộ nhớ cache này và thực hiện một tra cứu DB khác.

Bây giờ tôi nhận ra rằng điều này có thể được quản lý với các đối tượng SqlDependency và vân vân, nhưng hãy giả sử rằng chúng không có sẵn - có lẽ nó không phải là back-end của SQL Server hoặc có lẽ truy vấn thông tin hiện tại đi tới dịch vụ web , bất cứ điều gì. Câu hỏi đặt ra là, làm cách nào để ứng dụng web nhận thức được sự thay đổi về trạng thái?

Nếu số là có thể xử lý thông điệp NServiceBus trong ứng dụng ASP.NET, ngữ cảnh của trình xử lý là gì? Nói cách khác, container IoC sẽ phải tiêm một loạt các phụ thuộc, nhưng phạm vi của chúng là gì? Điều này có thực hiện trong bối cảnh yêu cầu HTTP không? Hay mọi thứ cần phải là tĩnh/singleton cho trình xử lý tin nhắn?

Có cách tiếp cận tốt hơn/được đề xuất cho loại vấn đề này không?

Answer 1

Điểm cuối (NSB) có thể được tạo để đăng ký sự kiện đã xuất bản và cập nhật bộ nhớ cache. Sự kiện không được xuất bản cho đến khi cập nhật thực tế được thực hiện để bạn không bị đồng bộ hóa. Ứng dụng web sẽ tiếp tục lấy dữ liệu từ bộ nhớ cache theo yêu cầu tiếp theo hoặc bạn có thể tạo trong một số loại chậm trễ.

Answer 2

Tôi đã tự hỏi chính điều tương tự đó - mức độ phù hợp thích hợp cho ứng dụng web với cơ sở hạ tầng NServiceBus là gì? Trong miền của tôi, tôi có một vấn đề tương tự để giải quyết liên quan đến việc sử dụng SignalR thay cho bộ nhớ cache. Giống như bạn, tôi đã không tìm thấy nhiều tài liệu về mẫu đặc biệt này. Tuy nhiên, tôi nghĩ rằng nó có thể lý do thông qua một số các tác động của việc theo dõi nó, sau đó quyết định nếu nó có ý nghĩa trong môi trường của bạn.

Tóm lại, tôi sẽ nói rằng tôi tin rằng hoàn toàn có thể có một ứng dụng web đăng ký các sự kiện của NServiceBus. Tôi không nghĩ rằng sẽ có bất kỳ rào cản kỹ thuật nào, mặc dù tôi phải thú nhận rằng tôi đã không thực sự thử nó - nếu bạn có thời gian, bằng mọi cách hãy cho nó một shot. Tôi chỉ có cảm giác mạnh mẽ rằng nếu một người bắt đầu cần để thực hiện việc này, thì có lẽ thiết kế tổng thể tốt hơn đang chờ được khám phá. Đây là lý do tại sao tôi nghĩ rằng điều này là như vậy:

1. Câu hỏi có liên quan để yêu cầu liên quan đến việc triển khai bộ nhớ cache của bạn. Nếu đó là một mô hình phân tán hoặc tập trung (nghĩ SQL, MongoDB, Memcached, vv), thì cách tiếp cận mà @Adam Fyles gợi ý âm thanh như một ý tưởng hay. Bạn sẽ không cần để thông báo cho mọi ứng dụng web - việc cập nhật bộ nhớ cache của bạn có thể được thực hiện bởi một điểm cuối NServiceBus duy nhất là không phải là một phần của ứng dụng web của bạn. Nói cách khác, mọi ví dụ về ứng dụng web của bạn và điểm cuối "bộ nhớ cache cập nhật" sẽ truy cập cùng một bộ nhớ cache được chia sẻ. Tuy nhiên, nếu cache của bạn đang trong quá trình xử lý, giống như Web Cache của Microsoft, thì tất nhiên bạn còn lại với một vấn đề phức tạp hơn để giải quyết trừ khi bạn có thể dựa vào tính nhất quán cuối cùng như đã được đề xuất.
2. Nếu ứng dụng web của bạn đăng ký một sự kiện NServiceBus cụ thể, thì bạn sẽ cần có hàng đợi đầu vào duy nhất cho mỗi phiên bản ứng dụng web của mình. Vì thực tiễn tốt nhất là cân nhắc ứng dụng web của bạn bằng cách sử dụng bộ cân bằng tải, điều đó có nghĩa là bạn có thể kết thúc với N hàng đợi và ít nhất N đăng ký, điều này khiến bạn lo lắng nhiều hơn số lượng đăng ký không đổi. Một lần nữa, không phải là một rào cản kỹ thuật, chỉ là một cái gì đó mà sẽ làm cho tôi nhướn mày.
3. Bài viết David Boike đã được liên kết làm tăng một điểm thú vị về các hồ bơi ứng dụng và cách tuổi thọ của chúng có thể không chắc chắn. Ngoài ra, nếu bạn có nhiều hồ bơi ứng dụng chạy đồng thời cho cùng một ứng dụng trên máy chủ (một tình huống phổ biến), tất cả chúng sẽ cố gắng đọc từ cùng một hàng đợi tin nhắn và không có cách nào tốt để xác định xem ứng dụng nào thực sự xử lý thông báo . Nhiều hơn thì không, điều đó sẽ quan trọng. Ngược lại, việc gửi lệnh không yêu cầu hàng đợi nhập theo this post by Udi Dahan. Đây là lý do tại sao tôi nghĩ rằng các lệnh một chiều được gửi bởi các ứng dụng web thường được thấy nhiều hơn trong thực tế.
4. Có rất nhiều điều để nói về Nguyên tắc về trách nhiệm duy nhất tại đây. Nói chung, tôi sẽ nói rằng nếu bạn có thể ủy thác "chuyên môn" của việc gửi và nhận tin nhắn đến một Host NSUsBus càng nhiều càng tốt, kiến ​​trúc tổng thể của bạn sẽ sạch hơn và dễ quản lý hơn. Qua trải nghiệm, tôi thấy rằng nếu tôi coi trang web của mình là một thực thể duy nhất, nghĩa là loại bỏ tất cả sự thừa nhận về bản sắc máy chủ web cá nhân, rằng tôi có xu hướng ít lo lắng hơn. Có mỗi máy chủ web là điểm cuối trên loại xe buýt phá vỡ quan niệm đó, bởi vì bây giờ "máy chủ nào" xuất hiện trở lại dưới dạng hàng đợi thông báo.

Điều này có giúp làm rõ mọi thứ không?