Серверная часть выполняет несколько запросов к облачным сервисам

Question

Я нахожусь в процессе написания веб-приложения, которое использует несколько веб-API.Для одного запроса одного пользователя моему приложению может потребоваться выполнить до 30 HTTP-запросов к другим сайтам.Сайт, на котором размещено веб-приложение, может иметь сотни одновременно работающих пользователей.

Я искал, пытаясь выяснить, какую библиотеку мне следует использовать.Я ищу зрелый проект, в котором есть подробная документация и проверенный код, который будет еще в ближайшие годы.Не уверен, что что-то подобное существует (!)

Пара вопросов:

1. В случае, подобном описанному выше, я должен использовать асинхронный HTTPклиент (без потоков) или обычный (возможно объединенный в пул) HTTP-клиент (с потоками) ?Асинхронность освобождает мое приложение от использования потоков, но делает код более разрозненным - будет ли указанное выше количество запросов слишком сильно загружать мой сервер?(здесь сказано , что асинхронный более масштабируем)

2. Какую библиотеку использовать чаще всего?Это Apache HttpComponenets HttpClient или его asynch couterpart HttpAsynchClient - который находится в Alpha ...)?Как насчет jfarcand AsyncHttpClient ?

---

Хорошо, допустим, я буду использовать потоки.Покопавшись, я понимаю, что порождение потоков внутри сервлета (в моем случае - действие Struts) может быть большим Нет-нет :

связанных вопросов:

Каков рекомендуемый способ порождения потоков из сервлета в Tomcat

Нужна помощь с дизайном веб-приложения Java для выполнения фоновых задач

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

На мой взгляд, это мои варианты:

1. использовать свой собственныйпул потоков (контейнер не управляет моими потоками)
2. использовать WorkManager, например CommonJ (кажется, неактивный продукт)
3. использоватьПланировщик стороннего производителя, такой как Quartz (может быть, излишним ...?)

Буду признателен за любые рекомендации для этого конкретного варианта использования - агрегирование данных по LotSA из различных веб-сервисов (это агрегированиевызывается одним запросом одного пользователя).

Answer 1

Хороший вопрос.Сначала я бы попробовал асинхронное решение, чтобы увидеть, как все работает.Асинхронное решение будет проще всего реализовать.

Если это не сработает, попробуйте более многопоточную модель.

Я бы использовал HttpClient для выполнения ваших запросов.Я много работал с ним и использую его для любой http-работы, которую мне нужно сделать.

Answer 2

Я бы использовал Jetty , а в сервлетах я бы использовал механизм продолжения , чтобы освободить поток в ожидании завершения стороннего веб-запроса. Это обеспечит максимальный параллелизм на вашем сервере, поскольку у вас может быть намного больше приостановленных запросов, чем потоков.

Вы можете использовать либо продолжения, либо асинхронный API сервлета 3.0, конечный результат тот же.

Answer 3

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

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

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

Nutshell : ветвь "сложных" задач для специализированной службы, где вы можете прозрачно обрабатывать параллелизм.

Answer 4

Один поток для каждого удаленного http-соединения и использование синхронного http-клиента, вероятно, будет проще. Я бы сначала попробовал этот подход и посмотрел, достаточно ли он быстр / масштабируем. Для синхронного подхода хорошим выбором будет http-клиент apache.

Если синхронное решение недостаточно хорошо, может подойти что-то вроде netty . Он использует NIO, поэтому вы не получите тысячи потоков.