Мы начинаем новый проект, который имеет некоторые требования к обмену сообщениями и очередям, которые являются довольно простыми, но в будущем могут появиться некоторые дополнительные требования к таким вещам, как саги, для обработки сообщений, которые могут поступать не по порядку и должны быть повторно упорядочены.

Мы только что выпустили проект, полностью размещенный на Amazon EC2, в котором также есть простая система обмена сообщениями. У нас есть очень упрощенный небольшой механизм pub / sub, посредством которого мы получаем сообщение, а затем выясняем, какой обработчик использовать для сообщения, основываясь на его типе. В нашем новом проекте у нас также есть подобный механизм, и у него могут быть некоторые более сложные требования, но даже если бы мы могли покончить с собственным кодом для разрешения обработчиков сообщений, это тоже было бы здорово.

Мы действительно стремимся использовать NServiceBus, поскольку модель pub / sub действительно хороша, но до сих пор мы использовали Amazon SQS в качестве поставщика очереди. На каждой из наших машин EC2 есть работник, который прослушивает одну и ту же очередь SQS и извлекает сообщения для ее обработки. Очевидно, что SQS не поддерживается как транспортный уровень (и я знаю, что это потому, что NServiceBus построен вокруг надежной очереди с низкой задержкой) в NServiceBus.

Я знаю, что у NServiceBus есть дистрибьютор, и я мог бы представить хостинг на своем собственном экземпляре EC2, но проблема в том, что существует огромная единственная точка отказа, поэтому мы в основном облажались, если это пойдет не так. Насколько я понимаю, люди настраивают отказоустойчивые кластеры Windows для решения этой проблемы для внутренних сетей, но я не знаю, применимо ли это к EC2.

Этот Это была одна из немногих публикаций в блоге, которую я смог найти у кого-то, кто действительно пытался использовать NServiceBus в облачном контексте, и он, похоже, не рекомендует его. Мне просто интересно, попытался ли кто-нибудь еще здесь, и если так, у них есть какой-нибудь совет, чтобы предложить? Похоже на такой позор, что мы не сможем использовать такую великолепную среду только потому, что мы размещены в облаке.

Похоже, есть некоторыепрогресс мы создаем его с помощью очередей Azure, и на данный момент мы хотели бы сохранить инфраструктуру в Amazon, поскольку у нас есть много средств автоматизации сборки, которые мы можем использовать повторно, основываясь на этом.