Масштабирование программного/аппаратного обеспечения для большого количества внешних запросов API?

У нас есть система, которая при наличии пакета запросов делает эквивалентное количество вызовов внешнего стороннего API. Учитывая, что это задача, связанная с вводом-выводом, в настоящее время мы используем кешированный пул потоков размером 20 для обслуживания этих запросов. Помимо вышеперечисленного, это решение:

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

or

Используйте больше машин, используя стандартное/дешевое оборудование (коробки для пиццы).

Количество запросов, которые мы получаем в день, составляет порядка миллионов.

Мы используем Java, поэтому темы здесь относятся к ядру, а не к «зеленым».

Другие моменты/мысли:

  • Hadoop обычно используется для решения проблем такого рода, но это должно быть в режиме реального времени, а не стереотипным автономным интеллектуальным анализом данных.
  • Запросы API занимают в среднем от 200 мс до 2 секунд.
  • Между запросами нет общего состояния
  • Рассматриваемая третья сторона способна обслуживать больше запросов, чем мы можем запустить (поставщик платежей).

java multithreading api scaling
person smonky    schedule 12.09.2011    source источник
comment
У вас есть общее состояние, используемое для обработки запросов? Если да, то как часто он меняется? Каков размер этого общего состояния?   -  person David Gruzman    schedule 12.09.2011
comment
Каковы ограничения на сторонний API? Нет смысла масштабировать стек, если API, который вы вызываете, по-прежнему является узким местом. Можете ли вы кэшировать данные, которые вы получаете от него, или использовать данные от одного обращения к сервису/снабжению многих ваших клиентов одновременно?   -  person Paolo    schedule 13.09.2011
comment
Отредактировал мой оригинальный пост, чтобы ответить на вопросы выше. Вызовы полностью независимы, поэтому нет данных для кэширования.   -  person smonky    schedule 13.09.2011

Ответы (2)


arrow_upward
1
arrow_downward

Для меня не очевидно, что вам вообще нужно больше ресурсов (большие машины или больше машин). Если вы говорите о не более 10 миллионах запросов в день, каждый из которых занимает не более 2 секунд, это означает:

  • ~110 запросов в секунду. Это не так быстро. Запросы особенно велики? Или бывают большие всплески? Вы выполняете тяжелую обработку помимо отправки в сторонний API? Вы до сих пор не дали мне никакой информации, которая заставляет меня поверить, что невозможно запустить весь ваш сервис на одном ядре. (Назовите это тремя наименьшими возможными машинами, если вы хотите иметь избыточность n+2.)
  • в среднем ~220 активных запросов. Опять же, это не проблема для одной машины, даже с (объединенной) моделью потока на запрос. Почему бы вам просто не увеличить размер вашего пула и не закрыть его? Они действительно взрывные? (И действительно ли у вас жесткие требования к задержке/надежности?) Нужен ли им огромный объем оперативной памяти во время работы?

Не могли бы вы дать дополнительную информацию о том, почему, по вашему мнению, вы должны сделать этот выбор?

person Scott Lamb    schedule 13.09.2011

arrow_upward
0
arrow_downward

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

Эта статья о SO может представлять интерес.

person beny23    schedule 13.09.2011