Веб-сервис с большим количеством соединений

Question

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

Возможно, сервис может быть распределен по многим внутренним серверам, при этом шлюз балансировки нагрузки выполняет функции управления потоками, поэтому фактическая обработка, выполняемая службой, не приведет к перегружению сервера шлюза. Я подумываю об использовании Amazon EC2, но я также могу использовать множество внутренних серверов, если смогу найти для них хорошее применение. База данных, вероятно, будет MySQL (если у вас нет лучшей идеи).

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

Кроме того, в настоящее время я пытаюсь выбрать между постоянными соединениями или нет, но я, вероятно, буду придерживаться последнего.

Итак, какие-нибудь рекомендации для хорошего, масштабируемого решения?

Answer 1

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

Apache + FastCGI сделает это, но ваш сервис будет CGI-программой. Вам придется писать на C или C ++, что может быть неприятно. Вы можете использовать Apache + mod_wsgi плюс одну из платформ Python; это не так быстро, но это будет очень быстро, и вам не нужно писать много кода.

Glassfish сделает это, и вы сможете писать на Java.

Коммерческий продукт (например, Sun's JCAPS) сделает это.

Существует множество платформ веб-сервисов - изобретать свои собственные не очень хорошая идея.

Редактировать Проблема "MaxClients".

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

Если ваши GET-запросы являются идемпотентными, их можно кэшировать в squid (или каком-либо другом обратном прокси-сервере). Вы можете иметь большое количество из них. Обратите внимание, что использование обратного прокси-сервера не имеет ничего общего с вашим веб-сервисом per se ; однако он имеет отношение к общей пропускной способности.

Answer 2

Я не согласен с тем, что разработка собственного веб-сервера - это «лучшее решение». Используйте тот, который существует. Вам не нужно писать сервер только для развертывания веб-службы.

. .NET и Java EE предлагают способы создания и развертывания веб-сервисов. Вы не говорите, какой язык вы выберете, но вы наверняка можете написать веб-сервис на Java EE и развернуть его на Tomcat, не создавая собственный веб-сервер.

Что касается балансировки нагрузки, F5 - хорошее аппаратное решение, если вы можете себе это позволить.

Answer 3

Amazon EC2 работает хорошо, но не основывайте свои цены на экземплярах по $ 0,10 - они очень слабы. Я рекомендую начинать как минимум с c1.mediums. Мне нравится использовать экземпляры nginx в качестве балансировки нагрузки на m1.small перед экземплярами веб-сервера c1.medium (все приложения, которые я недавно создал, связаны с процессором, а не с памятью).

3 секунды - это долго. Обычно я использую 200-400 мс для повышения производительности. Конечно, это меняется в зависимости от того, насколько чувствительно ваше время и сколько работы необходимо выполнить.

Если на самом деле нужно 3 секунды работы, вы, вероятно, можете получить предварительную обработку данных в бэкэнд-сетке. Тогда вам, вероятно, потребуется меньше веб-серверов, поскольку они в основном возвращают предварительно подготовленные данные.

Если бы я был на твоем месте, я бы создал прототип на любом языке / платформе, на которых мне удобнее всего. Тогда ты сможешь понять, где тебе нужно его взять.

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

Количество случаев, когда вам нужно написать собственный веб-сервер, очень мало. Это не один из них. Есть из чего выбирать. Предполагая, что платформа основана на nix, вы можете использовать Apache, nginx или lighttpd. Существует множество других, но они обычно используются в качестве серверов приложений (tomcat, zope, mongrel и т. Д.) И перед ними находится прокси-сервер apache / nginx / lighttpd / squid.

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

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