Использование архитектурных шаблонов реферат

Обновлено: 17.06.2024

Содержание
Введение . 3
Глава 1. Технологическая архитектура, структуры и шаблоны . 4
1.1 Адаптивная технологическая инфраструктура . 13
1.2 Роль стандартов. 17
1.3 Использование архитектурных шаблонов . 20
Глава 2. Оценка состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии . 40
Заключение. 43
Список литературы . 44

Введение
Эта область архитектуры предприятия рассматривает "традиционные" аспекты построения информационных систем, которые необходимы для поддержки прикладных систем и информационных ресурсов организации. Для технологической архитектуры иногда используютсятакие термины, как "платформы", "инфраструктура", "системная архитектура" или просто "ИТ-архитектура".
Цель курсовой работы состоит в рассмотрение контекста и основных элементов технологической архитектуры, адаптивной системы, роли стандартов и шаблонов, а так же оценки состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии.
Глава 1. Технологическая архитектура,структуры и шаблоны

Технологическая архитектура является как бы фундаментом, основой всего портфеля информационных технологий предприятия. Вторую существенную часть этого портфеля составляют прикладные системы, обеспечивающие выполнение бизнес-процессов (мы обсуждали это в предыдущем разделе, посвященном архитектуре приложений).
Основное назначение технологической архитектуры – этообеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно, как правило, департаментами информационных технологий. Технологическая архитектура определяет набор принципов и стандартов (индустриальных стандартов; стандартов, связанных с продуктами; конфигураций), которые обеспечивают руководства в отношении выбора и использования таких технологий какаппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т.д. Мы уже отмечали раньше, что отдельные аспекты (безопасность, интеграция, иногда разработка) могут быть выделены в отдельные области (домены) архитектуры предприятия взависимости от особенностей организации.
Инфраструктурные сервисы, в основном, стандартизированы в рамках предприятия и используются сразу несколькими прикладными системами, расположенными над уровнем инфраструктурных сервисов и непосредственно обеспечивающих выполнение бизнес-процессов. При наличии необходимой инфраструктуры новые прикладные системы, которые потребуются предприятию для выполненияновых бизнес-процессов или реализации новых стратегий, могут быть созданы достаточно быстро и эффективно. Это является предпосылкой для повышения того, что называется динамичностью и гибкостью предприятия. Одной из частных задач, решаемых в рамках технологической архитектуры, является формирование "списка закупаемых технологий".
По самой своей природе, инвестиции в инфраструктуру ИТ являютсякрупными и долговременными, при этом они не имеют определенной ценности для бизнеса с точки зрения получения конечных результатов. Но ценность инфраструктуры заключается в ее способности быстро и экономически эффективно обеспечить реализацию новых прикладных систем в интересах различных подразделений предприятия, которые и приносят бизнес-пользу. В конечном итоге.

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

Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин " pattern " имеет различные варианты перевода, в том числе "образец", " шаблон " и т.п. В данном случае мы будем использовать русский термин " шаблон ", оставляя кальку " паттерн " для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.

Одним из удачных определений шаблонов является следующее: " Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" [4.34].

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

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

Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия " pattern " принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года [4.35] он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст , воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.

Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения удачности в данной области во многом субъективны, так как зависят от общества, использующего данные постройки. В области информационных технологий такими критериями могут быть полнота выполнения требований, долговечность, эффективность реализации , а также, в соответствии с [4.36], ориентация, прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий, стал язык шаблонов ( Pattern Language ). В соответствии с определением Коупа, он является коллекцией взаимодействующих между собой шаблонов, образующих систему.

В приведенном выше определении шаблона имеется три ключевых словосочетания:

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

В отношении информационных технологий можно сказать, что шаблоны являются логическими моделями технологий: это проектировочные идеи, которые могут быть многократно использованы в рамках предприятия в целом [4.38]. Как правило, эти решения служат, в каком-то смысле, индустриальными стандартами и обычно существуют продолжительное время. Их можно рассматривать как некоторые схемы, которые определяют компоненты решения, т.е. логический уровень проектирования (например, сервер данных или сервер приложений), и которые показывают роли, взаимодействия и связи компонент на этом уровне абстракции.

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

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

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

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

Введение

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

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

Основные понятия и суть метода

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

Стандартное же определение каркаса предполагает, что это — набор взаимосвязанных классов для многократно используемого проектирования определенного класса программного обеспечения [4].

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

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

Смысл применения основанных на шаблонах каркасов в том, что они обеспечивают согласованность всего решения и могут повысить продуктивность. В динамичной среде с их помощью можно сделать решение более расширяемым. Кроме того, каркасы позволяют свести к минимуму объем кода, необходимого для реализации решения, благодаря чему решение легче сопровождать. Что еще важнее — используемые для создания каркасов шаблоны создают в организации разработчиков общий лексикон, в силу чего гораздо легче донести до других суть проекта [5].

Преимущества интеграции с помощью шаблонов

Средства реализации архитектуры

Рассмотрим в качестве примера платформу OSS Apache ServiceMix (лицензия Apache License 2.0), на основе которой создается интеграционное решение инженерных и расчетных систем. Указанное ПО представляет собой пакет формирования композитных приложений, базирующийся на концепции корпоративной сервисной шины (ESB) и комбинирующий сервисориентированную и событийноориентированную архитектуру. Для разработки интеграционной шины мы ограничились следующими его компонентами:

Заключение

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

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

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

