Что нужно знать об архитектуре ПО, или Чем разработка IT-продукта похожа на строительство дома

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

Сложные IT-продукты вроде банковского приложения или корпоративного портала состоят из множества программ. Это похоже на дом, который состоит из компонентов: стены, окна, двери, мебель и техника. При этом внешне дома могут выглядеть одинаково, но внутри у каждого будет разный интерьер в зависимости от желания владельца. Так же и с разработкой ПО. Что будет внутри конечного продукта — зависит от потребностей бизнеса.

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

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

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

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

Архитектурных решений очень много, как и их классификаций. Универсальных шаблонов не существует. Выбор вида архитектуры программного обеспечения зависит от задачи: целей продукта, требований и ресурсов заказчика — временных и материальных.

В статье рассмотрим два основных подхода к проектированию архитектуры компонентов программного обеспечения или системы в целом.

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

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

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

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

Монолитное программное решение относительно просто разрабатывать и тестировать. Но сложно масштабировать и менять. Смена концепции или новые требования заказчика могут привести к тому, что придётся переписать весь код

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

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

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

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

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

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

Вот две рекомендации, о которых стоит помнить на практике:

1. Работа над архитектурным решением должна начинаться с исследования.

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

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

2. Необязательно создавать всю архитектуру программного обеспечения по одному принципу.

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

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

Если пытаться сделать всю архитектуру ПО монолитно или микросервисно, продукт может перестать работать так, как требуется. Тогда придётся заново проектировать решение и переписывать код.