Архитектура в программировании что это

Архитектура в программировании что это

Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру «концепцией системы высочайшего уровня в своей среде» [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.

В Rational Unified Process (RUP) архитектура системы программы (в данной точке) представляет собой организацию или структуру важных компонентов системы, взаимодействующих посредством интерфейсов, где компоненты состоят из последовательно уменьшающихся компонентов и интерфейсов.

Описание архитектуры

Для обсуждения структуры программы сначала следует определить архитектурное представление, способ описания важных аспектов архитектуры. В RUP это описание фиксируется в Документе по архитектуре программного обеспечения.

Архитектурные представления

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

Архитектурные представления охватывают основные решения, принятые при выборе структуры программного обеспечения, и демонстрируют декомпозицию архитектуры на составляющие ее компоненты, соединители и формы [PW92]. Решения, принимаемые при выборе структуры, обусловлены функциональными и дополнительными требованиями, а также другими ограничениями. В свою очередь, эти решения порождают новые ограничения в отношении требований и последующих решений на более низких уровнях.

Типичный набор архитектурных представлений

Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает «значимый для архитектуры» элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется «моделью 4+1» [KRU95]. Модель содержит следующие компоненты:

Подробную информацию об архитектурных представлениях можно найти в документе по архитектуре программного обеспечения. Можно создавать и другие представления, отражающие те или иные аспекты системы: представление интерфейса, представление защиты, представление данных и т.д. В простых системах можно обойтись без некоторых из представлений, входящих в модель 4+1.

Фокус архитектуры

Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:

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

Шаблоны архитектуры

Примеры шаблонов архитектуры

В [BUS96] шаблоны архитектуры сгруппированы по характеристикам систем, в которых они наиболее часто применяются, при этом одна категория отведена под шаблоны общей структуры. В следующей таблице показаны категории [BUS96] и содержащиеся в них шаблоны.

Две из этих категорий подробно описаны в данной главе в качестве иллюстрации идей. Подробное описание можно найти в книге [BUS96]. Шаблоны представлены в следующей широко распространенной форме:

Имя шаблона

Контекст

Большая система, нуждающаяся в декомпозиции

Задача

Система должна работать одновременно с несколькими уровнями абстракции. Например, система должна принимать во внимание вопросы управления аппаратным обеспечением, вопросы, связанные с общими службами, и вопросы, относящиеся к конкретным предметным областям. Крайне нежелательно разрабатывать вертикальные компоненты, в которых придется иметь дело со сложностями на всех уровнях сразу. Такой подход потребует многократного решения одних и тех же задач (вероятно, различными способами) в разных компонентах.

Решение

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

2. Уровни бизнес-системы

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

Более подробная информация об этом шаблоне приведена в разделе Рекомендация: многослойные структуры.

Имя шаблона

Контекст

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

Задача

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

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

Разные агенты могут поставлять входные данные (результаты или частичные решения) в разных форматах и представлениях.

Агентам неизвестно о существовании других агентов напрямую, однако они могут оценивать вклад других агентов в решение задачи.

Решение

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

На этой диаграмме показано структурное (или статическое) представление, смоделированное с помощью UML. Это часть параметризуемого кооперирования, для которого фактические параметры устанавливаются в момент создания экземпляра по шаблону.

Архитектурный стиль

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

Архитектурный эскиз

Графическое изображение архитектурного представления называется архитектурным эскизом. Эскизы представлений, описанных выше, составляются из следующих диаграмм языка UML [UML01]:

Процесс разработки архитектуры

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Источник

Немного об архитектурах программного обеспечения

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

В стандарте IEEE 1471 дается следующее определение: «Архитектура – это базовая организация системы, которая описывает связи между компонентами этой системы (и внешней средой), а также определяет принципы её проектирования и развития». Однако многие другие определения архитектуры признают не только структурные элементы, но и их композиции, а также интерфейсы и другие соединительные звенья.

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

«Каналы и фильтры» (Pipes and Filters)

Рисунок 1 – Pipes and Filters

Этот вид архитектуры подходит в том случае, если процесс работы приложения распадается на несколько шагов, которые могут выполнятся отдельными обработчиками. Основными компонентами являются «фильтр» (filter) и «канал» (pipe). Иногда дополнительно выделяют «источник данных» (data source) и «потребитель данных» (data sink).

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

К примеру, один из фильтров может реализовывать шифр Цезаря – шифр подстановки, в котором каждый символ в тексте заменяется символом, находящимся на некотором постоянном числе позиций левее или правее в алфавите. Одна из вариаций кода Цезаря – это ROT13, имеющая шаг равный 13.

Рисунок 2 – Принцип ROT13

Его достаточно просто реализовать с помощью стандартной терминальной утилиты Unix tr:

А вот код на Python:

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

В качестве примера использования этой архитектуры может служить оболочка UNIX Shell, одним из дизайнеров которой был Дуглас Макилрой (Douglas McIlroy). Другим примером может стать архитектура компилятора, если рассматривать её как последовательность фильтров: лексера, парсера, семантического анализатора и генератора кода.

Дополнительную информацию по этому типу архитектуры можно найти здесь и здесь.

Многоуровневая архитектура

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

Рисунок 2 – Многоуровневая архитектура

Слою не обязательно знать, что делают его соседи. Здесь проявляется такое свойство как разделение ответственности. Если все три слоя являются закрытыми, то запрос пользователя к верхнему уровню инициирует цепочку обращений с верхнего уровня до самого нижнего. В этом случае уровень представления отвечает за пользовательский интерфейс и отображение данных для пользователя и ничего не знает о существовании физического хранилища данных. Ничего о существовании базы данных не знает и уровень логики – его «беспокоят» только правила бизнес-логики. Доступ к базе данных имеет лишь через уровень управления данными.

Достоинствами применения такой архитектуры являются простота разработки (в основном из-за того, что этот вид архитектуры всем знаком) и простота тестирования. Среди недостатков можно выделить возможные сложности с производительностью и масштабированием – всему виной необходимость прохождения запросов и данных по всем уровням (опять же, в том случае, если все слои являются закрытыми).

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

Архитектура, управляемая событиями (EDA)

Это популярный адаптивный паттерн, широко используемый для создания масштабируемых систем. Чтобы ознакомиться с принципами событийно-ориентированной архитектуры, можете посмотреть вот это видео от Complexity Academy:

Рисунок 3 – Событийно-ориентированная архитектура

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

Посредник может быть реализован несколькими способами. Самый просто способ – это воспользоваться фреймворками для интеграции Apache Camel, Spring Integration или Mule ESB. Для больших приложений, которым требуется более сложные функции управления, вы можете реализовать посредника, используя концепцию управления бизнес-процессами (например движок jBPL).

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

Подробнее о событийно-ориентированной архитектуре можно почитать здесь.

Микроядерная архитектура

Паттерн состоит из двух компонентов: основной системы (ядра) и плагинов. Ядро содержит минимум бизнес-логики, но руководит загрузкой, выгрузкой и запуском необходимых плагинов. Таким образом, плагины оказываются несвязанными друг с другом.

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

Возможно самым лучшим примером микроядерной архитектуры будет Eclipse IDE. Скачивая Eclipse без надстроек, вы получаете совершенно пустой редактор. Однако с добавлением плагинов пустой редактор начнет превращаться в полезный и легко настраиваемый продукт. Еще один хороший пример – это браузер: дополнительные плагины позволяют расширить его функциональность.

Подробнее о микроядерной архитектуре можно узнать здесь и здесь.

Микросервисная архитектура

Этот тип архитектуры позволяет масштабировать приложения по оси Y «Куба масштабирования» (Scale Cube), описанного в книге «The Art of Scalability» Мартина Эбботта (Martin L. Abbott) и Майкла Фишера (Michael T. Fisher). В этом случае приложение разбивается на множество небольших сервисов, называемых микросервисами. Каждый микросервис включает в себя бизнес-логику и представляет собой совершенно независимый компонент. Сервисы одной системы могут быть написаны на различных языках программирования и общаться друг с другом, используя различные протоколы.

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

Подробнее о микросервисных архитектурах вы можете почитать в следующих источниках: здесь, тут и вот тут.

Дополнительные материалы

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

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

Источник

Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера

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

Типы архитектур ПО

Многоуровневая архитектура

Это одна из самых распространенных архитектур. На её основе построено множество крупных фреймворков — Java EE, Drupal, Express. Пожалуй, самый известный пример этой архитектуры — это сетевая модель OSI.

Система делится на уровни, каждый из которых взаимодействует лишь с двумя соседними. Поэтому запросы к БД, которая обычно располагается в самом конце цепочки взаимодействия, проходят последовательно сквозь каждый «слой».

Архитектура не подразумевает какое-то обязательное количество уровней — их может быть три, четыре, пять и больше. Чаще всего используют трехзвенные системы: с уровнем представления (клиентом), уровнем логики и уровнем данных.

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

Каждый уровень этой архитектуры выполняет строго ограниченный набор функций (которые не повторяются от слоя к слою) и не знает о том, как устроены остальные уровни. Поэтому «содержимое» уровней можно изменять без риска глобальных конфликтов между слоями.

В целом многоуровневые приложения настолько распространены, что для их разработки создаются специальные генераторы шаблонов. Например, LASG для Visual Studio предлагает несколько методов генерации кода, которые автоматизируют рутинные задачи и помогают выстраивать уровни приложения.

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

Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.

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

Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).

