Чи Akka застаріли брокери повідомлень JMS / AMQP? [зачинено]

Останній тиждень я провів глибоке занурення в документи Акки і нарешті зрозумів, що таке акторські системи та проблеми, які вони вирішують.

Я розумію (і досвід) традиційних посередників повідомлень JMS / AMQP полягає в тому, що вони існують, щоб забезпечити наступне:

• Асинхронна обробка між виробником і споживачем; і
• Гарантія доставки повідомлень, включаючи стійкість, повторні спроби та резервні копії

Але чи не забезпечує Akka це без усієї необхідної інфраструктури та експлуатаційних витрат?

• У Akka все спілкування в Акторі асинхронне і не блокує; і
• У Akka SupervisorStrategiesіснують, щоб здійснити повторне, резервне та ескалаційне. Актори можуть бути налаштовані на зберігання практично в будь-якому магазині, якщо це теж вимога.

Тому мене цікавить: якщо в моєму додатку використовується Akka, чи не виникає у мене коли-небудь необхідність залучити брокерів JMS / AMQP (наприклад, ActiveMQ, RabbitMQ, Kafka)? Іншими словами, чи коли-небудь використовувався випадок, коли новий додаток на базі Akka також вимагав запровадити новий брокерський кластер JMS / AMQP? Чому або чому ні?

Єдиним аргументом було б те, що, можливо, мій додаток Akka має інтегруватися з іншою системою. Але в такому випадку модуль Akka-Camel дозволяє Акці використовувати загальний, майже нескінченний список можливостей інтеграції (як TCP, FTP, ZeroMQ, список продовжується і продовжується ...).

Думки?

Акторська модель

Модель актора - це стратегія інформатики для побудови додатків, що обробляють безліч паралельних обчислень та стану обробки. Це не єдина стратегія, але це дуже добре перевірений, простий та надійний підхід, який здійснює переміщення обчислень у дійових осіб , які спілкуються за допомогою повідомлень, які вони обробляють одночасно та в порядку.

Akka - це структура, яка реалізує модель актора і дозволяє будувати акторські системи з усією вже побудованою інфраструктурою та функціями (наприклад, використання JQuery замість javascript).

Повідомлення

Системи повідомлень - це програми, які можуть надсилати та завантажувати повідомлення. Існує багато різновидів: від базових черг до великих корпоративних програм з тематикою, pub / sub, стійкістю та іншими функціями, але кінцева мета та сама. Збережіть десь байти і отримайте їх знову пізніше, із впорядкуванням. Основний випадок використання сьогодні - це роз'єднання систем та забезпечення асинхронної обробки з різним графіком або швидкістю. RabbitMQ, NATS, Kafka тощо - це всі приклади систем повідомлень.

Порівняння

Модель Actor і рамка Akka - це інструменти низького рівня, які є чудовим способом побудови додатків , як черги повідомлень.

Чи можете ви використовувати Akka замість черги повідомлень? Звичайно. Якщо ви будуєте програмне забезпечення, яке вже використовує модель актора, вам, ймовірно, не потрібна зовнішня черга повідомлень, особливо для надсилання повідомлень у межах однієї теми чи програми. Ви можете використовувати можливості Akka Remoting навіть для надсилання повідомлень іншим акторським системам, що працюють на інших машинах.

Однак чи робить це обмін повідомленнями застарілими? Абсолютно не. Тільки тому, що ви можете кодувати всі ці речі самостійно, це не означає, що вам це потрібно, особливо коли модель актора не підходить для вашої проблеми або вам потрібні різні мови, програми, зовнішні API, операційні системи, бази даних тощо для спілкування один з одним (чи це акторські системи чи ні).

Якщо вам просто потрібно передати деякі повідомлення між двома системами, скористайтеся чергою повідомлень. Якщо вам потрібна масштабована обробка статі та повідомлення з низькою затримкою в межах однієї програми, тоді використовуйте модель актора. Вони обидва існують на абсолютно різних рівнях, і те, як ви їх використовуєте, залежить від рішення, яке ви будуєте.

Є прекрасна відповідь на цю саму модель актора та повідомлення: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- або-тибко