Comments 2
Преимущество асинхронного типа связи в том, что запрос клиента обрабатывается сразу, в то время, как при синхронной модели вся обработка выполняется одновременно. Поэтому синхронный способ взаимодействия лучше не использовать в рамках исходной операции «запрос-ответ».
Статья для статьи?
Как человек, который с этим всем работает, могу сказать, что смысл из статьи вычленить очень сложно, и если он в ней и был когда-то (вероятно в каком-то оригинале), то теперь по большинству покинул её.
Прошу прощения, если я неправ или обижаю автора, но как будто бы написал человек, который не понимает о чём пишет. Попробуйте дать прочитать 1-2 знакомым, фидбэк от них легко позволит сделать текст лучше.
>Следует понимать, что использование синхронного взаимодействие между несколькими микросервисами не лучший вариант — каждый микросервис должен быть автономным и доступным клиенту, даже если другие сервисы отключены или недоступны. Если это не реализовать, архитектура будет неустойчива к сбоям — при недоступности одного сервиса будет недоступно все приложение.
Если одному миеросервису для какого-то действия нужен другой микросервис, то переход от синхронного взаимодействия к асинхронному не избавит от проблемы недоступности второго микросервиса: чтобы выполнить действие, первому микросервису по-прежнему нужен второй.
Кроме этого, мы усложняем код: если нам нужно синхронное взаимодействие, т.е. ответ сразу, а мы лепим какую-нибудь очередь, нам нужно костылях, чтобы через очередь возвращать ответ в этом же запросе.
Более того, вместо того, чтобы пользователю сразу сообщить об ошибке, мол, эта операция сейчас недоступна, попробуй позже мы будем ожидать обработки сообщения из очереди, а брать сообщение некому.
Взаимодействие в архитектуре микросервисов