Сервис-ориентированная архитектура - AMQP или HTTP

Немного фона.

Очень большое монолитное приложение Django. Все компоненты используют одну и ту же базу данных. Нам нужно разделить службы, чтобы мы могли самостоятельно обновлять некоторые части системы, не затрагивая остальных.

Мы используем RabbitMQ в качестве брокера для Сельдерей.

Сейчас у нас есть два варианта:

Услуги HTTP, использующие интерфейс REST.
JSONRPC через AMQP для службы цикла событий

Моя команда склоняется к HTTP, потому что то, с чем они знакомы, но я думаю, что преимущества использования RPC над AMQP намного перевешивают его.

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

В то время как с HTTP мы должны создавать клиентские HTTP-обертки для работы с интерфейсами REST, мы должны установить балансировщик нагрузки и настроить эту инфраструктуру, чтобы иметь HA и т.д.

С AMQP я могу просто создать еще один экземпляр службы, он будет подключаться к той же очереди, что и другие экземпляры, и bam, HA и балансировка нагрузки.

Я что-то пропустил с мыслями о AMQP?

Ответ 1

Сначала

REST, RPC - шаблоны архитектуры, AMQP - протокол проводного уровня и HTTP-приложения, которые работают поверх TCP/IP
AMQP - это конкретный протокол, когда протокол HTTP общего назначения, таким образом, HTTP имеет чертовски высокие накладные расходы по сравнению с AMQP
Характер AMQP является асинхронным, когда природа HTTP является синхронной.
как REST, так и RPC используют сериализацию данных, формат которой зависит от вас, и это зависит от инфраструктуры. Если вы используете python всюду, я думаю, вы можете использовать собственную сериализацию python - pickle, которая должна быть быстрее, чем JSON или любые другие форматы.
как HTTP + REST, так и AMQP + RPC могут работать в гетерогенной и/или распределенной среде

Итак, если вы выбираете, что использовать: HTTP + REST или AMQP + RPC, ответ действительно зависит от сложности инфраструктуры и использования ресурсов. Без каких-либо конкретных требований оба решения будут работать нормально, но я бы предпочел сделать некоторые абстракции, чтобы они могли переключаться между ними прозрачно.

Вы сказали, что ваша команда знакома с HTTP, но не с AMQP. Если время разработки - важное время, вы получили ответ.

Если вы хотите построить инфраструктуру HA с минимальной сложностью, я думаю, что AMQP-протокол - это то, что вы хотите.

У меня был опыт работы с обоими из них, и преимущества сервисов RESTful:

они хорошо отображаются на веб-интерфейсе
люди знакомы с ними
легко отлаживается (из-за общего назначения HTTP)
легко предоставить API сторонним службам.

Преимущества решения на основе AMQP:

чертовски быстро
гибкий
легко поддерживать
легко масштабируется
рентабельным (в смысле использования ресурсов)

Обратите внимание, что вы можете предоставить API RESTful сторонним сервисам поверх вашего API на основе AMQP, в то время как REST не является протоколом, а скорее парадигмой, но вы должны подумать об этом, создав свой AQMP RPC api. Я сделал это таким образом, чтобы предоставить API внешним сторонним службам и предоставить доступ к API в той части инфраструктуры, которая работает на старой базе кода или там, где невозможно добавить поддержку AMQP.

Если я прав, ваш вопрос касается того, как лучше организовать связь между различными частями вашего программного обеспечения, а не как предоставить API конечным пользователям.

Если у вас есть проект с высокой нагрузкой, RabbitMQ - чертовски хороший инструмент, и вы можете легко добавить любое количество рабочих, которые работают на разных машинах. Также он имеет зеркальное отображение и группировку из коробки. И еще одно: RabbitMQ построен поверх Erlang OTP, который является высоконадежной, стабильной платформой... (bla-bla-bla), это хорошо не только для маркетинга, но и для инженеров. У меня была проблема с RabbitMQ только один раз, когда журналы nginx заняли все места на диске в том же разделе, где выполнялся RabbitMQ.

Ответ 2

Ирония решения OP должна была принять, AMQP или другие решения MQ часто используются, чтобы изолировать вызывающих абонентов от присущей ненадежности услуг HTTP-only - обеспечить некоторый уровень тайм-аута и повторить логику и постоянство сообщений, вызывающему абоненту не нужно реализовывать свой собственный код изоляции HTTP. Очень тонкий HTTP-шлюз или адаптерный слой над надежным ядром AMQP, с возможностью перейти прямо в AMQP с использованием более надежного клиентского протокола, такого как JSONRPC, часто будет лучшим решением для этого сценария.