Ответ 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.