Существует множество определений термина "Архитектура ПО", от устаревших и неформальных до слишком абстрактных и претендующих на остроумие. К примеру, можно упомянуть сайт Института Программной Инженерии (SEI) Университета Карнеги-Меллона, в электронной библиотеке которого есть соответствующий документ.
Далее я дам свое определение, чтобы всех окончательно запутать (нет).
Архитектура - набор ключевых решений при проектировании системы, удовлетворяющих следующим критериям:
Абстрактность
Ограниченность
Изменяемость
Имеют критерии качества
Абстрактность
Архитектура (в идеале) абстрактна и не зависит от реализации: протоколов, языков программирования, библиотек и т. д.
Абстракция позволяет сосредоточиться на ключевых аспектах системы, таких как ее структура, поведение и взаимодействие с другими системами, минимизируя детали, которые не являются критическими для понимания или реализации.
Иногда при написании документации (например по модели C4), можно увидеть названия протоколов и форматов файлов на уровнях контейнеров и компонентов. Тут решает только здравый смысл.
В целом, абстрактная архитектура помогает создавать системы, которые легче понимать, изменять и поддерживать в течение всего их жизненного цикла.
Ограниченность
Архитектура ограничена архитектурным стилем.
Это следует из определения архитектурного стиля как набора ограничений, наложенных на архитектуру.
Более строгое определение можно найти в диссертации автора REST и одного из ключевых разработчиков HTTP Роя Филдинга:
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
Архитектурный стиль - это согласованный набор архитектурных ограничений, которые ограничивают роли/особенности архитектурных элементов и разрешенные отношения между этими элементами в любой архитектуре, соответствующей этому стилю.
Приведу пример некой системы, имеющей следующую архитектуру:
Эта архитектура соответствует стилю N-Tier Architecture и ограничена им. Некоторые ограничения:
Слои явно выражены
Каждый слой имеет свой функционал
Верхний слой видит нижний, но не наоборот (на картинке выше левый слой видит правый, а стрелками показано направление данных, поэтому стрелки влево у Cache не должны смущать)
При этом архитектурный стиль не определяет количество слоев и их названия. Эти аспекты определяются конкретной архитектурой, которая подчиняется выбранному стилю. Реализация, согласованная с архитектурой, в свою очередь, будет определять протоколы, языки и алгоритмы.
Изменяемость
Архитектура меняется, "до" и "после".
До. Архитектура предполагает последовательность шагов, по которым она будет реализовываться. Самый очевидный пример - миграция.
Например, у нас есть система в дата-центре, и мы хотим перенести ее в облако. Существуют следующие стратегии миграции:
Rehosting. Перенос без изменений. Если у нас был PostgreSQL, то он переносится на виртуальную машину без изменений.
Replatforming. Перенос с небольшими оптимизациями, предоставляемыми облачным провайдером. База из PostgreSQL мигрируется на managed service (AWS RDS).
Repurchasing. Выкидываем и покупаем другой готовый.
Refactoring / Re-architecting. Переписываем, используя все возможности облака. Старый монолит переписываем на serverless и lambda.
Retire. Избавляемся от старой системы. Остроумно.
Retain. Ничего не делаем. Тоже остроумно.
Часто при переносе в облако сперва мигрирует по rehosting и replatforming, а затем начинают переписывать компонент за компонентом по refactoring и re-architecting.
Архитектура должна включать в себя все эти шаги.
После. Мы должны иметь ответы на вопросы вроде:
Как будет происходить масштабирование? Что поменяется, если нагрузка вырастет на порядок или на два порядка?
Как будет осуществляться добавление нового функционала?
Какие функции, если таковые имеются, будут реализованы в обозримом будущем?
От чего в дальнейшем захотят избавиться?
Имеет критерии качества
Мировой рынок облаков разделяется между тремя компаниями, которые занимают большую его часть. У всех трех компаний есть Well-Architected Framework - набор правил, описывающий принципы и практики разработки приложений:
AWS (Amazon Web Services)
Microsoft Azure
GCP (Google Cloud Platform)
Эти три документа являются отличными примерами критериев качества для архитектуры, процессов и не только.
Относительно архитектуры можно привести несколько примеров:
Проектируйте приложения так, чтобы они легко масштабировались и имели слабые связи друг с другом. Это позволит регулярно обновлять их компоненты. Автоматическое развертывание небольших изменений уменьшает масштаб возможных проблем и позволяет быстро откатить их в случае возникновения проблем. (AWS, Operational excellence - Make frequent, small, reversible changes)
Реализуйте принцип наименьших привилегий и обеспечьте разделение обязанностей для работы с ресурсами. Управляйте идентификацией централизовано и стремитесь к устранению зависимостей от долгосрочных статических учетных данных. (AWS, Security - Implement a strong identity foundation)
Используйте много маленьких серверов вместо одного большого. Это снизит влияние одного сбоя на работу всей системы. Избавьтесь от единой точки отказа. (AWS, Reliability - Scale horizontally to increase aggregate workload availability)
Развертывание в нескольких регионах позволит вам снизить задержки (latency) и улучшить качество обслуживания клиентов при минимальных затратах. (AWS, Performance - Go global in minutes)
Платите только за ресурсы, которые вам нужны, и увеличивайте или уменьшайте их потребление в зависимости от необходимости. (AWS, Cost Optimization - Adopt a consumption model).
Также от архитектуры зависят некоторые практики Well-Architected Framework. Например, частые обновления относятся к DevOps, а не к архитектуре, но они невозможны для некоторых архитектурных решений.
Раскрою эту тему подробней.
Если релизы делаются часто, по несколько раз в день, то обычно система не может быть остановлена во время обновления - она должна обновляться незаметно для пользователя. Этого можно добиться с помощью стратегий обновления (Deployment strategies, AWS Elastic Beanstalk deployment strategies) blue/green, rolling, канареечный деплой и некоторые других. Эти стратегии разворачивают новую версию бесшовно, но требуют обратной совместимости, чтобы и новая и старая версии могли работать одновременно.
Если используется реляционная база данных, и используется она только для хранения, то любая операция, ломающая обратную совместимость, может быть представлена как набор операций, каждая из которых совместимость не ломает, и провести миграцию в несколько этапов. Например, вместо переименовании колонки, можно создать новую, а потом удалить старую.
Если же архитектура подразумевает сложную логику в базе данных, то на бесшовном обновлении можно поставить крест - сохранение обратной совместимости будет дороже изменений, ради которых происходит обновление.
Таким образом, архитектура может влиять на то, как бы будем обновлять, мониторить систему, на ее безопасность и прочее.
Эпилог
Архитектурные решения являются ключевыми при проектировании, разработке и эксплуатации. Они определяют не только структуру и поведение системы, но и влияют на ее масштабируемость, гибкость и безопасность. Взаимосвязь между архитектурой и практиками разработки, такими как DevOps, подчеркивает важность грамотного проектирования и поддержания архитектуры на протяжении всего жизненного цикла.
