Микросервисы REST или AMQP, в каком случае

Я прочитал много статей, касающихся архитектуры микросервисов, и мне было интересно, когда использовать AMQP или REST.

Я читал, что слабая связь между сервисами - это хорошо, и AMQP кажется хорошим выбором в этом случае. Но если мы используем AMQP, это означает, что нам больше не нужны конечные точки REST (но это означает, что мы теряем концепцию HATEOAS).

Но действительно ли REST - хороший способ построить мои сервисы? Потому что я не буду использовать какие-либо конечные точки ... В каком случае один лучше, чем другой?

Когда я должен использовать один или другой?

Отбрасывая REST, вы теряете гораздо больше, чем просто HATEOAS. Если ваши микросервисы общедоступны (и для них будет хорошей идеей быть публичными или, по крайней мере, стремиться к общедоступности в один прекрасный день), использование чего-либо, кроме REST и SOAP, будет проблематичным:

• Некоторые разработчики никогда не использовали AMQP,

• Некоторые использовали AMQP, но часто гораздо лучше знакомы с REST и SOAP,

• Библиотеки AMQP для некоторых языков не особенно просты,

• Ручные эксперименты с сервисом очень ограничены: я могу использовать CURL для выполнения любого запроса к Amazon S3; что я должен установить на свой компьютер, если я хочу играть с вариантом AMQP S3?

• Отладка REST и SOAP проста. Я просто отслеживаю обмены HTTP и анализирую их. Не уверен, какие инструменты я должен использовать для отладки AMQP-обменов.

AMQP великолепен, но он сделан для очень конкретной цели обмена, основанного на событиях. Хотя технически возможно сделать RPC с AMQP, это не является его основной целью.

Асинхронный аспект тоже важен. Иногда это полезно: я не хочу блокировать пользовательский интерфейс приложения при выполнении запросов к серверам. Иногда это только усложняет ситуацию: если мне нужно восстановить резервную копию файла из Amazon S3, потому что локальная была повреждена, а затем восстановить резервную копию, мой пакетный файл обязательно нуждается в CURL, чтобы завершить свою работу, прежде чем продолжить, и синхронная операция (с определенным таймаутом) имеет смысл.

Сохранить REST для основных операций:

• Получение продукта,

• Хранение счета,

и используйте AMQP для задач, где обмен сообщениями имеет смысл:

• Обработка всех счетов за сентябрь и уведомление приложения о готовности отчета к показу (учитывая, что операция обычно занимает от двух до десяти минут),

  ^{Преимущество AMQP здесь заключается в его асинхронном аспекте. HTTP-запрос, ожидающий в течение десяти минут, может вызвать тайм-аут и другие проблемы.}

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

  ^{Преимуществом AMQP здесь является, среди прочего, возможность добавлять подписчиков без изменения приложения, которое отслеживает резервные копии и выдает предупреждение, когда находит поврежденное.}

^{Public Общедоступный веб-сервис не обязательно используется пользователями за пределами компании. В крупных или средних компаниях ваш сервис часто используется другими подразделениями той же компании и имеет те же требования, что и тот, который будет использоваться любой третьей стороной: он должен не доверять любому звонку (тот факт, что какой-то парень вы никогда слышать о том, кто звонит на ваш сервис, работает в той же компании, что и вы, не значит, что он не будет использовать ее проблемы безопасности), это должно быть должным образом задокументировано (потому что тот же самый индийский парень не обязательно знает ваш номер телефона и не обязательно знаю английский) и т. д.}

Используйте оба.

Веб-сервисы JSON в стиле REST отлично подходят для взаимодействия с javascript, ios и т. Д.

AMQP отлично подходит для длительных процессов, событий и оркестровки микросервисов.

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

AMPQ может хорошо работать через веб-сокеты, которые могут выглядеть как конечная точка REST, если вы щуритесь на нее.

REST - это стандартная технология, которая особенно подходит для взаимодействия между компонентами - это ключевая часть, она отлично подходит для создания веб-службы, которую может использовать кто-то другой. Тем не менее, он страдает от обычных проблем такой совместимости в том, что он менее эффективен, чем пользовательский протокол.

Если вы пишете серверную архитектуру, в которой сервисы используются только вами, вы можете использовать любой протокол, который вам нравится, - вы больше не ограничены тем, что он так совместим. Вы можете использовать MQ или что-то более тесно связанное и производительное. Какой из них вы используете, зависит от вашего варианта использования, шина сообщений очень хороша для распределенного набора сервисов, которые обрабатывают данные, когда клиенту все равно, кто получает отправляемые им сообщения.

AMQP также поддерживает двухточечное взаимодействие (например, см. python-qpid-protonУчебное пособие). Вы можете реализовать интерфейс RESTful, используя это, начиная с REST !=HTTP.

AMQP также работает намного лучше, чем HTTP.