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

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

Подходы построения архитектуры приложения

Есть несколько подходов к построению архитектуры проектов: монолитные и сервисные архитектуры.

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

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

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

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

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

Плюсы подхода

  • высокая масштабируемость приложения
  • быстрая разработка бизнес-логики приложения
  • стабильность работы приложения
  • разработчики средней квалификации для разработки бизнес-логики приложения

Минусы подхода

  • долгая разработка и взаимосвязь всех сервисов
  • дорогие разработчики высокой квалификации для разработки и поддержки сервисов

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

Плюсы подхода

  • быстрота разработки, сервисы и бизнес-логика разрабатываются одновременно
  • эффективность в разработке приложения

Минусы подхода

  • низкая масштабируемость приложения
  • дорогие разработчики высокой квалификации для разработки сервисов и бизнес-логики одновременно

Типы масштабирования приложений

Есть несколько типов масштабирования приложений:

  • вертикальное
  • горизонтальное
  • диагональное
  • по времени

Вертикальное масштабирование

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

Плюсы

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

Минусы

  • Может быть достигнут момент, когда вертикальное масштабирование уже нельзя проводить - нельзя постоянно покупать новое оборудование и устанавливать его для сервера.
  • Дорогая стоимость оборудования

Горизонтальное масштабирование

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

Плюсы

  • Очень быстрое масштабирование за счет покупки и подключения новых серверов

Минусы

  • Дорогая стоимость серверов

Диагональное масштабирование

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

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

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

Структура приложения

При создании приложения нужно позаботиться о ее правильной структуре. Более правильным решением будет разделение приложения на структуру состоящую из 3 компонентов:

  • область работы с бизнес-логикой
  • область отображения данных
  • область получения данных

Иными словами, это: frontend, backend, data storage.

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

Область отображения данных отвечает за отображения визуальной информации, различных данных пользователю.

Область получения данных занимается манипуляцией с данными - получением их из базы данных и дальнейшая работа с этими данными.