Блог

Работники Cloud hub НЕ кластеризованы, однако мы получаем защиту от потери сообщений и распределение рабочей нагрузки по экземплярам mule с использованием постоянных очередей. Также мы можем использовать постоянное хранилище объектов по умолчанию (_defaultUserObjectStore ) для распределенного кэширования (с настройкой). Поправьте меня, если я здесь ошибаюсь.

1. При наличии вышеуказанных функций чего нам не хватает в CloudHub по сравнению с локальными кластерами? ( Предотвращает ли это проблемы с параллелизмом / одноразовой доставкой сообщений?)

2. Прежде всего, почему Mulesoft не включила функцию кластеризации в Cloud hub?

Я бы сказал, что благодаря представленным выше функциям вы ничего не упустите. Также имейте в виду, что даже в кластере On Prem HA общие очереди и состояния (хранилища объектов) по умолчанию хранятся в общей памяти и не сохраняются, если весь кластер выходит из строя. Для обеспечения сохраняемости вам также необходимо выполнить настройки для локального кластера. Таким образом, для обеспечения истинной надежности сообщений я бы посоветовал вам обратиться к внешнему брокеру сообщений или сервису, такому как Anypoint MQ.

Что касается того, почему Mulesoft не включила кластеризацию, я не могу ответить, поскольку я не являюсь сотрудником Mulesoft. Однако наилучшей практикой при интеграции и разработке API является сохранение состояния приложения. При соблюдении этого правила и использовании внешнего посредника сообщений, такого как Anypoint MQ, для реализации надежного шаблона обмена сообщениями потребность в среде выполнения Mule HA возможностях кластера невелика.