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

Тема: Варианты архитектуры ИС: монолит и микросервисы с тонким и толстым клиентом
Части (4 альтернативы):

• Часть 1 — Монолит с тонким клиентом

• Часть 2 — Монолит с толстым клиентом

• Часть 3 — Микросервисная архитектура с тонким клиентом

• Часть 4 — Микросервисная архитектура с толстым клиентом

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

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

Сформировать понимание того, как архитектура клиента (тонкий/толстый) сочетается с:

• монолитной архитектурой на сервере;

• микросервисной архитектурой.

И научить студентов:

• проектировать архитектуру ИС с учётом выбора типа клиента;

• видеть компромиссы между четырьмя вариантами;

• аргументированно рекомендовать подходящий вариант для своей ИС.

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

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

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

• ЛАБА 2 — монолитная архитектура (deployment, интеграции, внутренняя структура).

• ЛАБА 3 — альтернативная архитектура (микросервисы/др.), её документирование и сравнение с монолитом.

Теперь тот же функционал ИС рассматривается в 4-х вариантах:

1. Монолит + тонкий клиент.

2. Монолит + толстый клиент.

3. Микросервисы + тонкий клиент.

4. Микросервисы + толстый клиент.

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

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

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

2. Уметь проектировать клиент–серверное разбиение для своей ИС в каждом из четырёх вариантов.

3. Уметь строить диаграммы уровней контейнеров/компонент с учётом клиента.

4. Сравнивать четыре архитектурные альтернативы по набору критериев.

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

4. Краткие определения (для студентов в методичке)

• Тонкий клиент — минимум логики на клиенте; основная бизнес-логика и обработка данных на сервере. Клиент — в основном UI/отображение и отправка запросов.
  Примеры:

  • классический web-интерфейс, где сервер рендерит HTML;

  • «очень лёгкий» SPA, когда почти всё всё равно решает сервер.

• Толстый клиент — значительная часть прикладной логики и/или обработки данных на клиенте (desktop-приложение, rich web SPA, мобильное приложение), сервер — больше про данные и интеграции.

5. Структура лабораторной работы (4 части)

ЧАСТЬ 1. Монолит с тонким клиентом

Цель: Спроектировать архитектуру ИС, где:

• на сервере — монолит (как в ЛАБЕ 2);

• на клиенте — тонкий клиент (минимум логики, максимум — на сервере).

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

Задания

1. Определить роль тонкого клиента для вашей ИС.
   В текстовой форме (5–7 предложений) ответить:

   • через какой интерфейс пользователь работает (браузер, терминал и т.п.);

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

   • как происходит отображение экранов: сервер рендерит HTML/шаблоны или клиент строит интерфейс?

2. Построить диаграмму “Клиент–сервер” для варианта “Монолит + тонкий клиент”.
   На одном рисунке показать:

   • Клиент (Thin client / Web UI);

   • Сервер приложения (Monolith App Server);

   • БД и другие компоненты монолита (как в ЛАБЕ 2, можно упростить).

   Обозначить:

   • основные типы запросов (HTTP/HTTPS);

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

3. Распределить ответственность между клиентом и сервером.
   Выберите 2–3 ключевых пользовательских сценария (например, «Создание заказа», «Просмотр отчёта», «Авторизация пользователя») и для каждого:

   • описать, какие шаги выполняет клиент (тонкий);

   • какие шаги выполняет монолит на сервере.

   Можно оформить в виде таблицы:

   | Сценарий | Действия клиента | Действия сервера (монолита) |

4. Плюсы и минусы для вашей ИС.
   Кратко (8–10 предложений):

   • плюсы: упрощение клиента, централизованная логика, единая точка обновления;

   • минусы: нагрузка на сервер, зависимость от сети, особенности UX и т.п. — применительно к вашей теме.

Результат ЧАСТИ 1:

• Текстовое описание роли тонкого клиента.

• Диаграмма “Монолит + тонкий клиент” (уровень контейнеров).

