Мы начинаем новый проект, который имеет некоторые требования к обмену сообщениями и очередям, которые являются довольно простыми, но в будущем могут возникнуть некоторые дополнительные требования к таким вещам, как саги, для обработки сообщений, которые могут поступать не по порядку и должны бытьresequenced.
Недавно мы выпустили проект, полностью размещенный на Amazon EC2, в котором также есть простая система обмена сообщениями.У нас есть очень упрощенный небольшой механизм pub / sub, посредством которого мы получаем сообщение, а затем выясняем, какой обработчик использовать для сообщения, основываясь на его типе.В нашем новом проекте у нас также есть похожий механизм, и у него могут быть некоторые более сложные требования, но даже если бы мы могли покончить с собственным кодом для разрешения обработчиков сообщений, это тоже было бы здорово.
Мы 'мы действительно хотим использовать NServiceBus, так как модель pub / sub действительно хороша, но до сих пор мы использовали Amazon SQS в качестве поставщика очереди.На каждой из наших машин EC2 есть работник, который прослушивает одну и ту же очередь SQS и извлекает сообщения для ее обработки.Очевидно, что SQS не поддерживается как транспортный уровень (и я знаю, что это потому, что NServiceBus построен на основе надежной очереди с низкой задержкой) в NServiceBus.
Я знаю, что у NServiceBus есть дистрибьютор, и я мог бы представить, что этона его собственном экземпляре EC2, но проблема в том, что там есть огромная единственная точка отказа, поэтому мы в основном облажались, если это пойдет не так.Из того, что я понял, люди настраивают отказоустойчивые кластеры Windows для решения этой проблемы для внутренних сетей, но я не знаю, применимо ли это к EC2.
Этот был одним из немногихпосты в блоге, которые я мог найти кем-то, кто действительно пытался использовать NServiceBus в облачном контексте, и он, похоже, не рекомендует его.Мне просто интересно, попытался ли кто-нибудь еще здесь, и если так, у них есть какой-нибудь совет, чтобы предложить?Похоже на такой позор, что мы не сможем использовать такой замечательный фреймворк только потому, что мы размещены в облаке.
Похоже, что достигнут некоторый прогресс с очередями Azure, на которые мы могли бы взглянуть, но сейчас мы хотели бы сохранить инфраструктуру в Amazon, поскольку у нас есть много средств автоматизации сборки, которые мы можем использовать повторно, основываясь на этом.