Akka có lỗi với các nhà môi giới tin nhắn JMS / AMQP không? [đóng cửa]

Tôi đã dành tuần cuối cùng để tìm hiểu sâu về các tài liệu của Akka và cuối cùng cũng hiểu hệ thống diễn viên là gì và những vấn đề mà họ giải quyết.

Sự hiểu biết của tôi (và kinh nghiệm với) các nhà môi giới tin nhắn JMS / AMQP truyền thống là họ tồn tại để cung cấp các thông tin sau:

• Xử lý không đồng bộ giữa người sản xuất và người tiêu dùng; và
• Đảm bảo gửi tin nhắn, bao gồm kiên trì, thử lại và dự phòng

Nhưng Akka không cung cấp điều này, mà không có tất cả các cơ sở hạ tầng cần thiết và chi phí hoạt động?

• Trong Akka, tất cả các giao tiếp diễn viên là không đồng bộ và không chặn; và
• Trong Akka, SupervisorStrategiestồn tại để thực hiện thử lại, dự phòng và leo thang. Các diễn viên có thể được cấu hình để duy trì hầu như bất kỳ loại cửa hàng nào, nếu đây cũng là một yêu cầu.

Vì vậy, điều này làm tôi tự hỏi: nếu ứng dụng của tôi sử dụng Akka, tôi có bao giờ có nhu cầu đưa các nhà môi giới JMS / AMQP (ví dụ ActiveMQ, RabbitMQ, Kafka) vào hình ảnh không? Nói cách khác, có bao giờ một trường hợp sử dụng nơi một ứng dụng mới Akka-based sẽ sau đó cũng bảo đảm sự ra đời của một mới cụm môi giới JMS / AMQP? Tại sao hay tại sao không?

Lập luận duy nhất là có lẽ ứng dụng Akka của tôi phải tích hợp với một hệ thống khác. Nhưng trong trường hợp đó, mô-đun Akka-Camel cho phép Akka truy cập vào danh sách các khả năng tích hợp gần như vô tận của Camel (TCP, FTP, ZeroMQ, danh sách sẽ tiếp tục và bật ...).

Suy nghĩ?

Người mẫu diễn viên

Mô hình diễn viên là chiến lược khoa học máy tính để xây dựng các ứng dụng xử lý nhiều tính toán đồng thời và xử lý trạng thái. Đây không phải là chiến lược duy nhất mà là cách tiếp cận được thử nghiệm rất đơn giản, đơn giản và đáng tin cậy để chuyển tính toán thành các diễn viên , giao tiếp thông qua các thông điệp mà họ xử lý một lần và theo thứ tự.

Akka là một khung công tác triển khai mô hình diễn viên và cho phép bạn xây dựng các hệ thống diễn viên với tất cả các cơ sở hạ tầng và các tính năng đã được xây dựng (như sử dụng JQuery thay vì javascript).

Nhắn tin

Hệ thống tin nhắn là các ứng dụng có thể gửi và lấy tin nhắn. Có nhiều loại từ hàng đợi cơ bản đến phần mềm doanh nghiệp lớn với các chủ đề, quán rượu / phụ, sự kiên trì và các tính năng khác nhưng mục tiêu cuối cùng là như nhau. Lưu một số byte ở đâu đó và lấy lại chúng sau, với một số thứ tự. Trường hợp sử dụng chính hiện nay là tách các hệ thống và cho phép xử lý không đồng bộ ở các lịch trình hoặc tốc độ khác nhau. RabbitMQ, NATS, Kafka, v.v ... là tất cả các ví dụ về hệ thống tin nhắn.

So sánh

Mô hình Actor và khung Akka là các công cụ cấp thấp là một cách tuyệt vời để xây dựng các ứng dụng , như hàng đợi tin nhắn.

Bạn có thể sử dụng Akka thay vì một hàng đợi tin nhắn? Chắc chắn rồi. Nếu bạn đang xây dựng phần mềm đã sử dụng mô hình diễn viên thì có lẽ bạn không cần hàng đợi tin nhắn bên ngoài, đặc biệt là để gửi tin nhắn trong cùng một chủ đề hoặc ứng dụng. Bạn có thể sử dụng các khả năng của Akka Remote để gửi tin nhắn đến các hệ thống diễn viên khác đang chạy trên các máy khác.

Tuy nhiên, điều này có làm cho hệ thống nhắn tin trở nên lỗi thời? Tuyệt đối không. Chỉ vì bạn có thể tự mình viết mã tất cả những thứ này không có nghĩa là bạn cần, đặc biệt là khi mô hình diễn viên không tốt cho vấn đề của bạn hoặc bạn cần các ngôn ngữ, ứng dụng, API bên ngoài, hệ điều hành, cơ sở dữ liệu, v.v. để giao tiếp với nhau (cho dù họ là hệ thống diễn viên hay không).

Nếu bạn chỉ cần chuyển một số tin nhắn giữa hai hệ thống, hãy sử dụng hàng đợi tin nhắn. Nếu bạn cần xử lý trạng thái có thể mở rộng và nhắn tin có độ trễ thấp trong cùng một ứng dụng, thì hãy sử dụng mô hình diễn viên. Cả hai đều tồn tại ở các cấp độ hoàn toàn khác nhau và cách bạn sử dụng chúng phụ thuộc vào giải pháp bạn đang xây dựng.

Có một câu trả lời tuyệt vời trên SO về mô hình diễn viên tương tự này so với nhắn tin: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- hoặc tibco