Подобная взаимосвязь, между структурой организации и подходами к разработке приложений также продиктована законом Конвея, сформулированном еще в 1967 году. Он гласит: «Разрабатывая какую-либо систему, организации вынуждены придерживаться схемы, которая бы повторяла структуру коммуникаций внутри компании».

Событийно-ориентированная архитектура

В этом случае разработчик прописывает для программы поведение (реакции) при возникновении каких-либо событий. Событием в системе считается существенное изменение её состояния.

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

Система, управляемая событиями, обычно содержит два компонента: источники событий (агенты) и их потребители (стоки). Типов событий обычно тоже два: инициализирующее событие и событие, на которое реагируют потребители.

Примером реализации такой архитектуры может служить библиотека Java Swing. Если классу нужно оповещение о каком-либо событии, разработчик реализует так называемого слушателя — ActionListener (он «ловит» соответствующий эвент), и дописывает его к объекту, который это событие может сгенерировать.

На Wiki приводится следующий код реализации этого механизма:

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

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

Микроядерная архитектура

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

Как пример микроядерной архитектуры в книге O’Reilly приводится Eclipse IDE. Это простой редактор, который открывает файлы, дает их править и запускает фоновые процессы. Но с добавлением плагинов (например, компилятора Java) его функциональность расширяется.

