Проблема не в SF. Главная проблема вашего проекта заключается в том, что вы связываете архитектурные требования с реализациями.SF работает поверх VirtualMachines, в конце концов, единственное отличие состоит в том, что SF размещает сервисы на этих машинах, используя другое решение, в котором у вас будет агент, внедряющий эти сервисы, или выполняющее развертывание вручную.Проблемы одинаковы.
Из описания ясно, что требование в вашем проекте - это необходимость в очереди сообщений, концепция очередей одинакова, независимо от того, является ли это служебной шиной, RabbitMQ илиMSMQ.Каждый из них будет иметь базовые основы очередей со спецификой каждой реализации, некоторые могут добавлять транзакции, некоторые могут реализовывать несколько шаблонов и т. Д.
Если вы разрабатываете на основе конкретной реализации, вы объедините свое решениереализации и сделать ваше решение трудным в обслуживании и решать проблемы, как вы описали.
Такие решения, как NServiceBus и Masstransit уменьшают многие из этих связей из вашего кода, и если вы считаете, что их недостаточно, вы можете создатьваша собственная абстракция.Затем вы используете конфигурации, чтобы связать свою бизнес-логику с реализациями.
Несмотря на вышеприведенный совет, я бы не рекомендовал использовать разные решения для среды, поскольку, как уже говорилось ранее, каждое решение имеет свои собственные реализации, и онимогут не ассимилироваться друг с другом, например, вы можете столкнуться с проблемами в производственном процессе, поскольку вы разрабатывали для MSMQ в средах DEV и TEST, а при развертывании в Production вы используете ServiceBus, у них есть разные ограничения, такие как размер сообщения, срок хранения и сын в.
Если вы хотите использовать MSMQ, вы можете добавить MSMQ к виртуальным машинам, на которых работает ваш кластер, и без проблем подключаться к вашим службам.Сначала взгляните на эту SO: Как использовать MSMQ в Azure Service Fabric