http://hawkhouse.ru/wp-includes/images/media/default.png		

Чем стандартная архитектура отличается от архитектуры высоконагруженных приложений?

captcha

Что обозначает выражение высоконагруженная система? Давайте попробуем разобраться, что же такое highload.

Так сложилось, что в нашей стране термин «highload» используют в основном в отношении веб-сервисов, то есть многопользовательских интернет-сайтов. Но это только часть высоконагруженных систем, к ним еще относятся и различные управляющие и бизнес-приложения. В чем отличительные особенности системы highload?

Highload – это приложение с высокой нагрузкой, которая возникает ввиду:

  • большого количества одновременных пользователей;
  • большого объема обрабатываемых данных;
  • наличия многочисленных сложных расчетов и вычислений.

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

Высоконагруженное приложение

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

Отличительные особенности высоконагруженных систем

Чтобы понять, чем highload-приложения отличаются от обычных, остановимся подробнее на их особенностях.

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

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

Сложно сделать универсальным все, что связано с доступом к данным. Чтобы система функционировала стабильно, нужно четко понимать, с какой базой данных она будет работать. И использовать при реализации проекта преимущества этой БД, исходя из объемов данных и частоты обращений.

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

  1. Быстрое время отклика. Это важное качество highload-приложений. Общение пользователя с системой происходит через запрос, и ответ на него должен приходить если не мгновенно, то через приемлемое время. Вряд ли вам понравится работать с программой, которая сутки будет производить необходимое вычисление.
  2. Масштабируемость. Как много: людей могут одновременно пользоваться ресурсом; данных способна вместить база до того, как перестанет справляться с нагрузкой? Высоконагруженный проект обязательно должен быть масштабируемым.

Существует два пути масштабирования:

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

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

Масштабирование системы

Разработка высоконагруженного приложения предполагает гибкий подход к масштабированию

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

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

Решение отличное, после его внедрения система начинает справляться быстрее. Но, как и в случае с вертикальным, горизонтальное масштабирование не бесконечно. Как только мы вводим параллельную обработку, получается, что на каждом из серверов, в каждом потоке, свои данные. Они перестают быть синхронными.

С ростом нагрузки и распараллеливания мы получаем многосистентное состояние данных: параллельно два пользователя начинают менять одну и ту же сущность, а так быть не должно. Введение синхронизатора убирает параллельность, но синхронизатор становится сильно загруженным. Лучше обособить те части, которые должны выполняться синхронно, и с ними идти по пути увеличения производительности сервера.

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

  1. Высокая нагрузка на интеграционный слой. Это еще одна особенность высоконагруженных приложений. Чем больше мы его разбиваем на модули и чем больше возрастает нагрузка на них, тем сильнее становится нагрузка и на интеграционный слой.

По сути никому не нужны отдельные модули, нужна качественно работающая система в целом. Если мы «распилим» ее на 2 модуля, то будет одна коммуникация – между первым и вторым модулями. Все достаточно просто и есть выигрыш – 2 модуля могут параллельно выполняться и легко масштабироваться. Если же мы разобьем систему на 3 модуля, между ними будет уже 3 коммуникации, на 4–6 коммуникаций и т. д. С увеличением модульности системы сложность коммуникаций и нагруженность интеграционного слоя растут в геометрической прогрессии.

  1. Эксклюзивность. Из вышесказанного вытекает еще одна особенность высоконагруженного приложения – оно нетривиально и ограничено нагрузкой на интеграционный слой. Проектируя такие приложения, нужно понимать, что нет стандартных решений, которые бы подошли для любой highload-системы, в каждом случае решение эксклюзивно и ориентировано на бизнес-требования.
  2. Дублирование критических узлов. Все особо важные части highload-системы, от которых зависит ее жизнедеятельность, нужно дублировать и в программном плане, и в плане «железа». И при этом они не обязательно должны работать параллельно. Всегда нужно иметь failover-сервер или кластер серверов, которыми можно воспользоваться, если рабочие машины перестанут справляться с нагрузкой.

Архитектура высоконагруженных приложений: особенности проектирования highload

Архитектура – это фундамент приложения. И как в строительстве от прочности фундамента зависит качество дома, так в разработке – успешность и жизнеспособность системы.

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

Стоимость разработки системы мониторинга может занимать до трети всей стоимости создания высоконагруженного приложения. Но без нее сложно построить надежно работающую highload-систему.

Бизнес, к сожалению, не всегда понимает, для чего это нужно. Зачем платить деньги за дополнительный функционал, который не требуется для работы и не приносит прибыль? Возникает вполне оправданное желание сэкономить, но экономить на мониторинге, когда речь идет о highload, – это не лучшая идея.

Система мониторинга

Система мониторинга – обязательная составляющая высоконагруженного приложения

Что будет, если не внедрить систему мониторинга?

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

Можно ли восстановить работоспособность системы без мониторинга?

Это реально, но все зависит от квалификации специалистов. Опытные программисты найдут проблемное место, вопрос в другом: сколько на это уйдет времени и нервов?

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

Если какой-то модуль не справляется, его можно оперативно перенести на сервер помощнее, добавить память, расширить интернет-каналы, выделить места под БД или добавить дополнительные диски в массив. И все это заранее, не допуская краха highload и финансовых потерь для бизнеса.

Можно ли «прикрутить» мониторинг к готовой системе?

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

Преимущества подхода компании HHI к разработке высоконагруженных систем

  • Негибкость позволяет экономить на «железе». Изначально стоимость аппаратной части высоконагруженной системы на порядок выше стоимости обычного приложения. Если раздувать его гибкостью, многократно увеличится количество необходимого оборудования. Жесткость системы решает проблему удорожания ресурсов, и мы делаем все возможное, чтобы сбалансировать работоспособность системы и бюджет капиталовложений.
  • Предлагаем стратегию развития. Зная о проблемах масштабирования и возрастании нагрузки на интеграционный слой, мы заранее прорабатываем наиболее экономичную стратегию долгосрочного развития.

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

Вроде бы ничего плохого в таком подходе нет. Но если сначала потребуется сервер за 0,5 млн, то потом более мощный – за 3 млн, в дальнейшем – за 30 млн, а система все равно не будет справляться. И даже если вы согласитесь платить дальше, то рано или поздно не найдется технического способа решения проблемы.

Итог: вы выкинули кучу денег, а в финале остались без решения и будете вынуждены делать систему с нуля. Именно поэтому стратегию – понимание того, как будет дорабатываться система, – наши специалисты разрабатывают заранее.

  • Используем упрощающие решения. Перед началом работы мы всегда задаем клиенту вопрос: что для него является главным в системе? И на реализацию этого пускаем 95 % ресурсов и сил, оставляя мелочи «за бортом».

Здесь работает правило 95-процентный процентиль. Суть: не стоит стараться решить все проблемы, работать нужно над 95 % функций, а 5 % рассматривать как частные случаи, которые ведут к усложнению и удорожанию системы.

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

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