Микроядерную архитектуру в свое время использовала операционная система Symbian для мобильных устройств (разработку прекратили в 2012 году). В её микроядре находился планировщик задач, системы управления памятью и драйверы, а файловая система и компоненты, отвечающие за телефонную связь, выступали в роли плагинов.

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

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

Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.

Хорошо подходит для:

Микросервисы

Похожи на архитектуру, управляемую событиями, и микроядро. Но используются тогда, когда отдельные задачи приложения можно легко разделить на небольшие функции — независимые сервисы. Эти сервисы могут быть написаны на разных языках программирования, поскольку общаются друг с другом при помощи REST API (например, с использованием JSON или Thrift).

В каких пропорциях делить код, решает разработчик, но Сэм Ньюмен (Sam Newman), автор книги «Создание микросервисов», рекомендует выделять на микросервис столько строк кода, сколько команда сможет воспроизвести за две недели. По его словам, это позволит избежать излишнего «раздувания» архитектуры.

Чаще всего микросервисы запускаются в так называемых контейнерах. Эти контейнеры доступны по сети другим микросервисами и приложениям, а управляет ими всеми система оркестровки: примерами могут быть Kubernetes, Docker Swarm и др.

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

Подробнее о механизмах масштабирования микросервисных систем можно почитать в книге Мартина Эббота (Martin L. Abbott) «Искусство масштабирования» (The Art of Scalability).

Сложно искать ошибки. В отличие от монолитных систем (когда все функции находятся в одном ядре), бывает сложно определить, почему «упал» запрос. За деталями приходится идти в логи «виновного» процесса (если их несколько, то проблема усугубляется).

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

Еще один недостаток — необходимость мириться с концепцией eventual consistency (согласованность в конечном счёте). У микросервисов есть собственные хранилища данных, к которым обращаются другие микросервисы. Информация об изменении этих данных распространяется по системе не мгновенно. Потому возникают ситуации, когда у некоторых микросервисов (пусть и на крайне короткий промежуток времени) оказываются устаревшие данные.

Почему мы в 1cloud переходим на микросервисы

Как мы уже говорили, в основе предоставляемых нами сервисов (частное облако, виртуальные серверы, объектное облачное хранилище и др.) лежит многоуровневая архитектура. Она показала себя с хорошей стороны, но теперь её возможности по масштабированию начали иссякать.

У нас становится все больше партнеров, которые предоставляют свои решения на базе нашей платформы по франшизе. Появляются удаленные площадки и сервисы, которыми становится сложно управлять из единой точки (в частности, наше оборудование находится в нескольких дата-центрах в России, Казахстане и Беларуси).

Чтобы было проще масштабировать существующие функции и внедрять новые фичи, мы в 1cloud переводим всю нашу инфраструктуру на микросервисы.

Мы хотим выделить их в отдельные модули и вместо одной сложной базы данных получить N простых. Таким образом, в новой архитектуре каждой фиче будет соответствовать отдельная БД. Это гораздо удобнее и эффективнее в поддержке и разработке.

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

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

Клиенты из Казахстана и Беларуси (и других стран, где мы откроем представительства) заметят существенное увеличение скорости и отзывчивости интерфейсов, так как панели управления будут размещаться локально.

Что уже сделано

Пока мы реализовали только первый пилот: «Услугу Мониторинг». Остальные сервисы переведем на новые рельсы в конце 2018 — начале 2019 года.

Начать новый переход планируем в начале 2019 года и закончить его в конце следующего года.

Используют в крупных проектах с высокой нагрузкой, которым требуется повышенная безопасность.

Источник