Прокрутить вниз
Категории
//ТОП-5 шаблонов архитектуры программного обеспечения: как сделать правильный выбор

ТОП-5 шаблонов архитектуры программного обеспечения: как сделать правильный выбор

30.10.2018Категория : Без рубрики

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

Многоуровневая (n-ярусная) архитектура

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

Это некое само-выполнимое пророчество. Многие из самых больших и лучших программных платформ, таких как Java EE, Drupal и Express, были построены с учетом этой структуры, поэтому многие из встроенных в них приложений, естественно, выходят из многоуровневой архитектуры.

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

Структура Model-View-Controller (MVC), которая является стандартным подходом к разработке программного обеспечения, предлагаемым большинством популярных веб-платформ, является явно многоуровневой архитектурой. Чуть выше базы данных находится слой модели, который часто содержит бизнес-логику и информацию о типах данных в базе данных. В верхней части находится слой представления, который часто является CSS, JavaScript и HTML с динамическим встроенным кодом. В середине находится контроллер, который имеет различные правила и методы преобразования данных, перемещающихся между представлением и моделью.

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

Это делает её:

Ремонтопригодной
Тестируемой
Легко назначать отдельные “роли”
Легко обновлять и улучшать слои отдельно

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

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

Подводные камни:

Исходный код может превратиться в ”большой шар грязи”, если он неорганизован, и модули не имеют четких ролей или отношений.
Код может закончиться медленно, благодаря тому, что некоторые разработчики называют “воронка анти-шаблона”. Большая часть кода может быть посвящена передаче данных через слои без использования какой-либо логики.
Изоляция слоев, которая является важной целью архитектуры, также может затруднить понимание архитектуры без понимания каждого модуля.
Кодеры могут пропускать прошлые уровни, чтобы создать плотную связь и создать логический беспорядок, полный сложных взаимозависимостей.
Монолитное развертывание часто неизбежно, что означает, что небольшие изменения могут потребовать полного повторного развертывания приложения.

Лучше всего подходит для:

Новые приложения, которые необходимо быстро создавать.
Корпоративные или бизнес-приложения, которые должны отражать традиционные ИТ-отделы и процессы.
Команды с неопытными разработчиками, которые еще не разбираются в других архитектурах.
Приложения, требующие строгих стандартов совместимости и тестирования.

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

Многие программы проводят большую часть своего времени в ожидании чего-то. Это особенно верно для компьютеров, которые работают непосредственно с людьми, но это также распространено в таких областях, как сети. Иногда есть данные, которые нуждаются в обработке, а иногда нет.

Управляемая событиями архитектура помогает управлять путем создания центрального блока, который принимает все данные, а затем делегирует их отдельным модулям, обрабатывающим определенный тип. Говорят, что эта передача генерирует “событие” и делегируется коду, назначенному этому типу.

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

В целом, событийная архитектура:

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

Подводные камни:

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

Лучше всего подходит для:

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

Архитектура микроядра

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

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

Дополнительные функции, которые накладываются сверху, часто называются подключаемыми модулями. Многие называют этот расширяемый подход архитектурой подключаемых модулей.

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

Подводные камни:

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

Лучше всего подходит для:

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

Архитектура микросервисов

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

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

Подводные камни:

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

Лучше всего подходит для:

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

Архитектура на основе пространства (Космическая архитектура)

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

Архитектура на основе пространства предназначена для предотвращения функционального коллапса при высокой нагрузке путем разделения обработки и хранения между несколькими серверами. Данные распределены по узлам так же, как ответственность за обслуживание вызовов. Некоторые архитекторы используют более аморфный термин “облачная архитектура”. Имя “космическая архитектура” относится к “пространству записи” пользователей, которое разрезается для разделения работы между узлами.

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

Подводные камни:

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

Лучше всего подходит для:

Большие объемы данных, такие как потоки кликов и журналы пользователей.
Низкая стоимость данных, которые могут быть потеряны, иногда без больших последствий—другими словами, не банковские операции.
Социальные сети.

Это большая пятерка шаблонов архитектуры ПО Ричардса. Они могут быть как раз тем, что вам нужно. А если нет, то правильным решением может быть смесь двух. Или, может быть, даже трех.

  • 45 просмотров
  • 1 Comment
1 thought on “ТОП-5 шаблонов архитектуры программного обеспечения: как сделать правильный выбор
  • Автор комментария

    Привет! Это комментарий.
    Чтобы начать модерировать, редактировать и удалять комментарии, перейдите на экран «Комментарии» в консоли.
    Аватары авторов комментариев загружаются с сервиса Gravatar.

Leave a Reply

Your email address will not be published. Required fields are marked *

Close