У программного обеспечения, как у зданий, есть свой «фундамент», на котором держатся функции. Как устроена архитектура в разработке — разбираемся в статье.
Что такое архитектура ПО
Архитектура — это каркас будущего приложения. Он включает в себя:
- компоненты: модули, классы или функции, которые используют при написании кода;
- взаимодействие: то, как компоненты «общаются» друг с другом;
- технологии: язык программирования, фреймворки, базы данных и т.д.
Именно правильная архитектура делает приложение понятным и удобным для разработчика.
Архитектура задает вектор развития системы и напрямую влияет на скорость разработки и внедрения новых фич, а также простоту сопровождения. Монолитные решения, например, упрощают старт, но затрудняют частые релизы и изолированное развитие функционала. Перестройка архитектуры на поздних этапах требует значительных ресурсов, поэтому критически важно закладывать правильные архитектурные принципы и траекторию развития системы на ранних стадиях.
Зачем нужна архитектура
Программа без продуманной архитектуры тоже будет работать. Но со временем могут возникнуть трудности.
С правильной архитектурой приложения можно:
- быстро разрабатывать и тестировать ПО;
- избегать дублирования кода;
- внедрять новые фичи;
- быстро восстанавливаться после сбоев;
- легко масштабироваться.
Например, вначале у интернет-магазина может быть каталог и корзина. Потом добавят личный кабинет, систему скидок, пуш-уведомления, мобильное приложение. Без продуманной архитектуры приложение будет напоминать башню из «костылей». А самый простой баг может полностью вывести систему из строя.
Понятие хорошей архитектуры относительно. Задача архитектора — сделать так, чтобы система работала в соответствии с функциональными и прежде всего нефункциональными требованиями: держала нагрузку, легко масштабировалась и дорабатывалась, была отказоустойчива, работала с необходимым SLA. Если возникает необходимость доработать одну функцию, то не требуется переписывать половину кода. А когда нужно исправить дефект, то можно устранить проблему сразу, не разбирая неделями спагетти из кода.
Виды ИТ-архитектуры
Есть разные подходы к построению программ.
Монолитная архитектура
Все функциональные части приложения (интерфейс, бизнес-логика, доступ к данным) находятся в одной кодовой базе. Разрабатывать такие приложения легко, но их трудно масштабировать, т.к. каждое изменение требует полной пересборки кода. Поэтому чаще всего такой подход используют для MVP и небольших проектов.
Микросервисы
Каждый блок системы отвечает за определенную функцию и взаимодействует с другими через API. Такие блоки живут, развиваются и даже «падают» независимо друг от друга. Поэтому микросервисный подход используют для больших проектов.
Главный минус — это цена. Инфраструктура для поддержания микросервисов стоит дороже, а сам сайт может грузиться дольше.
Микросервисы — не панацея, монолит — не всегда зло. С монолита почти всегда хорошо начинать. Когда система разрастается, отдельные части можно выделить в сервисы. Просто нужно изначально закладывать в дизайне возможность разделения на уровне модулей. Переходить от монолита к микросервисам стоит, когда: функционала в едином монолите становится столько, что полный регрессионный тест занимает недопустимое время; появляются конфликты с бизнесом: хочется выпускать новый функционал чаще, но релизный цикл слишком долгий; становится слишком много разработчиков, и коммитить в один репозиторий трудно: растет поток изменений, и возникают сложности с мерджем».
Многослойная архитектура
Делит приложение на несколько слоев. Обычно это:
- слой представления (UI, интерфейсы, мобильные приложения, API);
- бизнес-логика (правила и алгоритмы);
- доступ к данным (взаимодействие с базами).
Понимать и поддерживать такой код проще. При этом каждый слой можно тестировать отдельно.
Event-driven
Это событийно-ориентированная архитектура. Компоненты системы работают независимо и взаимодействуют друг с другом через события. Например, пользователь оформил заказ, и система генерирует событие, а другие компоненты реагируют на него: один отправляет чек, другой — уведомление, третий обновляет склад. При необходимости можно легко добавить новых «потребителей событий».
Serverless
Бессерверная архитектура ПО. Вместо обычных серверов используют облачные сервисы, которые автоматически управляют ресурсами и масштабированием.
При выборе архитектуры важно учитывать внутренние процессы и ограничения: в крупных компаниях часто нельзя выбрать любую понравившуюся технологию или язык, потому что есть общепринятые инструменты. Также нужно учитывать текущий уровень команды и особенности CI/CD — сборку, автотесты, чек-листы, проверки безопасности. Отдельное внимание стоит уделить проектированию модели данных. От того, как данные будут храниться, зависит будущее системы. Лучше заранее «заглянуть вперед», чтобы потом не пришлось переделывать.
Принципы хорошей архитектуры ПО
Хорошая архитектура проекта должна быть:
- Простой: чем меньше лишнего кода, тем проще поддерживать проект.
- Гибкой: допускает изменения, не ломая при этом уже работающие компоненты.
- Ясной: новые разработчики могут легко разобраться, как все устроено.
- Надежной: устойчиво работает даже при сбоях. Отдельные ошибки не приводят к потере данных или «падению» всего приложения.
Можно сказать, что хорошая архитектура — это компромисс между скоростью, качеством, удобством и сложностью. При этом архитектура ПО не делается раз и навсегда, а эволюционирует вместе с проектом.
Я сторонник эволюционной архитектуры. В эпоху Agile и быстрых изменений архитектура тоже должна быть гибкой и уметь подстраиваться. Уже на этапе дизайна нужно предусмотреть изменения. Это не оверинжиниринг, а забота о будущем. Продукт не должен быть жестко привязан к определенным технологиям и инструментам. У меня был опыт, когда мы начинали с небольшой команды из трех разработчиков, а уже через два года у нас было двадцать пять программистов и четыре команды, которые нон-стоп писали код и расширяли функционал. Система выросла в десятки раз. Это стало возможным благодаря тому, что мы параллельно меняли архитектуру.
Ошибки при проектировании архитектуры программного обеспечения
При создании архитектуры приложений программисты часто допускают эти ошибки:
- Оптимизируют архитектуру наперед. В итоге получается сложная система, которая решает несуществующие проблемы.
- Выбирают «модную» архитектуру. Например, внедряют микросервисы там, где подойдет обычный монолит.
- Масштабируют архитектуру без документации. Спустя время никто не понимает, как все работает, и люди боятся трогать код, потому что «все может сломаться».
- Не учитывают будущий рост. Это приводит к проблемам с производительностью. Система тормозит, падает под нагрузкой, ее становится трудно поддерживать.
- Не тестируют архитектуру. Проблемы обнаруживают только на поздних стадиях разработки или уже после развертывания.
Самая опасная ошибка — это оверинжиниринг. Когда пытаются построить звездолет, хотя нужна обычная весельная лодка. Ни к чему хорошему это не приводит. Тратится много ресурсов, времени, денег, а по факту используется лишь 5%. Однажды команда из смежного отдела замахнулась наперед и сразу выбрала микросервисы. При этом использовали Scala, который поддерживает функциональный подход к программированию, и Kafka для “общения” между компонентами. В итоге спустя время микросервисы слили в один, выкинули Kafka, переписали Scala на Java. Все сразу стало работать.
Главное об архитектуре ПО
- Хорошо спроектированная архитектура ПО упрощает разработку, поддержку и масштабирование проекта.
- Чем раньше разработчики задумаются об архитектуре, тем меньше будет техдолга и хаоса в будущем.
- Существуют разные стили архитектуры: монолит, микросервисы, многослойная, event-driven, serverless. Каждый подходит под определенные задачи.
- Архитектура программы должна эволюционировать вместе с продуктом.
- Хорошая архитектура ПО должна быть простой, гибкой и надежной. Не нужно намеренно усложнять ее или оптимизировать наперед.