• Таблица распределения ответственности по 2–3 сценариям.

• Анализ плюсов/минусов.

ЧАСТЬ 2. Монолит с толстым клиентом

Цель: Спроектировать вариант, где:

• на сервере — по-прежнему монолит;

• на клиенте — толстый клиент (настольное приложение, rich SPA, мобильное приложение), выполняющий значимую часть логики.

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

Задания

1. Выбрать тип толстого клиента для своей ИС.
   В тексте: каким вы видите толстый клиент в вашей системе:

   • desktop-приложение (Windows/macOS/Linux);

   • мобильное приложение;

   • web SPA с большим объёмом логики;

   • что хранится локально (кэш, настройки, часть данных).

2. Диаграмма “Монолит + толстый клиент”.
   Нарисовать:

   • Толстый клиент (Rich Client / Desktop / Mobile / SPA);

   • Сервер монолита (Monolith Backend);

   • БД и другие серверные компоненты.

   На диаграмме обозначить:

   • какие данные запрашиваются c сервера;

   • какой объём логики выполняет клиент (валидация, бизнес-правила на клиенте, кеширование, офлайн-режим — если есть).

3. Распределить функционал и данные между клиентом и монолитом.
   Для тех же 2–3 сценариев, что в ЧАСТИ 1 (чтобы было проще сравнивать):

   | Сценарий | Что делает толстый клиент | Что делает сервер (монолит) | Какие данные могут кэшироваться на клиенте |

4. Риски и преимущества толстого клиента при монолите.
   Кратко (8–10 предложений):

   • плюсы: богатый UX, часть обработки уходит на клиент, возможность частичного офлайна;

   • минусы: сложнее обновлять, несколько версий клиентов, дублирование логики между клиентом и сервером и т.п.

Результат ЧАСТИ 2:

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

• Диаграмма архитектуры “Монолит + толстый клиент”.

• Таблица распределения функционала по сценариям.

• Анализ плюсов/минусов.

ЧАСТЬ 3. Микросервисы с тонким клиентом

Цель: Рассмотреть вариант, когда серверная часть — микросервисная (из ЛАБЫ 3), а клиент остаётся тонким.

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

Задания

1. Определить точку входа для тонкого клиента.
   Обычно это:

   • API Gateway / Frontend Backend Service;

   • сервис, который агрегирует данные от микросервисов и выдаёт удобный интерфейс (страницы/данные) тонкому клиенту.

   В тексте опишите:

   • через что тонкий клиент обращается к микросервисам (напрямую или через gateway);

   • где собивается и форматируется ответ.

2. Диаграмма “Микросервисы + тонкий клиент”.
   На диаграмме:

   • Тонкий клиент;

   • API Gateway (если есть);

   • несколько ключевых микросервисов (из ЛАБЫ 3);

   • БД каждой службы (или общие хранилища, если так задумано).

   Показать, как клиент проходит путь к микросервисам (напрямую / через gateway).

3. Распределить ответственность по 2–3 сценариям.
   Для тех же сценариев:

   | Сценарий | Действия тонкого клиента | Участие gateway/фасада | Какие микросервисы задействованы |

4. Плюсы и минусы такого сочетания.
   Кратко (8–10 предложений):

   • чем помогает комбинация “микросервисы + тонкий клиент”;

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

Результат ЧАСТИ 3:

• Текстовое описание взаимодействия тонкого клиента с микросервисами.

• Диаграмма “Микросервисы + тонкий клиент”.

• Таблица сценариев и задействованных сервисов.

• Анализ плюсов/минусов.

ЧАСТЬ 4. Микросервисы с толстым клиентом

Цель: Рассмотреть вариант максимальной распределённости: микросервисная архитектура + толстый клиент.

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

Задания