Рассказываем о распространенных шаблонах в архитектуре ПО.

Архитектурный шаблон — это обобщенное часто используемое решение распространенной задачи в архитектуре ПО в заданном контексте.

Шаблон — это решение задачи в определенном контексте.

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

Что ж, давайте разбираться!

Каналы и фильтры

Модель — представление — контроллер

Управляемая событиями архитектура

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

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

Популярный пример n-уровневой архитектуры

Контекст

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

Задача

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

Решение

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

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

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

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

Недостатки

Наличие уровней снижает производительность. Этот шаблон не подходит для высокопроизводительных приложений: проходить несколько уровней архитектуры для выполнения бизнес-запроса — это неэффективно.

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

Применение

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

Многоярусный шаблон

Контекст

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

Задача

Как разделить систему на ряд независимых в вычислительном отношении исполнительных структур — групп программного и аппаратного обеспечения, объединенных каким-нибудь средством связи?

Решение

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

Недостатки

Значительные полная стоимость и сложность.

Применение

Используется в распределенных системах.

Каналы и фильтры

Один из часто используемых шаблонов в архитектуре ПО — шаблон каналов и фильтров.

Контекст

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

Задача

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

Решение

В таком подходе выделяют фильтры четырех видов:

генератор (источник) — отправная точка процесса;

преобразователь (сопоставление) — выполняет преобразование некоторых или всех данных;

испытатель (редуцирование) — проверяет один или несколько критериев;

потребитель (приемник) — конечная точка.

Недостатки

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

Чрезмерное использование синтаксического анализа и синтеза снижает производительность и усложняет написание самих фильтров.

Применение

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

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

Клиент — сервер

Контекст

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

Задача

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

Решение

Недостатки

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

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

Применение

Модель — представление — контроллер

Контекст

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

Задача

Как можно отделить функциональность пользовательского интерфейса от функциональности приложения и при этом обеспечить быстрый отклик на действия пользователя и изменения в базовых данных приложения?

Как создавать, поддерживать и координировать несколько представлений пользовательского интерфейса при изменении базовых данных приложения?

Решение

Модель — содержит данные приложения.

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

Контроллер — действует в качестве посредника между моделью и представлением и управляет уведомлениями об изменении состояния.

Недостатки

Для простых пользовательских интерфейсов такая сложность может быть чрезмерной.

Применение

Архитектурный шаблон MVC обычно используется в мобильных и веб-приложениях при разработке пользовательских интерфейсов.

Управляемая событиями архитектура

Контекст

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

Задача

Решение

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

Недостатки

Возможные проблемные области — производительность и восстановление после ошибок.

Применение

Использующее такой подход приложение для электронной коммерции будет работать следующим образом:

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

Контекст

Задача

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

Решение

Недостатки

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

Кроме того, потребуется больше памяти.

Применение

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

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

Мы рассмотрим пять архитектур распределённых систем, их плюсы, минусы и области применения.

Что такое паттерн распределённой системы?

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

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

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

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

Типы паттернов распределённых систем

Большинство паттернов распределённых систем попадает в одну из трёх категорий, в зависимости от функциональности с которой они работают:

1. Разделение ответственности на команды и запросы (CQRS)

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

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

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

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

Область применения

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

2. Двухфазная фиксация (2PC)

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

2PC гарантирует, что одновременно может работать только одна служба, что делает процесс более устойчивым и последовательным, чем CQRS.

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

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

Область применения

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

3. Saga

Saga — это асинхронный паттерн не использующий центр управления. Сервисы здесь сами взаимодействуют между собой. Эта особенность позволяет избавиться от недостатков упомянутых выше паттернов.

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

Эта структура похожа на 2PC тем, что службы циклически запускаются, если кто-то не может выполнить задачу. Тем не менее, Saga не использует центр управления, чтобы лучше управлять потоком и уменьшить количество требуемой обратной связи.

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

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

Область применения

Этот паттерн распределённой системы хорошо подходит для задач, которым требуется масштабируемая беcсерверная архитектура, способная обрабатывать много запросов одновременно. AWS использует подобные решения в AWS Step Functions и AWS Lambda, и других продуктах.

4. Реплицированные сервисы с распределением нагрузки (RLBS)

RLBS — это самый простой и часто используемый шаблон проектирования. На базовом уровне он состоит из нескольких идентичных сервисов, которые общаются с центральным распределителем. Каждый сервис способен выполнять задачи и перезапускать их в случае неудачи. Распределитель получает запросы от конечного пользователя и разделяет их между сервисами, используя round-robin или более сложный алгоритм.

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

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

Стабильная производительность с точки зрения конечного пользователя.
Быстрое восстановление после сбоев.
Высокая масштабируемость через увеличение числа сервисов.
Отличная многопоточность.

Нестабильная производительность, зависящая от алгоритма балансировки.
Управление сервисами требует много ресурсов.

Область применения

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

5. Шардинг

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

Шардинг сервисов обычно используется для создания сервисов с поддержкой состояния, потому что объём состояния часто слишком большой для одного stateless контейнера. Шардинг позволяет масштабировать отдельные элементы под размер состояния.

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

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

Поддержка большого числа сегментов может потребовать много ресурсов.
Непропорциональное использование сегментов может привести к потерям производительности.

Область применения

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

Что дальше?

В статье были рассмотрены лишь несколько паттернов распределённых систем. Вот ещё несколько шаблонов проектирования для изучения:

Читайте также: