Лабораторная работа 3

Тема: Альтернативная архитектура информационной системы (микросервисы и подобные стили) и её документирование
Части:

• Часть 1 — Альтернативный архитектурный стиль (микросервисы / модульный монолит / сервис-ориентированная архитектура) и сравнение с монолитом

• Часть 2 — Документирование архитектуры и архитектурных решений

Дисциплина: Проектирование архитектуры информационных систем
Продолжительность: 2 пары (3 академических часа)
Форма проведения: индивидуальная работа + публичная защита с обсуждением.

1. Цель лабораторной работы

• Показать студентам, что монолит — это не единственный вариант архитектуры.

• Научить проектировать альтернативную архитектуру (в первую очередь микросервисную, но допускаются и другие стили, если осознанно выбраны).

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

2. Исходные условия

Используются результаты предыдущих лабораторных:

• ЛАБА 1 — контекст ИС, стейкхолдеры, требования, логическая и информационная архитектура.

• ЛАБА 2 — вариант монолитной архитектуры:

  • схема развёртывания;

  • интеграции;

  • внутренняя структура монолита (слои, модули).

Индивидуальность темы сохраняется: у каждого студента — своя ИС (по интересам или из списка популярных ИС с hh.ru, список тем приложен слайдом после лабораторных).

3. Планируемые результаты

Студент должен уметь:

1. Разработать альтернативный архитектурный стиль для своей ИС (например, микросервисы).

2. Сравнить монолит и альтернативу по набору критериев, связанных с требованиями и сценариями качества.

3. Подготовить архитектурный документ по альтернативе (краткое, но структурированное описание).

4. Сформулировать и оформить архитектурные решения (ADR) и их последствия.

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

4. Требования к программным средствам

• текстовый редактор;

• редактор диаграмм (Draw.io / diagrams.net, Lucidchart, PlantUML, Visual Paradigm и т.п.);

• ПО для презентации (PowerPoint, Google Slides, текстовый редактор, скрины и др.).

5. Структура лабораторной работы

ЧАСТЬ 1. Альтернативная архитектура: микросервисы (или аналог) и сравнение с монолитом

Цель части:
Спроектировать архитектуру ИС в альтернативном стиле (по умолчанию — микросервисы) и осмысленно сравнить её с уже спроектированным монолитом.

Рекомендуемое время: ~60 минут.

По умолчанию студент берёт микросервисную архитектуру как альтернативу.
Если у студента есть хорошее обоснование, можно выбрать другой стиль:

• модульный монолит;

• SOA / сервис-ориентированная;

• событийно-ориентированная и т.п.
  Главное — чётко описать стиль и его отличия от монолита.

Задания

1. Выбор альтернативного стиля и его краткое описание.
   В отчёт записать:

   • Название стиля (микросервисы / сервис-ориентированная / модульный монолит и т.п.).

   • 3–5 характерных признаков этого стиля:

     • что такое сервис/микросервис в рамках данной ИС;

     • какие границы ответственности;

     • как сервисы разворачиваются и обновляются;

     • как устроено хранение данных (общая БД или отдельная БД на сервис).

     • паттерны

2. Декомпозиция ИС на сервисы/контейнеры.
   Опираясь на подсистемы из ЛАБЫ 1 и модули монолита из ЛАБЫ 2:

   • определить кандидатов в сервисы, например:
     «Сервис каталог товаров», «Сервис заказов», «Сервис платежей», «Сервис пользователей», «Сервис уведомлений» и т.д.;

   • составить таблицу:

     | Сервис / компонент | Ответственность | Основные операции | Основные данные | Взаимодействие с другими сервисами |

   • ответить себе:

     • какие сервисы можно масштабировать независимо;

     • какие сервисы критичны по отказоустойчивости.

3. Построить архитектурную диаграмму альтернативы (уровень контейнеров / сервисов).
   Использовать C4 (Container) или UML Component Diagram, где:

   • показаны отдельные сервисы;

   • для каждого сервиса — своя БД либо общая БД с разделением схем (как вы считаете правильным для вашей ИС);

   • присутствует точка входа (API Gateway / фронтенд);

   • показаны основные связи между сервисами и внешними системами.

4. Сравнительная оценка: монолит vs альтернатива.
   На основе требований и сценариев качества из ЛАБЫ 1 сформировать набор критериев, например:

   • масштабируемость по нагрузке;

   • простота разработки и тестирования;

   • скорость вывода новых фич;

   • сложность развертывания и эксплуатации;

   • надёжность и отказоустойчивость;

   • сложность интеграций;

   • требования к квалификации команды.

   Составить матрицу сравнения, например:

   Критерий	Монолит (оценка/комментарий)	Альтернатива (оценка/комментарий)
   Масштабируемость	…	…
   Скорость внесения изменений	…	…
   Сложность отладки	…	…
   Надёжность / отказоустойчивость	…	…
   и т.д.

   
   
   

1. Можно использовать простую шкалу (1–5), но обязательно добавить краткие комментарии.

2. Вывод и рекомендация по стилю.
   На основе матрицы студент делает обоснованный вывод:

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

   • какой стиль он рекомендует для своей ИС на ближайшие 1–3 года развития;

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

Результаты ЧАСТИ 1 (в отчёт):

• Краткое описание выбранного альтернативного стиля.

