4 типа архитектуры программного обеспечения
Детальный обзор существующих подходов
Зачем нужна архитектура ПО
Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).
За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.
Подробно рассмотрим каждую из них.
Многослойная архитектура
Этот подход работает п о принципу разделения ответственностей. ПО разделено на слои, лежащие друг на друге, и каждый из них выполняет определенную обязанность.
Архитектура делит ПО на следующие слои.
Данные и элементы управления проходят через каждый слой в дизайне и передаются от одного к другому. Эта система также повышает уровень абстракции и в некоторой степени даже стабильность ПО.
Преимущества
Недостатки
Многоуровневая архитектура
Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.
Этот подход использует шаблон Request Response для связи между уровнями. В отличие от многослойной архитектуры, он предлагает масштабируемость, которая может быть как горизонтальной (масштабирование сети с помощью высокопроизводительных узлов), так и вертикальной (масштабирование каждого узла путем повышения его производительности).
Одноуровневая система
В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).
Такая система подходит только для небольших однопользовательских приложений.
Двухуровневая система
Эта система состоит из двух физических машин в качестве сервера и клиента. Она обеспечивает изоляцию операций управления данными, обработки данных и операций представления.
Трехуровневая и n-уровневая системы
Такие архитектуры обладают высокой масштабируемостью как по горизонтали, так и по вертикали. Реализация n-уровневой системы, как правило, обходится дороже, но обеспечивает высокую производительность. Поэтому она обычно применяется в крупных и комплексных программных решениях.
Этот подход можно сочетать с современной сервис-ориентированной архитектурой, чтобы создавать сложнейшие модели. Поскольку реализация может оказаться дорогостоящей с точки зрения времени и ресурсов, рекомендуется использовать его для сложных ПО, требующих производительности и масштабируемости.
Сервис-ориентированная архитектура (SOA)
Эта архитектурная модель состоит из компонентов и приложений, которые связываются друг с другом с помощью четко определенных сервисов.
Она состоит из 5 элементов:
Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.
Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.
Как правило, сервисы делятся на два вида.
Типы сервисов
Mикросервисная архитектура
При таком подходе приложение разрабатывается как набор небольших сервисов, каждый из которых работает в собственном процессе и связывается с легковесными механизмами, обычно API для HTTP-ресурса.
Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы), каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.
Состав микросервисов
Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:
Характеристики микросервисов
Микросервисная архитектура должна включать следующие характеристики.
Рекомендуется развивать каждый микросервис отдельно под управлением разных команд. Поскольку передача данных происходит по стандартному протоколу и формату данных, структура одного сервиса не затронет функциональность сопутствующих.
Немного об архитектурах программного обеспечения
Никаких сомнений, что за последнее время мир только укрепил свою зависимость от программного обеспечения. Приложения должны обладать высокой доступностью, качественно выполнять требуемые функции и иметь адекватную стоимость. Эти характеристики, в той или иной степени, определяет архитектура ПО.
В стандарте 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). В этом случае приложение разбивается на множество небольших сервисов, называемых микросервисами. Каждый микросервис включает в себя бизнес-логику и представляет собой совершенно независимый компонент. Сервисы одной системы могут быть написаны на различных языках программирования и общаться друг с другом, используя различные протоколы.
Поскольку каждый микросервис является отдельным проектом, вы можете распределить работу над ними между командами разработчиков, то есть над системой могут одновременно трудиться несколько десятков программистов. Микросервисная архитектура позволяет с легкостью масштабировать приложение – если вам понадобилось внедрить новую функцию (развертывать каждый микросервис можно по отдельности), просто напишите новый сервис, а если какой-то функцией никто не пользуется – отключите сервис.
Подробнее о микросервисных архитектурах вы можете почитать в следующих источниках: здесь, тут и вот тут.
Дополнительные материалы
В рамках этой статьи мы рассмотрели несколько видов архитектур программного обеспечения. Разумеется, здесь не было затронуто множество других паттернов. В качестве дополнительных материалов по теме можете посмотреть следующие ресурсы:
Помимо этого мы рассказываем о работе службы поддержки «облачного» провайдера и теме оптимизации производительности, к обсуждению которой мы планируем вернуться в одном из следующих материалов.
Архитектура ПО: разница между архитектурой и проктированием
Oct 2, 2018 · 6 min read
Определение архитектуры программного обеспечения
Говоря простым языком, архит е ктура программного обеспечения — это процесс превращения таких характеристик программного обеспечения, как: гибкость, масштабируемость, возможность реализации, многократность использования и безопасность — в структурированное решение, которое соответствует как техническим, так и бизнес требованиям. Отсюда возникает следующий вопрос: какие характеристики программного обеспечения могут повлиять на преоктирование архитектуры программного обеспечения? Помимо технических особенностей, также существует множество параметров, которые в основном отвечают требованиям бизнеса или функциональности.
Характеристики архитектуры ПО
Полный список параметров программного обеспечения или так называемых «качественных характеристик» вы найдете здесь.
Архитектурные шаблоны программного обеспечения
Большинство из вас, наверно, уже знакомы с термином « микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.
** Внимание: пожалуйста, не путайте архитектурные стили с шаблонами проектирования, такими как фабричный шаблон проектирования или адаптерами. Я расскажу о них позже.
Бессерверный архитектурный стиль
Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».
Более подробно прочитать о нем вы можете здесь.
Архитектура, управляемая событиями
Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж. Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.
Запомните, что производитель события не знает за каким из событий наблюдает какой из потребителей события. Также и другие потребители не знают, кто из них за каким событием наблюдает. Таким образом, главная идея заключается в расщеплении частей системы.
Если вы хотите узнать больше про архитектуры, управляемые событиями, перейдите по ссылке.
Архитектура микросервисов
За последние несколько лет архитектура микросервисов стала одной из самых популярных. Она создается на основе небольших, независимых модульных сервисов, каждый из которых решает свою проблему или выполняет уникальное задание. Эти модули взаимодействуют через API, запрограммированный на выполнение определённой бизнес цели. А теперь посмотрите на картинку и вы все поймёте.
Проектирование программного обеспечения
Архитектура — это скелет и многоуровневая инфраструктура программного обеспечения, а проектирование ПО — это проектирование на уровне кода, например: чем занят каждый из модулей, разнообразие классов, цели функций, и т.д.
Если вы разработчик, вам необходимо знать принципы SOLID, и понимать, как шаблон проектирования должен решать повседневные проблемы.
Принципы SOLID ( Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles ) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.
Шаблоны проектирования
Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:
Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.
Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();
Итак, вы вызвали эту функцию в 20 разных местах в приложении.
А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();
Теперь вам придется найти и переименовать эту функцию во всем приложении или создать адаптер-класс, как показано далее в примере:
В последнем случае, единственное, что вам придется сделать — изменить одну строку, все остальное приложение продолжит работать как раньше.
Помните, что архитектор программного обеспечения и разработчик программного обеспечения — две разные вещи. Архитекторы программного обеспечения обычно работают с опытным тимлидом, который хорошо знает существующие решения, что помогает ему принимать правильные решения на стадии планирования. Разработчик программного обеспечения должен знать особенности проектирования программного обеспечения и также обладать знаниями об архитектуре приложения, чтобы команде было легче взаимодействовать.
Архитектура программного обеспечения – принципы, методы и стили
Разработка правильной архитектуры для решения проблемы – это скорее искусство, чем наука, потому что это во многом зависит от понимания постановки проблемы, контекста и того, где, по нашему мнению, она будет расширяться дальше. Самое важное в любой архитектуре-это ее адаптивность перед лицом меняющихся требований бизнеса и масштаба. Ниже приведен мой опыт того, как различные архитектурные стили, принципы и методологии объединяются, чтобы сформировать архитектуру, готовую к эволюции.
Что такое плохая архитектура и как ее распознать?
Ради удобства разработки программисты часто пишут плохой код, что в конечном итоге приводит к тому, что мы традиционно называем лашпшекодом, спагетти или говнокодом. Это приводит к функциональному параличу в какой-то момент времени, когда стоимость создания заново дешевле, чем исправление существующего кода. Некоторые из характеристик таковы
Что такое хорошая архитектура и какими свойствами она обладает?
Зачем беспокоиться об архитектуре, принципах, практиках?
Снижение затрат — Хотя изначально скорость разработки будет меньше, но в конечном итоге общая стоимость создания, а затем и технической поддержки будет меньше
Делайте только то, что требуется, — это позволяет нам создавать самые необходимые блоки кода. Важно делать именно то, что требуется для решения задачи, делать это раньше – путь к плохой архитектуре. Этот подход помогает устранить беспорядок, создавая только то, что необходимо, тем самым уменьшая накладные расходы на обслуживание кода.
Оптимизация — Регулярно задумывайтесь о рефакторинге кода. Это позволит содержать большие объемы кода в чистоте и порядке.
Оптимизация производительности — Не делайте оптимизации производительности кода, пока не достигните LRT.
LRT – это концепция, заимствованная из принципов бережливого производства, в которой решения/изменения откладываются до определенного момента времени, после которого стоимость непринятия решения станет дороже, чем принятие решения. Когда требования серые, проектные решения следует отложить до LRT, чтобы к тому времени мы получили достаточно знаний для принятия обоснованных проектных решений.
Адаптивность/Эволюция — Следуя вышесказанному, программное обеспечение всегда следует эволюционной модели, когда оно продолжает адаптироваться к новым требованиям бизнеса и масштаба
Каким инструментам, методологиям и методам мы можем следовать?
Каким архитектурным стилям следовать?
Как правило, никогда не бывает одного подходящего для всех стиля. Проектирование архитектуры для решения проблемы зависят от контекста, и у каждого стиля есть свой компромисс. Ниже приведены некоторые из наиболее часто используемых архитектурных стилей, которые обычно сочетаются друг с другом. Какая комбинация лучше всего подходит для вашего приложения, лучше всего известно именно вам.
Доменно-ориентированная архитектура
Домен находится в центре модели, а все остальное построено вокруг него, уровень приложений, уровень представления, уровень сохраняемости, служба уведомлений, веб-службы и т.д. Т. е. домен имеет важное значение, а все остальное – это просто деталь реализации, которую можно заменить.
Домен здесь представляет ментальную модель пользователей системы. Это наиболее стабильная часть архитектуры, которая редко меняется. За ним следует уровень приложений, который встраивает варианты использования. Эти варианты использования определяют все остальное.
Исходный источник: https://images.app.goo.gl/cW5QmNMxn912DM4D6
Определены 2 такие модели предметной области: шестиугольная и луковичная модели. Суть в том, что каждый из внешних слоев зависит от внутреннего слоя, в то время как внутренний слой не будет знать о внешнем слое.
Исходный Источник: https://images.app.goo.gl/dRgpzwPR9w8u5u4t7
Плюсы
Минусы
Ориентированное на приложение (Многоуровневая архитектура)
Как только граница домена определена, следующим идет уровень приложения. Прикладной уровень становится надежным благодаря применению нижеприведенных SOLID принципов.
Исходный источник: https://images.app.goo.gl/UwBEyStMHaVVJt7u5
Абстракции (ЧТО?) — Приложение должно быть построено таким образом, чтобы оно могло содержать бизнес-логику с использованием абстракций. Он должен сосредоточиться на том, что(?) он хочет делать.
Сегрегация(КАК?) — это сделано, аспект деталей реализации можно подключить с помощью инъекции зависимостей(DI). DI применяется не только для внедрения бизнес-логики с использованием различных шаблонов проектирования, но и конкретно применяется при внедрении элементов инфраструктуры, таких как базы данных, кэш, серверы уведомлений, внешние веб-службы и т.д.
Интерфейсы/Контракты — Такой подход автоматически создает многоуровневую архитектуру с четкими интерфейсами для каждого внешнего элемента. Разделение ответственности в сочетании с тем, что каждый слой владеет одной-единственной ответственностью, уменьшает сцепление. Это, в свою очередь, помогает легко тестируемому коду, который также может быть протестирован с помощью моков (mocks).
Опять же, уровень приложений не зависит ни от каких других деталей реализации и имеет только знания о доменном уровне, от которого он зависит.
Функциональная организация кода (кричащая архитектура)
Архитектура должна кричать о намерениях системы — дядя Боб
Это лучше всего объяснить с помощью чертежа жилого здания о том, как в каждой комнате четко прописаны цели использования.
Для внутреннего уровня — мы можем модулировать код в функциональных сегментах по структуре папок. Код с функциональной связностью сохраняется вместе. Каждый модуль может иметь совокупный корень в качестве единственной точки входа в модуль, и, таким образом, просто взглянув на совокупный корень, мы сможем описать все варианты использования модуля. Таким образом, упрощается функциональное назначение модуля.
Исходный источник: https://levelup.gitconnected.com/let-me-hear-you-screaming-architecture-3adcc02f2ca3
Что касается уровня представления — возможно, вам все еще захочется следовать старому подходу моделей/представлений/контроллеров. Уровень презентации должен быть легким, без какой-либо бизнес-логики. Это помогает в 2-х отношениях. Во-первых, мы устраняем дублирование логики. Во-вторых, такая организация помогает младшим разработчикам пользовательского интерфейса сосредоточиться только на том, чтобы сделать пользовательский интерфейс насыщенным.
Архитектура микросервисов
В прежние времена у нас была единая модель единого домена для представления клиента или продукта в контексте продаж и в контексте поддержки. Например, контакт службы поддержки и клиент отдела продаж были смоделированы как единая модель клиента. По мере того как пространство решения становится больше, чтобы иметь все больше и больше доменов, мы добавляем больше атрибутов, свойств и правил проверки, которые применяются только к одному домену, но которые неверны для другого домена, что приводит к ненужным затратам на сложность такого унифицированного кода.
https://images.app.goo.gl/HHfv3ojn17B5L1dU7
Ограниченный контекст —Это признание определенной контекстуальной области, в которой конкретная терминология модели предметной области является допустимой и имеет смысл.
В новой модели вам не нужно помещать “Контакт” в “Клиента ” в домене поддержки. Но вместо этого используйте правильную терминологию “Контакт” в области поддержки. Когда вы хотите поговорить с доменом продаж, вы преобразуете “Контакт” в объект “Клиент”, используя четко определенные интерфейсы. Это также приводит к высокой функциональной когезии и уменьшает сцепление между различными областями.
Определены микросервисы — они разделяют единый монолит на подсистемы, которые несут единую ответственность как услуга. Они взаимодействуют друг с другом с помощью четко определенных интерфейсов. Они имеют автономное развертывание, имеют собственную независимую базу данных и службы резервного копирования. Каждый микросервис самостоятельно выбирает технологический стек, инструменты, методы, которые наилучшим образом подходят ему. Они масштабируются независимо друг от друга. Команды относительно невелики. Возможно, одна команда заботится об одном или нескольких микросервисах. Каждой команде просто нужно знать предметную область микросервиса, за который они отвечают, а не все в монолите.
Минусы
Архитектура, управляемая событиями (EDA)
Микросервисы теперь могут взаимодействовать друг с другом, используя механизм запроса/ответа, такой как JSON, через вызовы REST или используя управляемую событиями архитектуру с посредником сообщений. Современная архитектура предпочитает EDA, поскольку она позволяет службам более гибко реагировать, сокращать задержки, обеспечивать надежное, отказоустойчивое, гарантированное обслуживание и позволяет лучше масштабироваться.
В EDA есть 3 участника, а именно производитель, который создает запускающее событие, посредник сообщений, который надежно передает сообщение, и потребитель, который может подписаться на конкретное или на все события. Это приводит к “реактивному программированию”, которое реагирует на событие(триггер), поступающее из потока данных, что приводит к более быстрому времени отклика и, следовательно, к низкой задержке.
Для микросервисов, которым требуются ACID свойства транзакций между микросервисами с использованием возможной согласованности, вместо EDA используется шаблон SAGA, в котором используется явный механизм отката для обработки условий ошибок для отката изменений. Это, однако, усложняет конструкцию, поэтому следует использовать с осторожностью.
EDA также породила Event Sourcing в качестве нового механизма хранения данных в БД. Здесь объекты БД никогда не обновляются. Вместо того, чтобы получить текущее состояние объекта, создается путем применения событий в том же порядке, в каком они были получены. Оптимизация производительности достигается в источнике событий путем создания моментальных снимков текущего состояния с фиксированными интервалами.
Шаблон CQRS-Разделение ответственности за командные запросы
Появление микросервиса и EDA также породило шаблон CQRS. Команда-это то, что изменяет состояние базового объекта, и запрос не изменяет объект, а просто возвращает запрошенное подмножество объектов.
Чем это полезно? Несколько примеров
Выше приведено несколько вариантов дизайна высокого уровня и методов, которые часто используются. Опять же, они используются в сочетании с несколькими другими вариантами низкоуровневого проектирования, представляющими собой комбинацию различных шаблонов проектирования, принципов, инструментов и т.д. Все это, объединенное значимым образом, позволяет определить решение, которое является гибким, адаптируемым, расширяемым, ремонтопригодным, тестируемым и, самое главное, простым.