1. Определить, сколько логики уходит на толстый клиент при микросервисах.
   В тексте объяснить:

   • какие части бизнес-логики остаются на стороне клиента (композиция экранов, часть бизнес-правил, локальные проверки, агрегация данных из разных сервисов);

   • как клиент взаимодействует с микросервисами:

     • напрямую с несколькими сервисами;

     • или через gateway;

     • какие данные может кэшировать.

2. Диаграмма “Микросервисы + толстый клиент”.
   На диаграмме показать:

   • Толстый клиент (Desktop/Mobile/SPA);

   • API Gateway (если нужен);

   • основные микросервисы (как в ЛАБЕ 3);

   • БД сервисов.

   Отметить, какие запросы клиент отправляет напрямую, а какие — через посредника.

3. Сценарии с участием толстого клиента.
   Для тех же 2–3 сценариев:

   | Сценарий | Логика на толстом клиенте | Какие микросервисы вызываются | Как клиент комбинирует ответы |

4. Риски и преимущества максимального разделения.
   В тексте (8–10 предложений):

   • плюсы: гибкий UX, независимое масштабирование клиентских приложений и backend-сервисов, богатые offline-возможности;

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

Результат ЧАСТИ 4:

• Описание роли толстого клиента в микросервисной архитектуре.

• Диаграмма “Микросервисы + толстый клиент”.

• Таблица сценариев и распределения логики.

• Анализ плюсов/минусов.

6. Итоговое сравнение четырёх вариантов

После выполнения всех частей студент:

1. Заполняет итоговую матрицу сравнения 4-х вариантов по 5–7 критериям (пример):

   Критерий / Вариант	Монолит + тонкий	Монолит + толстый	Микросервисы + тонкий	Микросервисы + толстый
   Сложность разработки	…	…	…	…
   Удобство обновления (release management)	…	…	…	…
   Требования к квалификации команды	…	…	…	…
   UX / возможности интерфейса	…	…	…	…
   Масштабируемость по нагрузке	…	…	…	…
   Возможности офлайна	…	…	…	…
   Сложность эксплуатации и поддержки	…	…	…	…

   
   
   

2. Делает итоговый вывод:

   • какой из вариантов наиболее подходит для его ИС сейчас;

   • какой вариант может стать следующим шагом эволюции (если система вырастет).

7. Публичная защита и обсуждение

Каждый студент:

1. Показывает на проекторе 2–3 ключевых диаграммы, которые лучше всего иллюстрируют отличие вариантов (обычно по одному рисунку для монолитной и микросервисной связки, плюс акцент на клиенте).

2. Показывает итоговую матрицу сравнений (4 варианта х критерии).

3. За 5–7 минут объясняет:

   • чем отличаются 4 варианта именно для его темы;

   • какой вариант он рекомендует и почему.

Остальные студенты и преподаватель:

• задают вопросы,

• критикуют «лишнюю сложность» там, где микросервисы/толстый клиент не оправданы,

• или наоборот — указывают, где монолит/тонкий клиент могут не выдержать требований.

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

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

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

3. Часть 1. Монолит + тонкий клиент (описание, диаграмма, таблица сценариев, плюсы/минусы).

4. Часть 2. Монолит + толстый клиент (то же).

5. Часть 3. Микросервисы + тонкий клиент (то же).

6. Часть 4. Микросервисы + толстый клиент (то же).

7. Итоговая матрица сравнения 4-х вариантов.

8. Итоговые выводы: рекомендуемый вариант сейчас и возможный путь эволюции.

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

1. Чем тонкий клиент отличается от толстого клиента с точки зрения распределения логики и данных?

2. Какие комбинации архитектуры сервера и клиента вы рассмотрели для своей ИС?

3. В каких случаях монолит + тонкий клиент — разумный вариант?

4. Когда оправдан монолит + толстый клиент?

5. Как меняются требования к инфраструктуре и DevOps при переходе к микросервисам?

6. Как выбор толстого клиента влияет на сложность версионирования API?

7. Какой вариант вы считаете наилучшим для своей ИС и почему?

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