Назад | Перейти на главную страницу

Лучшие практики для создания масштабируемого веб-приложения на Java

У нас есть это приложение JavaEE WebApp (JSP + Struts + Hibernate + MySQL), которое в настоящее время работает на одном сервере. Из-за роста веб-сайта и проблем с производительностью мы решили кластеризовать проект на некоторых машинах. Веб-сайт должен обрабатывать около 5000 запросов в секунду. После некоторого поиска в Google и чтения материалов я нашел несколько способов сделать это:

Я полагаю, что в вышеупомянутых подходах весь трафик должен проходить через интерфейсный балансировщик нагрузки (Apache, Nginx или HAProxy Server). это делает внешний сервер узким местом, а также SPOF. Это правильно? может ли один интерфейсный сервер выдержать весь трафик большого веб-приложения?

Чтобы решить эту проблему, я придумал своего рода стратегию ручной работы:

Итак, я на правильном пути?

Сообщите мне свое мнение об этих подходах, и если вы думаете о лучшем, пожалуйста, упомяните его здесь.

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

Вам нужен активный / пассивный (Сердцебиение/Кардиостимулятор/IP-отказоустойчивость/DNS-отказоустойчивый) или активный / активный (Циклический перебор DNS/балансировка сетевой нагрузки) интерфейсные серверы.

При активном / пассивном режиме весь ваш трафик будет перенаправлен на один интерфейсный сервер, а второй - в режиме ожидания (горячий резерв). Когда первый выйдет из строя, вы каким-то образом переключитесь на другой сервер (Ether, переназначив IP-адрес или изменив DNS *), чтобы указать на второй сервер.

С активным / активным у вас будет два (или более) постоянно активных сервера, использующих эфир Циклический перебор DNS или Балансировка нагрузки IP / сети чтобы распределить нагрузку (примерно) равномерно между ними. Затем два сервера снова распределяют нагрузку на ваши внутренние серверы.

active / active - это метод, используемый большинством крупных веб-приложений (посмотрите записи DNS на Youtube / Google / Twitter / Wordpress.com / Tumblr, и у них будет несколько IP-адресов для серверов для циклического перебора DNS.

После того, как вы приняли это решение и реализовали его, все, что у вас есть, - это выбор между решениями. Лично я предлагаю NGINX но у каждого свои предпочтения (HAProxy, Кальмар, Чероки, Скорость света, F5 (оборудование), Cisco (оборудование) и бесчисленное множество других).

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

* По возможности следует избегать аварийного переключения на основе DNS, некоторые клиенты будут кэшировать DNS за пределами его TTL, так что это далеко не идеально.

Я не знаю насчет nginx, но вы можете объединить пару балансировщиков нагрузки haproxy в активную / пассивную конфигурацию, чтобы предотвратить превращение haproxy в единую точку отказа.

Есть и коммерческие решения, но они почему-то не получают столько «чернил» при сбоях сервера.