• Используемые паттерны

• Таблица сервисов/компонентов и их ответственности.

• Диаграмма архитектуры (микросервисы / сервисы / контейнеры).

• Матрица сравнения «монолит vs альтернатива» с комментариями.

• Краткий текстовый вывод и рекомендация (½–1 страница).

ЧАСТЬ 2. Документирование архитектуры и архитектурных решений

Цель части:
Научиться оформлять архитектуру и ключевые архитектурные решения в виде структурированного документа и архитектурных решений (ADR).

Рекомендуемое время: ~45–60 минут.

Задания

1. Мини-документ архитектуры альтернативного варианта (4–6 страниц текста).
   На основе уже сделанных диаграмм и таблиц подготовить краткий архитектурный документ по альтернативному стилю.
   Рекомендуемая структура:

   1. Введение

      • краткое напоминание о теме ИС;

      • цель документа (описать альтернативную архитектуру).

   2. Контекст и основные драйверы

      • что важно для системы: масштабируемость, быстрые релизы, интеграции и т.п.;

      • почему вообще рассматривалась альтернатива монолиту.

   3. Архитектурный стиль и общая структура

      • описание выбранного стиля (микросервисы/…) и его особенности;

      • общая диаграмма сервисов/контейнеров.

   4. Логический/сервисный разрез

      • короткое описание каждого сервиса (по абзацу);

      • таблица сервисов и их ответственности (можно из ЧАСТИ 1).

   5. Интеграции и коммуникации

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

      • как архитектура помогает/мешает выполнению ключевых сценариев.

   6. Сравнение с монолитом и область применимости

      • какие преимущества и недостатки альтернативы по отношению к монолиту;

      • когда стоит переходить на эту архитектуру (по объёму нагрузки, числу команд, темпу изменений).

   7. Риски и ограничения

      • какие новые риски появляются (сложность эксплуатации, распределённые транзакции, наблюдаемость и т.п.).

2. Архитектурные решения (ADR) — не менее 3–5 шт.
   Для ключевых решений подготовить короткие записи ADR (Architecture Decision Record).
   Примерный шаблон для каждой ADR:

   • Название решения:
     (Например, «Переход к микросервисной архитектуре для подсистемы X»)

   • Контекст:
     (какая была исходная ситуация, какие требования / ограничения учитывались)

   • Решение:
     (что именно принято: выбрать стиль, разделить на такие-то сервисы, использовать такие механизмы взаимодействия…)

   • Обоснование:
     (почему это лучше других вариантов для данной ИС, ссылка на матрицу сравнения, требования и т.д.)

   • Последствия (плюсы и минусы):

     • положительные эффекты (масштабируемость, независимые релизы…);

     • отрицательные эффекты (рост сложности, требования к DevOps и т.п.).

   Типичные ADR в рамках работы:

   • выбор альтернативного стиля (микросервисы или иной);

   • выбор схемы разбиения на сервисы;

   • выбор подхода к данным (общая БД vs БД на сервис);

   • выбор способа коммуникации между сервисами (синхронный REST vs асинхронные сообщения).

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

   1. Тема ИС и напоминание о монолите (1 слайд).

   2. Альтернативный стиль (микросервисы/…) — схема и основные идеи (1–2 слайда).

   3. Матрица сравнения монолит vs альтернатива (1 слайд).

   4. Ключевые архитектурные решения (ADR) — 2–3 самых важных (1–2 слайда).

   5. Итоговая рекомендация: какой стиль для вашей ИС сейчас и в будущем (1 слайд).

4. Публичное обсуждение.
   Во время защиты:

   • студент показывает презентацию и 1–2 ключевые диаграммы;

   • объясняет, почему выбран именно такой вариант альтернативы;

   • какие использовались паттерны;

   • группа и преподаватель задают вопросы, обсуждают, где микросервисы (или другой стиль) действительно нужны, а где это «переусложнение».

Результаты ЧАСТИ 2 (в отчёт):

• Мини-документ архитектуры альтернативного варианта (структурированный текст + диаграммы).

• Не менее 3–5 ADR.

• Презентация (файл можно приложить отдельно, в отчёт — краткий конспект слайдов).

6. Структура отчёта по Лабораторной работе 3

1. Титульный лист.

2. Цель работы и краткое описание темы ИС.

3. Часть 1. Альтернативная архитектура

   • описание выбранного архитектурного стиля;

   • таблица сервисов;

   • диаграмма архитектуры;

   • матрица сравнения монолит vs альтернатива;

   • вывод и рекомендация.

4. Часть 2. Документирование

   • мини-документ архитектуры (можно как отдельный раздел или вложение);

   • список ADR (3–5 шт.);

   • краткое описание структуры презентации для защиты.

5. Выводы по работе.

7. Примерные контрольные вопросы

1. Чем микросервисная архитектура принципиально отличается от монолитной?

2. В каких случаях переход к микросервисам оправдан, а в каких — нет?

3. Что такое архитектурное решение (Architectural Decision) и зачем его документировать?

4. Какие плюсы и минусы микросервисной архитектуры вы видите применительно к своей ИС?

5. Какие сложности возникают с данными в микросервисной архитектуре (транзакции, консистентность и т.п.)?

6. Почему важно фиксировать не только само решение, но и контекст и последствия?