Отдых на базе услуг в бэк-энде

Question

мы создаем онлайн-сообщество с более чем 30M пользователями, которое имеет сервисы RESTful в своем бэкэнде и интерфейс, который их использует. Меня беспокоит: можно ли использовать REST в качестве внутреннего протокола передачи данных, или это значительно снизит производительность по сравнению с двоичным протоколом сериализации Java (зависит от языка)? Какие еще подходы / протоколы можно использовать, чтобы сделать его независимым от языка и максимально быстрым?

Answer 1

Подход REST может быть вполне нормальным, но уровень http может замедлить процесс.Если вы используете REST в бэкэнде, вам следует убедиться, что соединение между вашим бэкэндом и фронтэндом остается открытым и не открывается заново при каждом запросе.

Более подробную информацию о http keep-alive можно найти здесь: http://en.wikipedia.org/wiki/HTTP_persistent_connection

Answer 2

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

Эти два преимущества REST могут привести к значительному преимуществу по сравнению с более традиционными методами сериализации RPC, в зависимости от ситуации, особенно если у вас есть "медленные" внутренние процессы, которые могут извлечь выгоду из кэширования или быть сбалансированными по нагрузке.

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

Answer 3

Это то, что вы должны будете измерить и сравнить, прежде чем принимать решения. Это зависит от того, какая информация передается, как часто и т. Д. Сериализация не может быть узким местом. Но будет хорошей идеей рассмотреть Буферы протокола в этом масштабе.