Архитектура программного обеспечения
Архитектура программного обеспечения (англ. software architecture ) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders ), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
Обзор
Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best-practices), языков описания и формальная логика были разработаны в течение этого времени. ЕПИ-3-11 супер Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и разграничения полномочий. На сегодняшний день до сих пор нет согласия в отношении четкого определения термина «архитектура программного обеспечения».
Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО все еще является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, какие ключевые цели имеет система, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющих, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию (maintainability), доступность, безопасность, удобство использования, а также другие качества. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения является аргументом в защиту необходимости и целесообразности создания архитектуры ПО еще до этапа разработки ПО.
История
Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.
В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.
Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.
Темы по программной архитектуре
Языки описания архитектуры
Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.
Виды (views)
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
- Функциональный/логический вид
- Вид код/модуль
- Вид разработки (development)/структурный
- Вид параллельности выполнения/процесс/поток
- Физический вид/вид развертывания
- Вид с точки зрения действий пользователя
- Вид с точки зрения данных
Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.
Базовые фреймворки для архитектуры ПО (software architecture frameworks)
Существуют следующие фреймворки, относящихся к области архитектуры ПО:
- 4+1
- RM-ODP (Reference Model of Open Distributed Processing)
- Service-Oriented Modeling Framework (SOMF)
Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).
Отличие архитектуры ПО от детального проектирования ПО
Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.
Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Детальное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.
Архитектура является проектированием (дизайном), но не всякий дизайн является архитектурным дизайном. На практике, архитектор определяет грань между архитектурой программного обеспечения (архитектурным дизайном) и детальным дизайном (неархитектурным проектированием). Не существует правил или инструкций, как сделать это, которые подходят для любого случая.
Примеры архитектурных стилей и моделей
Есть много распространенных способов разработки программных модулей и их связей, в том числе:
- Blackboard
- Клиент-серверная модель (client-server)
- Архитектуры, построенные вокруг базы данных (database-centric architecture)
- Распределенные вычисления (distributed computing)
- Событийная архитектура (event-driven architecture)
- Front end and back end
- Неявные вызовы (implicit invocations)
- Монолитное приложение (monolithic application)
- Peer-to-peer
- Пайпы и фильтры (pipes and filters)
- Plugin
- Representational State Transfer
- Rule evaluation
- Поиск-ориентированная архитектура
- Сервис-ориентированная архитектура
- Shared nothing architecture
- Software componentry
- Space based architecture
- Структурированная
- Трех-уровневая
Примечания
Ссылки
- Крачтен Ф., Оббинк Х.,Стаффорд Д. Ретроспектива программных архитектур на сайте http://www.osp.ru
- Software Architecture:Glossary, Software Engineering Institute (англ.)
- Architecture: Publications, Software Engineering Institute (англ.)
Что такое архитектура в программировании
Архитектура программного обеспечения — это очень простая концепция, интуитивно понятная большинству инженеров даже с небольшим опытом работы. В то же время довольно сложно дать формальное определение этой концепции. В частности, сложно провести четкую границу между проектом и архитектурой, поскольку архитектура представляет собой один из аспектов проекта, в котором внимание уделяется строго определенным вещам.
В книге An Introduction to Software Architecture Дейвид Гарлан (David Garlan) и Мэри Шоу (Mary Shaw) пишут, что архитектура — это особый уровень проекта: «Помимо создания алгоритмов и структур данных, необходимо решить еще одну принципиальную задачу — разработать общую структуру системы. Процесс разработки структуры включает в себя создание общей инфраструктуры организации системы и управления ею, выбор протоколов и методов синхронизации и доступа к данным, распределение функций системы между компонентами, физическое распределение, объединение элементов проекта, масштабирование, оптимизацию производительности и выбор оптимальных вариантов среди доступных альтернатив». [GAR93]
Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру «концепцией системы высочайшего уровня в своей среде» [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.
В Rational Unified Process (RUP) архитектура системы программы (в данной точке) представляет собой организацию или структуру важных компонентов системы, взаимодействующих посредством интерфейсов, где компоненты состоят из последовательно уменьшающихся компонентов и интерфейсов.
Описание архитектуры
Для обсуждения структуры программы сначала следует определить архитектурное представление, способ описания важных аспектов архитектуры. В RUP это описание фиксируется в Документе по архитектуре программного обеспечения.
Архитектурные представления
Архитектуру программного обеспечения можно проиллюстрировать с помощью нескольких архитектурных представлений. Каждое архитектурное представление связано с некоторым определенным набором вопросов, интересующих участников разработки: пользователей, проектировщиков, менеджеров, технических специалистов, обслуживающий персонал и так далее.
Архитектурные представления охватывают основные решения, принятые при выборе структуры программного обеспечения, и демонстрируют декомпозицию архитектуры на составляющие ее компоненты, соединители и формы [PW92]. Решения, принимаемые при выборе структуры, обусловлены функциональными и дополнительными требованиями, а также другими ограничениями. В свою очередь, эти решения порождают новые ограничения в отношении требований и последующих решений на более низких уровнях.
Типичный набор архитектурных представлений
Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает «значимый для архитектуры» элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется «моделью 4+1» [KRU95]. Модель содержит следующие компоненты:
- Представление вариантов использования, в состав которого входят сценарии и варианты использования, описывающие значимые для архитектуры технические риски, классы и поведение системы. Это подмножество модели вариантов использования.
- Логическое представление содержит важнейшие классы проекта, распределенные по пакетам и подсистемам, которые, в свою очередь, распределены по слоям. Кроме того, это представление содержит некоторые реализации вариантов использования. Данное представление представляет собой подмножество модели проекта.
- Представление реализации содержит общие сведения о модели реализации и ее структуре с точки зрения модулей, пакетов и слоев. В это представление также входит информация о распределении пакетов и классов логического представления по пакетам и модулям представления реализации. Это подмножество модели реализации.
- Представление процессов содержит описание задач (процессов и нитей), их взаимодействия и конфигурации, а также взаимосвязи между классами и объектами проекта и задачами. Это представление применяется только в системах, обладающих значительным параллелизмом. В RUP это подмножество модели проекта.
- Представление развертывания содержит описания физических узлов наиболее распространенных конфигураций платформ и информацию о распределении задач (из представления процессов) между физическими узлами. Это представление применяется только с распределенными системами. Оно представляет собой подмножество модели развертывания.
Подробную информацию об архитектурных представлениях можно найти в документе по архитектуре программного обеспечения. Можно создавать и другие представления, отражающие те или иные аспекты системы: представление интерфейса, представление защиты, представление данных и т.д. В простых системах можно обойтись без некоторых из представлений, входящих в модель 4+1.
Фокус архитектуры
Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:
- Структура модели — организационные шаблоны, например слои.
- Базовые элементы — важнейшие варианты использования, классы, общие механизмы и т.п. (в противоположность всем элементам модели).
- Несколько ключевых сценариев, на которых продемонстрированы основные потоки управления в системе.
- Службы, характеризующие модульность системы, необязательные компоненты и аспекты, относящиеся к линиям продукта.
По сути архитектурные представления представляю собой абстракции, или упрощенные представления, проекта в целом, в которых убраны ненужные детали и подчеркнуты важнейшие характеристики. Эти характеристики приобретают особую важность при обсуждении следующих вопросов:
- Эволюция системы — переход к следующему циклу разработки.
- Повторное использование архитектуры и ее частей в контексте линии продукции.
- Оценка таких характеристик системы, как производительность, коэффициент готовности, переносимость и безопасность.
- Распределение задач разработки между группами разработчиков.
- Решения, касающиеся применения стандартных готовых компонентов.
- Включение системы целиком в систему более широкого профиля.
Шаблоны архитектуры
Шаблоны архитектуры представляют собой готовые формы для решения стандартных архитектурных задач. Среда архитектуры или инфраструктура архитектуры (промежуточное программное обеспечение) — это набор компонентов, на базе которых можно построить определенную архитектуру. Среда (инфраструктура) должна содержать компоненты для решения основных задач архитектуры, обычно в пределах определенной предметной области, например управления.
Примеры шаблонов архитектуры
В [BUS96] шаблоны архитектуры сгруппированы по характеристикам систем, в которых они наиболее часто применяются, при этом одна категория отведена под шаблоны общей структуры. В следующей таблице показаны категории [BUS96] и содержащиеся в них шаблоны.
| Категория | Шаблон |
|---|---|
| Структура | Уровни |
| Конвейеры и фильтры | |
| Классная доска | |
| Распределенные системы | Посредники |
| Интерактивные системы | Модель-представление-контроллер |
| Представление-абстракция-управление | |
| Адаптивные системы | Отражения |
| Микроядра |
Две из этих категорий подробно описаны в данной главе в качестве иллюстрации идей. Подробное описание можно найти в книге [BUS96]. Шаблоны представлены в следующей широко распространенной форме:
- Имя шаблона
- Контекст
- Задача
- Описание различных аспектов задачи, которые следует принять во внимание.
- Обоснование
- Результирующий контекст
- Примеры
Имя шаблона
Контекст
Большая система, нуждающаяся в декомпозиции
Задача
Система должна работать одновременно с несколькими уровнями абстракции. Например, система должна принимать во внимание вопросы управления аппаратным обеспечением, вопросы, связанные с общими службами, и вопросы, относящиеся к конкретным предметным областям. Крайне нежелательно разрабатывать вертикальные компоненты, в которых придется иметь дело со сложностями на всех уровнях сразу. Такой подход потребует многократного решения одних и тех же задач (вероятно, различными способами) в разных компонентах.
- Компоненты системы должны быть взаимозаменяемы.
- Изменение компонентов не должно нарушать стабильность системы в целом.
- Схожие функции должны быть сгруппированы.
- Сложные компоненты могут нуждаться в декомпозиции .
Решение
Структура системы должна представлять собой несколько слоев компонентов. Компоненты верхних слоев должны пользоваться компонентами нижних слоев (но ни в коем случае не наоборот). Не рекомендуется пользоваться компонентами «через слой» (единственный вариант, когда это оправданно — это ситуация, когда искусственно созданные промежуточные слои не несут полезной нагрузки).
Примеры:
1. Общие слои
В многослойной архитектуре элементы проекта (классы, пакеты, подсистемы) могут пользоваться только службами элементов, находящихся на один уровень ниже. Примерами служб могут служить обработка событий, обработка ошибок, обращение к базе данных и т.п. В такой архитектуре механизмы взаимодействия более структурированы, чем вызовы операционной системы, использующиеся на нижнем уровне.
2. Уровни бизнес-системы
На этой диаграмме приведен еще один пример многослойной структуры с вертикальными слоями приложений и горизонтальными слоями инфраструктуры. В данном случае цель заключается в максимальном сокращении длины «трубопровода» и максимальной утилизации общих элементов структуры приложения. В противном случае может получиться так, что разные сотрудники будут решать одну и ту же задачу несколько раз, причем по-разному.
Более подробная информация об этом шаблоне приведена в разделе Рекомендация: многослойные структуры.
Имя шаблона
Доска
Контекст
Предметная область, в котором закрытое (алгоритмическое) решение задачи не существует или неизвестно. Примерами могут служить системы искусственного интеллекта, системы распознавания голоса или системы внешнего наблюдения.
Задача
Различные агенты должны скоординированно решить задачу, с которой не в состоянии справиться ни один из них в отдельности. Результаты работы отдельных агентов должны быть доступны всем остальным агентам, которые принимают решение о том, могут ли они оказать помощь в поиске решения, и в случае положительного ответа публикуют результаты своей работы.
- Последовательность, в которой агенты принимают участие в решении задачи, не фиксирована и может зависеть от стратегии решения задачи.
- Разные агенты могут поставлять входные данные (результаты или частичные решения) в разных форматах и представлениях.
- Агентам неизвестно о существовании других агентов напрямую, однако они могут оценивать вклад других агентов в решение задачи.
Решение
У некоторых агентов знаний есть доступ к общему хранилищу данных, которое называется доской. Доска снабжена интерфейсом для просмотра и изменения ее содержимого. Объект или модуль управления активирует агенты в соответствии с некоторой стратегией. После активации агент анализирует информацию на доске и принимает решение о том, может ли он помочь в решении задачи. Если агент решает, что он может помочь, управляющий объект может предоставить ему право на запись частичного (или конечного) решения на доске.
Пример:
На этой диаграмме показано структурное (или статическое) представление, смоделированное с помощью UML. Это часть параметризуемого кооперирования, для которого фактические параметры устанавливаются в момент создания экземпляра по шаблону.
Архитектурный стиль
Для архитектуры программного продукта или отдельного архитектурного представления можно задать атрибут, который называется архитектурным стилем. Этот атрибут позволяет сократить количество доступных форм и придать архитектуре определенное единообразие. Стиль можно определить с помощью набора шаблонов или путем выбора конкретных компонентов и соединителей. Для отдельно взятых систем элементы стиля можно включить в руководство по архитектурному стилю в форме рабочего продукта рекомендаций по проекту RUP. От стиля напрямую зависят простота понимания и целостность архитектуры.
Архитектурный эскиз
Графическое изображение архитектурного представления называется архитектурным эскизом. Эскизы представлений, описанных выше, составляются из следующих диаграмм языка UML [UML01]:
- Логическое представление. Диаграммы классов, конечные автоматы и диаграммы объектов.
- Представление процессов. Диаграммы классов и объектов (включая нити и процессы задач).
- Представление реализации. Диаграммы компонентов.
- Представление развертывания. Диаграммы развертывания.
- Представления вариантов использования. Диаграммы вариантов использования с вариантами использования, субъектами и обычными классами, а также последовательные диаграммы, иллюстрирующие взаимодействие объектов проекта.
Процесс разработки архитектуры
В RUP архитектура представляет собой результат выполнения потока операций проектирования и анализа. Архитектура пересматривается и уточняется в ходе итерационного выполнения этого потока операций. Поскольку на каждой итерации выполняются интеграция и тестирование, архитектура становится довольно стабильной к моменту поставки продукта. Создание архитектуры — главная задача на этапе уточнения, в конце которого обычно создается контрольная версия архитектуры.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Разработка архитектуры для чайников. Часть 1
Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.
И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же это собственно такое?
Ниже я привёл несколько картинок которые описывают ту или иную архитектуру
И как мы видим все эти картинки абсолютно разные. Так что же всё таки такое архитектура?
Архитектура программного обеспечения относится к фундаментальным структурам программной системы и дисциплине создания таких структур и систем. Каждая структура включает элементы программного обеспечения, отношения между ними, а также свойства как элементов, так и отношений. Архитектура программной системы — это метафора, аналогичная архитектуре здания. Он функционирует как план для системы и проекта разработки, в котором излагаются задачи, которые должны быть выполнены командами разработчиков.
Ну теперь когда мы разобрались с тем что такое архитектура, давайте разберемся, а зачем она собственно то нужна? И на самом деле ответ довольно простой и легко изобразить на следующей картинке.
Чем старше становится проект, тем больше у нас технического долга, даже если функциональность проекта не сильно меняется, то технический долг всё равно накапливается со временем и в какой то критический момент мы уже занимаемся тем, что пытаемся просто исправлять баги, а на новую функциональность времени попросту не хватает.
Ну хорошо, мы разобрались что такое архитектура и зачем она собственно нужна, но как же её собственно строить?
Первое что нужно понимать, это что мы вообще строим. Нужно понять что за проект мы делаем. Это кажется очевидным, но я часто видел в своей практике когда архитектор просто приходит и говорит что давайте сделаем микросервисы, не разобравшись в том, что мы делаем и вообще зачем мы это делаем.
Далее нам нужно понять, а зачем вообще заказчику понадобилась новая архитектура и почему мы должны её продумывать. Так же мы должны ответить на вопрос, а почему была выбрана именно текущая архитектура, и почему мы попали в ситуацию что заказчику нужно её поменять? Какие проблемы мы имеем с текущей архитектурой?
Ну и самое главное, мы должны собрать требования к нашей архитектуре, данные требования могут быть абсолютно разными, вот лишь некоторые из них:
- fault tolerance (reliability) / отказоустойчивость (надёжность)
- speed of development / скорость разработки
- ease deployed / простота деплоя
- scalability by the number of people in the project / масштабируемость по количеству человек в проекте
- scalability in terms of requests per second / масштабируемость по количеству запросов в секунду
- fast entry / exit to resolution / быстрый вход/выход в разработку
- application deployment speed / скорость развертывания приложения
- remove old code / избавиться от старого кода
- complexity of adding new integrations / сложность новых интеграций
- etc. / И т.д.
Например на одном из моих проектов важно была отказоустойчивость, но вот масштабируемость проекта, чтобы на нём могли находиться тысяча человек одновременно — не требовалось. Есть проекты в которых наоборот нужно чтобы миллионы пользователей могли одновременно сидеть, но если у одного из них случались проблемы(например сообщение не отправилось за 5 секунд), то это не критично, отправим его через 10 секунд.
К сожалению не существует золотой пули и идеально архитектуры которая подойдёт для всего, поэтому нам требуется как можно точнее собрать требования под конкретную архитектуру которую нам требуется разработать.
Такс, а теперь давайте ещё раз повторим вопросы на которые нам нужно ответить. Их всего 5:
- Что мы делаем?
- Почему мы имеем текущую архитектуру?
- Почему нам нужна новая архитектура?
- Какие проблемы мы имеем с текущей архитектурой?
- Что хочет наш клиент от новой архитектуры?
Ну а теперь мы можем приступать к разработке нашей новой архитектуры.
ПРИНЦИПЫ ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Текст научной статьи по специальности «Компьютерные и информационные науки»
Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Яровая Екатерина Владимировна
В статье рассмотрим, как правильно реализовать архитектуру программного обеспечения. Обсудим самые популярные паттерны, используемые для построения программного обеспечения. Будут затронуты, какие проблемы могут быть при некорректном подходе реализации архитектуры. Плюсы и минусы использования паттернов микросервесной архитектуры и монолитной, в каких случаях и для каких проектов могут быть использованы эти патерны.In this article we will consider how to implement the software architecture correctly. We will discuss the most popular patterns used to build software. We will touch upon what problems can occur if the architecture is implemented incorrectly. Pluses and minuses of using patterns of microserial architecture and monolithic, in what cases and for what projects these patterns can be used.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Яровая Екатерина Владимировна
СТРАТЕГИЯ МИГРАЦИИ ПРОГРАММНОГО КОДА ИЗ МОНОЛИТНОЙ АРХИТЕКТУРЫ В МИКРОСЕРВИСЫ
ВЫГОДЫ ПЕРЕХОДА ОТ МОНОЛИТНОЙ К МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ ПРИЛОЖЕНИЯ
Проектирование сложного программного обеспечения с использованием микросервисной архитектурыОценка возможности использования микросервисной архитектуры при разработке пользовательских интерфейсов клиент-серверного программного обеспечения
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА ПРИ РАЗРАБОТКЕ ФРОНТЕНД ПРИЛОЖЕНИЙ
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.Текст научной работы на тему «ПРИНЦИПЫ ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ»
Яровая Екатерина Владимировна, магистранта Гродненского государственного университета им Я. Купалы, Беларусь, г. Гродно
ПРИНЦИПЫ ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРОГРАММНОГО
Аннотация: В статье рассмотрим, как правильно реализовать архитектуру программного обеспечения. Обсудим самые популярные паттерны, используемые для построения программного обеспечения. Будут затронуты, какие проблемы могут быть при некорректном подходе реализации архитектуры. Плюсы и минусы использования паттернов микросервесной архитектуры и монолитной, в каких случаях и для каких проектов могут быть использованы эти патерны.
Ключевые слова: архитектурные паттерны, типы архитектур, микросервисная архитектура, монолитная архитектура.
Annotation: In this article we will consider how to implement the software architecture correctly. We will discuss the most popular patterns used to build software. We will touch upon what problems can occur if the architecture is implemented incorrectly. Pluses and minuses of using patterns of microserial architecture and monolithic, in what cases and for what projects these patterns can be used.
Keywords: architectural patterns, types of architectures, microservices architecture, monolithic architecture.
Многие разработчики слышали такое выражение, как архитектура программного обеспечения, может кто-то знает, что есть такая должность как архитектор. Только поймите меня правильно, мы не говорим про архитектора
зданий, если будет упомянуто архитектору без дополнения, это все равно будет архитектор программного обеспечения, для сокращения -архитектор.
Для начала нужно ответить на такой вопрос, что такое Архитектура? Архитектура приложения — это набор методов и шаблонов, дробление бизнес процессов на более мелкие, которые помогают команде разработки создавать хорошо структурированные приложения, также это можно понимать, как перечень неких фундаментальных решений, которые после принятия и согласования с трудом поддаются изменению [3]. В описание Архитектуры входит ряд задач такие как, описание компонентов системы и их взаимодействия между собой, также в задачу архитектора входит определение самых важных классов и функций которые будут составлять основу приложений или обязательны для выполнение задач, определять организацию данных, общение между сервисами, как будут данные храниться, какие механизмы будут запускаться при сбоях или как мы будем обрабатывать исключительные операции, какой уровень безопасности будет, но тут есть исключение, это входит в обязанности архитектора, если нету инженера по безопасности. В обязанности Архитектора также входит оценивание и масштабирование ресурсов, ресурсов в плане серверной части. И последнее, что входит в обязанности архитектора — стратегия и способы развития системы.
После обсуждения, что входит в обязанности архитектора, стоит обсудить, какие архитектурные паттерны существуют. Мы перечислим самые популярные паттерны, на некоторых остановимся, чтобы сильно не растягивать время чтения. И так какие же они бывают: многоуровневая архитектура (Layered), клиент-сервер(СНеП:^е1^ег), ведущий-ведомый (master-slave), канал-фильтр (pipe-filter), посредник (broker), одноранговое соединение (peer-to-peer), шины событий(event-bus), модель-представление-контроллер (MVC), доска объявлений (blackboard), интерпретатор (interpreter) [2; 5]. Например, паттерн ведущий, ведомый, предназначен для снижения нагрузки на сервер, его принцип заключается в том, что есть главная база данных и так называемые ведомые, если вы делаете записи или обновляете данные, вы это делаете в
главной базе, а она передает информацию об измененной записи в ведомые, но если вам надо вычитать данные, это делается с ведомых баз данных, таким образам нагрузка уменьшается, а производительность увеличивается.
Перейдем к типам архитектуры, просьба не путать с паттернами. Файл серверная архитектура, такой тип уже устарел и в современном мире ее уже тяжело найти. Клиент-серверная, по сути весь веб основан на этом типе. Трехслойная архитектура и микросервисная, и еще очень много. Но самые важные — это клиент-серверная и микросервисные архитектуры.
А что считать хорошей архитектурой, как все в мире программирования определение хорошей архитектуры не самое однозначное, она звучит так -хорошая архитектура это та, которая вам говорит для чего предназначено ваше приложение. Она также должна быть эффективна, например, калькулятор считает, а не рисует картинки на экране, гибкость при планирование систему мы не можем привязываться к примеру определенной базе данных. Расширяемость системы, тут все просто, добавление новых функций, не нарушая основную структуру. Масштабируемость процесс — возможность декомпозировать сложные большие бизнес процессы на несколько команд, а потом куски собрать в единое без особых проблем. Переиспользование, придерживание паттернов DRY, или избегать по максимум дублирование кода [4]. Сопровождение, хорошо налаженное логирование мониторинга, простое устранение критических ошибок.
Теперь немного подробней о некоторых самых популярных архитектурных паттернов. Первое что мы обсудим, это клиент-серверная архитектура, у нее тип многоуровневая, суть заключается в том, что есть сервер, который каким-то способам получает данные или запросы, как-то их обрабатывает и возвращает ответ. Сервер может хранить данные или просто валидировать. Если говорить, а вебе как правило они общаются по HTTP протоколу. Трехступенчатая архитектура очень похожа на клиент-серверную, только добавляется база данных, которая дает возможность хранить какие-то данные.
Мы обсудили физическое представление, но есть и логическая так называемая концепция слоев [1]. Чаще всего выделяют 3 основных слоя представления, сюда относится то, что мы показываем пользователю, бизнес-логика, там находятся модели сервиса и третьим слоем являются источники данных, это могут быть веб или базы данных, все что угодно, там же происходит обработка и переработка данных для моделей. Также слои могут увеличивать, дробиться или претерпевать какие-то другие изменения.
Монолитная архитектура представляет собой что-то единое целое: база данных, логика, бизнес процесс, и мы не можем удалить какую-то часть, так как все завязано друг на друге, но есть модульные монолиты, которые можно подключать или отключать. Плюсы монолитов можно отметить: простое развертывание, разработка, весь код лежит рядом, минимум интеграций, производительность, опять же не надо использовать другие сервисы, упрощенное тестирование и отладка, снижение скорости разработки, но это проблема возникает после того, как приложение разрослось до огромных размеров, очень сложное масштабирование, с надежностью тоже могут быть проблемы, из-за одной ошибки все приложение может привести к поломке, недостаточно гибки, развертывание, да это плюс и минус одновременно, большие монолиты могут устанавливаться часами.
Микросервисная архитектура, тут противоположность монолитной архитектуре, каждый сервис выполняет конкретную бизнес задачу. Преимуществами такого подхода является: непрерывное развертывание ускоряет выпуск релизов, независимость развертывания, можно обновлять один модуль, не изменяя всю структуру, гибкость технологий для каждого бизнес процесса, можно выбрать свой язык программирования, высокая надежность так как при ошибке ломается только один модуль, а не все приложение. Из недостатков можно отметить такие как: разрастание процесса разработки, один человек не сможет отследить откуда ошибка и приходиться много коммуницировать с другими командами, расходы на инфраструктуру так как под каждый микросервис требуется свой сервер, отсутствие стандартизации,
каждая команда может использовать свои языки и технологии.
После обсуждения двух доминирующих паттернов архитектуры микросервисы и моналит, что же выбрать? Для этого нужна ответь на пару вопросов. Ожидается ли высокая нагрузка на ваше приложение, и вам не понадобится масштабировать, то монолит прекрасно подойдет. Стартап? Монолит прекрасно подойдет, сократит время разработки и затраты на разработку. Частое обновление процессов, тут будет хорошее решение выбрать микросервисную архитектуру. Резко меняется трафик? Тут надо использовать принцип работы холодного старта если использовать монолитное приложение, но микросервис позволит увеличить количество только тех сервисов, на которые наиболее загружены.
1. Shklar, L. Web Application Architecture: principles, protocols, and practices // 2010.
2. Пьюривал С., Основы разработки веб-приложений // Бестселлеры O’Reilly. 2015.
3. Роберт М., Чистая архитектура. Искусство разработки программного обеспечения // Архитектор ПО. 2018.
4. Сэм Ньюман, Building Microservices: Designing Fine-Grained Systems // Технолог. 2014.
5. Martin Kleppmann, Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems // исследователь. 2017. № 1.