Как справиться с нагрузкой в ​​веб-приложении Java с высоким трафиком?

Я предполагаю, что ключевыми элементами, которые я бы рассмотрел, будут:

• Вам нужны серверы приложений с поддержкой кластера?
• Вам нужны аппаратные или программные балансировщики нагрузки?
• Какие параметры вы будете записывать для определения работоспособности сервера?
• Будете ли вы балансировать нагрузку на свои БД?
• Будет ли ваше приложение интенсивным вводом-выводом? Процессор тяжелый? Оба?
• Вы хотите использовать много веб-трафика? Если вы усредняете 5 КБ данных на пользователя, сколько пользователей вы сможете обработать, прежде чем сочтете, что ссылка перенасыщена?
• Масштабирование против масштабирования. Определите, какой из них лучше всего подходит вашему приложению, и используйте его.
• Будет ли много транзакций БД?
• Будете ли вы использовать общее хранилище?

Надеюсь, это поможет.

Масштабируемость очень важна для системы, которая должна справляться с растущим трафиком. И безгражданство очень важно для реализации простой системы масштабирования. Проверьте http://www.playframework.org/, веб-фреймворк без сохранения состояния. Используя playframework с mongodb (через модуль PlayMorphia), вы можете легко реализовать масштабируемое веб-приложение.

Некоторые из моих соображений и лучших практик:

• Используйте принципы SOLID, не все из них применимы для всех проектов, но особенно единая ответственность и принцип открытости/закрытости помогут вам легче расширять/настраивать программное обеспечение в соответствии с меняющимися потребностями и растущим трафиком.
• Сохраняйте редко изменяемые данные конфигурации в базе данных памяти, если требуются изменения, сначала обновите реляционную базу данных и вызовите Restfull API для обновления объектов памяти.
• Определите и разделите логику для ваших больших данных, оценив рост продукта, чтобы быстрее выполнять поисковые запросы. например Если номер мобильного телефона является значением ключа, применяя операцию по модулю для определения идентификатора раздела с учетом реляционных ограничений или ограничений размера одного объекта базы данных в базе данных в памяти.
• Сохраняйте обновления базы данных как минимум в одной и той же строке, сериализуя операции обновления. Если состояние данных обновляется через короткие промежутки времени, держите его в памяти и используйте запланированные задачи для пакетного обновления реляционной базы данных.
• Используйте все возможности доступных библиотек ведения журналов, чтобы регистрировать важные и значимые события, предпочитая асинхронное ведение журналов.
• Выполняйте запись истории через отдельную очередь, используйте пакетные вставки и потребляйте их через запланированные задания.
• Рассмотрите возможность использования асинхронной логики API для более быстрого выполнения, ожидайте, что запрос с идентификатором сеанса или возвратом идентификатора отслеживания будет запрашивать и отправлять ответы, когда выполнение выполняется параллельными заданиями.
• Реализовать логику повторных попыток для неудачных уведомлений на конечные точки потребителя.
• Определить каждую программную подсистему независимой и самодостаточной. Подсистемы должны обмениваться данными и обмениваться данными через API, а не через общую память или дисковое хранилище.