WebApi в Net Core с использованием RabbitMQ

1. Совершенно нормально вернуть 200. Это лишь один из многих компромиссов для архитектуры микросервисов. Например. с точки зрения производительности, эффективно, если вы можете вернуться раньше с 200 и распространить все изменения асинхронно через остальную часть распределенной системы. С другой стороны, он добавляет еще один тип сложности, который вам необходимо принять - конечную согласованность. Эта концепция как бы описывает то, о чем вы спрашивали. Допустим, ваш клиент получил 200, но если он немедленно вызывает другой микросервис, клиент может не увидеть изменений, внесенных предыдущим запросом, потому что существует вероятность того, что изменения еще не распространены. Вам нужно решить, приемлемо это в вашем проекте или нет. Если нет, возможно, вам следует изменить способ разделения бизнес-домена на микросервисы, пытаясь сгруппировать транзакционно близкие друг к другу объекты вместе, чтобы смягчить такие проблемы. Если вы действительно не можете терпеть конечную согласованность, возможно, вам следует отказаться от микросервисов для конкретного проекта.

2. Да, это возможно, вы могли бы, например, создать реализацию IHostedService для каждой очереди, прослушивающей сообщения, и запускать их параллельно с вашим основным приложением asp net, зарегистрировав их в starutp.cs

3. Вы найдете это в репозитории по ссылкам ниже. Они используют RabbitMQ. Хотя есть небольшая абстракция, которая может усложнить понимание, это отличная реализация с бонусом в виде документации в бесплатной электронной книге.

https://github.com/dotnet-architecture/eShopOnContainers/ - Я не могу не подчеркнуть, как этот репозиторий помог мне в понимании микросервисов. Также есть бесплатная электронная книга от Microsoft docs об этом репо: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/. Они касаются таких понятий, как конечная согласованность и асинхронная коммуникация. Это именно то, что вы ищете.