Каждый программист хочет получать и выполнять сложные и интересные задачи, набираться нового опыта, применять новые инструменты при разработке программного обеспечения.
Рано или поздно разработчику приходится заниматься или принимать участие в создании созданием высоконагруженного продукта: программы, сайта, сервиса, API и тому подобное. Проектирование масштабируемых архитектур является трудоемкой и важной вещью при разработке крупного проекта.
Подходы построения архитектуры приложения
Есть несколько подходов к построению архитектуры проектов: монолитные и сервисные архитектуры.
Монолитная архитектура - представляет собой единый и неделимый программный код. Такая архитектура является сложно масштабируемой, или даже не масштабируемой, не способная выдержать большое количество пользователей. Сложность разработки нового функционала в приложении с такой архитектурой очень высокая. Любая неосторожная ошибка способна вывести работу всего приложения.
Сервисная архитектура - разделяет приложение на отдельные наборы компонентов, которые соединяются и взаимодействуют между собой. Каждый набор компонентов решает свои задачи. Разработка новых функций и поддержка существующих значительно упрощается у сервисной архитектуры.
Подходы разработки высоконагруженных проектов
Разработку высоконагруженных и масштабируемых можно разделить на следующие подходы:
Подход 1. Производится разработка сервисов, которые будут осуществлять взаимосвязь всех компонентов приложения и отдавать по запросу нужные данные. Создание таких сервисов может занимать долгое время, но впоследствии они значительно упростят разработку остальных частей приложения и позволяют ее масштабировать, сосредотачиваясь при этом на разработке бизнес-логики приложения, абстрагируясь от сложной низкоуровневой разработки по масштабированию и обеспечению приложение стабильностью.
Плюсы подхода
- высокая масштабируемость приложения
- быстрая разработка бизнес-логики приложения
- стабильность работы приложения
- разработчики средней квалификации для разработки бизнес-логики приложения
Минусы подхода
- долгая разработка и взаимосвязь всех сервисов
- дорогие разработчики высокой квалификации для разработки и поддержки сервисов
Подход 2. В другом подходе аналогичным способом производится разработка сервисов, но сервисы масштабирования разрабатываются вместе с логикой приложения, не абстрагируясь от нее. Если в первом подходе, для решения вопросов масштабирования одна группа разработчиков создавала сервисы, а вторая группа разработала бизнес-логику приложения, то во втором подходе бизнес-логика разрабатывается вместе с сервисами.
Плюсы подхода
- быстрота разработки, сервисы и бизнес-логика разрабатываются одновременно
- эффективность в разработке приложения
Минусы подхода
- низкая масштабируемость приложения
- дорогие разработчики высокой квалификации для разработки сервисов и бизнес-логики одновременно
Типы масштабирования приложений
Есть несколько типов масштабирования приложений:
- вертикальное
- горизонтальное
- диагональное
- по времени
Вертикальное масштабирование
Вертикальное масштабирование - это масштабирование приложения за счет увеличения мощности серверного оборудования.
Плюсы
- Быстрое масштабирование приложения за счет покупки дополнительного оборудования для сервера: оперативной памяти, дополнительного диска.
Минусы
- Может быть достигнут момент, когда вертикальное масштабирование уже нельзя проводить - нельзя постоянно покупать новое оборудование и устанавливать его для сервера.
- Дорогая стоимость оборудования
Горизонтальное масштабирование
Горизонтальное масштабирование - это масштабирование приложения за счет покупки и подключения дополнительных серверов.
Плюсы
- Очень быстрое масштабирование за счет покупки и подключения новых серверов
Минусы
- Дорогая стоимость серверов
Диагональное масштабирование
Диагональное масштабирование - это масштабирование включает в себя два предыдущих типа: вертикальное и горизонтальное масштабирования.
Масштабирование во времени
Масштабирование во времени - это масштабирование приложения за счет отложенной обработки, которая подгружает лишь необходимую часть данных, а остальную часть данных позволяет отложить для получения позже, по заданному времени.
Структура приложения
При создании приложения нужно позаботиться о ее правильной структуре. Более правильным решением будет разделение приложения на структуру состоящую из 3 компонентов:
- область работы с бизнес-логикой
- область отображения данных
- область получения данных
Иными словами, это: frontend, backend, data storage.
Область работы с бизнес логикой отвечает за действия совершаемые пользователем и события происходящие в ответ на эти действия в приложении.
Область отображения данных отвечает за отображения визуальной информации, различных данных пользователю.
Область получения данных занимается манипуляцией с данными - получением их из базы данных и дальнейшая работа с этими данными.
Спасибо за объяснение простым и понятным языком. Добавил статью в подборки.