Hàng đợi tin nhắn so với dịch vụ web? [đóng cửa]

Trong những điều kiện nào người ta sẽ ưu tiên các ứng dụng nói chuyện qua hàng đợi tin nhắn thay vì qua các dịch vụ web (tôi chỉ có nghĩa là XML hoặc JSON hoặc YAML hoặc bất cứ điều gì qua HTTP ở đây, không phải bất kỳ loại cụ thể nào)?

Tôi phải nói chuyện giữa hai ứng dụng trên mạng cục bộ. Một sẽ là một ứng dụng web và phải yêu cầu các lệnh trên một ứng dụng khác (chạy trên phần cứng khác nhau). Các yêu cầu là những thứ như tạo người dùng, di chuyển tệp và tạo thư mục. Trong những điều kiện nào tôi sẽ thích Dịch vụ web XML (hoặc TCP thẳng hoặc một cái gì đó) để sử dụng hàng đợi Tin nhắn?

Ứng dụng web là Ruby on Rails, nhưng tôi nghĩ câu hỏi còn rộng hơn thế.

Khi bạn sử dụng dịch vụ web, bạn có máy khách và máy chủ:

1. Nếu máy chủ bị lỗi, máy khách phải chịu trách nhiệm xử lý lỗi.
2. Khi máy chủ hoạt động trở lại, máy khách có trách nhiệm gửi lại nó.
3. Nếu máy chủ đưa ra phản hồi cho cuộc gọi và máy khách bị lỗi thì thao tác sẽ bị mất.
4. Bạn không có sự tranh chấp, đó là: nếu hàng triệu khách hàng gọi một dịch vụ web trên một máy chủ trong một giây, rất có thể máy chủ của bạn sẽ ngừng hoạt động.
5. Bạn có thể mong đợi phản hồi ngay lập tức từ máy chủ, nhưng bạn cũng có thể xử lý các cuộc gọi không đồng bộ.

Khi bạn sử dụng hàng đợi tin nhắn như RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, tuxedo bạn mong đợi các kết quả khác nhau và có khả năng chịu lỗi hơn:

1. Nếu máy chủ bị lỗi, hàng đợi vẫn duy trì thông báo (tùy chọn, ngay cả khi máy tắt).
2. Khi máy chủ hoạt động trở lại, nó sẽ nhận được thông báo đang chờ xử lý.
3. Nếu máy chủ đưa ra phản hồi cho cuộc gọi và máy khách không thành công, nếu máy khách không xác nhận phản hồi thì tin nhắn vẫn tồn tại.
4. Bạn có sự tranh chấp, bạn có thể quyết định có bao nhiêu yêu cầu được xử lý bởi máy chủ (thay vào đó gọi nó là worker).
5. Bạn không mong đợi một phản hồi đồng bộ ngay lập tức, nhưng bạn có thể thực hiện / mô phỏng các cuộc gọi đồng bộ.

Hàng đợi tin nhắn có nhiều tính năng hơn nhưng đây là một số quy tắc để quyết định xem bạn muốn tự xử lý các điều kiện lỗi hay để chúng vào hàng đợi tin nhắn.

Đã có một số lượng lớn các nghiên cứu gần đây trong việc xem xét cách các cuộc gọi REST HTTP có thể thay thế khái niệm hàng đợi tin nhắn.

Nếu bạn giới thiệu khái niệm về một quy trình và một nhiệm vụ như một tài nguyên, thì nhu cầu về lớp nhắn tin giữa sẽ bắt đầu bay hơi.

Ví dụ:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Một tác vụ có thể có nhiều bước để khởi tạo và một quy trình có thể trả về trạng thái khi được thăm dò hoặc POST vào URL gọi lại khi hoàn tất.

Điều này thật đơn giản và trở nên khá mạnh mẽ khi bạn nhận ra rằng bây giờ bạn có thể đăng ký một nguồn cấp dữ liệu rss / nguyên tử của tất cả các quy trình và tác vụ đang chạy mà không cần bất kỳ lớp giữa nào. Bất kỳ hệ thống xếp hàng nào cũng sẽ yêu cầu một số loại giao diện web, và khái niệm này được tích hợp sẵn mà không cần một lớp mã tùy chỉnh khác.

Tài nguyên của bạn tồn tại cho đến khi bạn xóa chúng, điều đó có nghĩa là bạn có thể xem thông tin lịch sử lâu sau khi quá trình và nhiệm vụ hoàn thành.

Bạn đã xây dựng trong khám phá dịch vụ, ngay cả đối với một tác vụ có nhiều bước, không có bất kỳ giao thức phức tạp nào.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Khám phá dịch vụ của bạn là một dạng HTML - một định dạng phổ quát và có thể đọc được.

Toàn bộ dòng chảy có thể được sử dụng theo chương trình hoặc bởi con người, sử dụng các công cụ được chấp nhận phổ biến. Đó là một khách hàng điều khiển, và do đó RESTful. Mỗi công cụ được tạo cho web có thể thúc đẩy các quy trình kinh doanh của bạn. Bạn vẫn có các kênh thông báo thay thế bằng cách POST không đồng bộ vào một mảng các máy chủ nhật ký riêng biệt.

Sau khi bạn xem xét nó một lúc, bạn ngồi lại và bắt đầu nhận ra rằng REST có thể loại bỏ nhu cầu về hàng đợi nhắn tin và ESB hoàn toàn.

http://www.infoq.com/presentations/BPM-with-REST

Hàng đợi tin nhắn là lý tưởng cho các yêu cầu có thể mất nhiều thời gian để xử lý. Các yêu cầu được xếp hàng và có thể được xử lý ngoại tuyến mà không chặn ứng dụng khách. Nếu khách hàng cần được thông báo về việc hoàn thành, bạn có thể cung cấp một cách để khách hàng kiểm tra định kỳ trạng thái của yêu cầu.

Hàng đợi tin nhắn cũng cho phép bạn mở rộng quy mô tốt hơn theo thời gian. Nó cải thiện khả năng của bạn để xử lý các đợt hoạt động nặng, bởi vì quá trình xử lý thực tế có thể được phân phối theo thời gian.

Lưu ý rằng hàng đợi tin nhắn và dịch vụ web là các khái niệm trực giao, tức là chúng không loại trừ lẫn nhau. Ví dụ: bạn có thể có một dịch vụ web dựa trên XML hoạt động như một giao diện cho hàng đợi tin nhắn. Tôi nghĩ rằng sự khác biệt mà bạn đang tìm kiếm là Hàng đợi Tin nhắn so với Yêu cầu / Phản hồi, sau đó là khi yêu cầu được xử lý đồng bộ.

Hàng đợi tin nhắn không đồng bộ và có thể thử lại một số lần nếu việc gửi không thành công. Sử dụng hàng đợi tin nhắn nếu người yêu cầu không cần chờ phản hồi.

Cụm từ "dịch vụ web" khiến tôi nghĩ đến các cuộc gọi đồng bộ đến một thành phần phân tán qua HTTP. Sử dụng dịch vụ web nếu người yêu cầu cần phản hồi lại.

Tôi nghĩ nói chung, bạn muốn có một dịch vụ web cho một nhiệm vụ chặn (nhiệm vụ này cần phải được hoàn thành trước khi chúng tôi thực thi nhiều mã hơn) và một hàng đợi tin nhắn cho một nhiệm vụ không chặn (có thể mất nhiều thời gian, nhưng chúng tôi không Không cần phải đợi nó).