3 шаблона архитектурного проектирования для разработки программного обеспечения

Согласно Википедии,

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

Давайте рассмотрим несколько общих архитектурных шаблонов,

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

В монолитной архитектуре вся программа представляет собой один большой исполняемый модуль. Иногда указывается сотнями тысяч строк исходного кода. Хорошо структурированный монолит может обеспечить необходимую эффективность за счет очень медленного и болезненного развертывания.

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

Архитектура микроядра (плагина)

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

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

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

Архитектуры на основе сообщений

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

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

В другой модели архитектуры на основе сообщений, которая называется моделью pub/sub,

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

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

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

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

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

В предыдущей главе, в которой обсуждался оборонный штурм, вы должны были реализовать агенты или объекты, возникшие в результате этого упражнения, в виде отдельных микросервисов. Эти сервисы могут быть распределены по сети, даже по всему Интернету, и в них встроена избыточность. Например, многие экземпляры одной и той же службы могут работать параллельно. Сложите все вместе, и вы получите очень устойчивую систему, которая легко выдержит любую нагрузку, которую вы на нее возлагаете. Микросервисы — это не просто крошечные монолиты. Они должны быть спроектированы таким образом, чтобы поддерживалось распределенное развертывание и сложные взаимодействия в реальном времени.

микросервисы должны быть

• быть независимо развертываемым

• транслируется в несколько сотен строк исходного кода

• написан таким образом, что скрывает все детали реализации

• предназначен для работы в ненадежной сетевой среде

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

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

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

Второй подход — обмен сообщениями вместо HTTP.

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

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

Реактивные и хореографические системы

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

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

Я надеюсь, что эта статья помогла вам узнать о некоторых архитектурных шаблонах, их преимуществах и недостатках. Если вы хотите узнать больше, вы можете следить за работами Грэди Буча, Марка Ричардса, Саймона Брауна и Нила Форда.

Комментируйте, делитесь и дайте мне знать, если вам это нравится, ваше небольшое усилие побуждает меня писать больше.

Также опубликовано здесь