Задание
Ревью
История

Сдача проектной работы 3 спринта

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

Текущее решение компании

  • Нынешнее положение компании позволяет только управлять отоплением в доме и проверять температуру.
  • Каждая установка сопровождается выездом специалиста по подключению системы отопления в доме к текущей версии системы.
  • Архитектура компании представляет из себя монолит на Java с СУБД Postgres. Всё синхронно. Никаких асинхронных вызовов, микросервисов и реактивного взаимодействия в системе нет. Всё управление идёт от сервера к датчику. Данные о температуре также получаются через запрос от сервера к датчику.
  • Самостоятельно подключить свой датчик к системе пользователь не может.

Целевая экосистема, которую необходимо создать

  • Экосистема доступна пользователю в режиме самообслуживания по модели SaaS.
  • Система позволяет управлять отоплением, включать и выключать свет, запирать и отпирать автоматические ворота, удаленно наблюдать за домом и будущее неуточненное поведение.
  • Пользователь самостоятельно выбирает необходимые ему модули умного дома (устройства), сам их подключает, настраивает сценарии работы и просматривает телеметрию.
  • Компания не занимается производством устройств, но поддерживает подключение к экосистеме устройств партнеров по стандартным протоколам.
  • Веб-разработка передана на аутсорс и не входит в требования данной работы.
Требования к экосистеме
  • Модули управления приборами и сами приборы (устройства) должны быть максимально готовы к использованию и продаваться в отдельных комплектах для удобной покупки и подключения.
  • Устройства должны быть доступны через интернет (для удаленного наблюдения и доступа), и предполагается, что пользователь будет иметь интернет-канал, к которому их можно подключить.
  • Покупатели могут программировать систему для управления различными модулями в соответствии со своими потребностями.

Лэндскейп компании

Структура компании
  • Команда разработчиков (5 человек)
  • Команда DevOps (2 человека)
  • Команда QA (3 человека)
  • Команда по обслуживанию клиентов (10 человек)
  • Команда по продажам и маркетингу (5 человек)
Команды и продукты, с которыми компания работает в рамках кейса
  • Команда разработчиков будет работать над рефакторингом и разделением монолита на микросервисы.
  • Команда DevOps будет заниматься настройкой CI/CD пайплайнов, контейнеризацией и оркестрацией.
  • Команда QA будет проводить тестирование новой системы.
  • Команда по обслуживанию клиентов будет обучена работе с новой системой и предоставлять поддержку пользователям.
  • Команда по продажам и маркетингу будет заниматься продвижением новых модульных комплектов.
Развернутые технологии, сервисы и приложения, которые влияют на решение (описание и диаграмма)
  • Монолитное приложение на Java с PostgreSQL в качестве СУБД.
  • 100 подключенных модулей управления отоплением
  • 100 веб-клиентов приложения (веб-разработка передана на аутсорс и не входит в требования данной работы)

Цели бизнеса

Промежуточное состояние (через пару месяцев)
  • Описана AsIs и ToBe архитектура решения. Создан план по переходу к целевой системе.
  • MVP с разделёнными микросервисами для управления отоплением, освещением, наблюдением, воротами.
Финальное состояние (через год)
  • Настроенные CI/CD пайплайны для автоматизации сборки и деплоя платформы экосистемы.
  • Полностью развернутая экосистема умного дома с модульной структурой.
  • Платформа экосистемы готова к подключению до 100 экопоселков по 200 домов по пять устройств в каждом.
  • Пользователи могут самостоятельно подключать новые модули, управлять ими через интернет и настраивать автоматические сценарии работы устройств.
В этой проектной работе всего вас ждёт три задания. Обязательная часть включает первое задание и часть второго. Вам предстоит спроектировать архитектуру и реализовать MVP новой экосистемы, которая будет:
  • Модульной и масштабируемой, чтобы легко добавлять новые функции.
  • Ориентированной на самообслуживание, чтобы пользователи могли всё делать сами.
  • Основанной на микросервисах, чтобы обеспечить гибкость и отказоустойчивость.
Выполнение дополнительной части позволит вам глубже понять принципы Saga, CQRS и некоторых аспектов 12-факторных приложений и получить практические навыки в области контейнеризации, CI/CD и управления микросервисами.

Как работать над заданием

  1. Создайте репозиторий по шаблону https://github.com/Yandex-Practicum/architecture-sprint-3.
  2. Создайте в репозитории ветку project_part_1. В ней вы будете выполнять задания.
  3. Выполните задания и опишите свои решения в файле Project_template_part_1. Мы заранее добавили его в репозиторий и сохранили туда шаблон для ответов. Вам нужно только заполнить его.
  4. Когда сделаете все задания проекта и опишете свои решения в Project_template_part_1, создайте пул-реквест из ветки project_part_1 в основную ветку вашего репозитория. Убедитесь, что пул-реквест содержит все изменения, которые вы вносили. Проверьте, что отправляете их в ваш собственный репозиторий, а не в репозиторий Практикума. Это важно: если сделаете ПР в репозиторий Практикума, ревьюер сразу отправит ваше решение на доработку.

Задание 1: Анализ и проектирование

🔍 Первое задание состоит из четырёх частей, в которых вы проанализируете текущее монолитное приложение, выделите микросервисы и спроектируете взаимодействие между ними, визуализируете архитектуру с помощью модели С4, а затем разработаете ER-диаграмму.
Выполнение этого задания займёт 5–7 часов.

Необходимая инфраструктура

  • Система контроля версий (например, Git).
  • IDE (например, IntelliJ IDEA, VS Code).
  • Markdown редактор (например, в том же самом IDE).
  • PlantUML-редактор (например, PlantUML plugin for IntelliJ IDEA, online PlantUML editor).
  • Шаблон C4 для PlantUML.

Рекомендуемые инструменты

Инфоресурс по C4
Документация по plantUML
Онлайн-редактор для создания диаграмм
Средства для разработки API (например, Swagger Editor)

Подзадание 1.1: Анализ и планирование

Суть бизнес-задачи

Прежде чем проектировать новую систему, необходимо досконально разобраться с тем, что у нас есть. Вам нужно изучить текущее монолитное приложение, понять его сильные и слабые стороны, а также проанализировать, как принципы Domain-Driven Design (DDD) могут быть применены для построения новой архитектуры.

Что нужно сделать?

  1. Изучите функциональность монолитного приложения:
    Управление отоплением:
    • Пользователи могут удалённо включать/выключать отопление в своих домах.
    • Пользователи могут устанавливать желаемую температуру.
    • Система автоматически поддерживает заданную температуру, регулируя подачу тепла.
    Мониторинг температуры:
    • Система получает данные о температуре с датчиков, установленных в домах.
    • Пользователи могут просматривать текущую температуру в своих домах через веб-интерфейс.
  2. Проанализируйте архитектуру монолитного приложения:
    • Язык программирования: Java
    • База данных: PostgreSQL
    • Архитектура: Монолитная, все компоненты системы (обработка запросов, бизнес-логика, работа с данными) находятся в рамках одного приложения.
    • Взаимодействие: Синхронное, запросы обрабатываются последовательно.
    • Масштабируемость: Ограничена, так как монолит сложно масштабировать по частям.
    • Развертывание: Требует остановки всего приложения.
  3. Определите домены и границы контекстов: домен «Управление Устройствами» и так далее.
  4. Подробно опишите, какие проблемы создаёт монолитного решение для компании в контексте текущих бизнес-задач. Если вы считаете, что текущее решение не вызывает проблем, аргументируйте свою позицию.
  5. Визуализируйте контекст системы. Создайте C4 диаграмму (System Context diagram) с помощью PlantUML, чтобы наглядно показать, как монолитное приложение взаимодействует с внешним миром (пользователи, датчики).

В результате вы

  • Изучите функциональность текущего монолитного приложения и поймёте, как оно работает.
  • Проанализируете архитектуру монолитного приложения, выявите его сильные и слабые стороны.
  • Определите домены и границы контекстов в соответствии с принципами Domain-Driven Design (DDD).
  • Создадите C4 диаграмму (System Context diagram), визуализирующую взаимодействие монолитного приложения с внешним миром.
  • Подготовите план перехода к микросервисной архитектуре, который будет использоваться в следующих подзаданиях.

Перед отправкой проверьте, что

  • Описана функциональность текущего монолитного приложения.
  • Проанализирована архитектура монолитного приложения (язык программирования, база данных, архитектура, взаимодействие, масштабируемость, развертывание).
  • Определены домены и границы контекстов в системе.
  • Создана C4 диаграмма (System Context diagram), визуализирующая взаимодействие монолитного приложения с внешним миром.
  • Диаграмма создана с использованием PlantUML и соответствует стандартам C4.

Подзадание 1.2: Архитектура микросервисов

Суть бизнес-задачи

Вы провели анализ текущего монолитного приложения, определили его функциональные блоки и выделили основные домены. Теперь ваша задача — спроектировать высокоуровневую архитектуру новой экосистемы, основанную на микросервисах. Для этого вам нужно определить ключевые микросервисы, спроектировать их взаимодействие с учетом использования API Gateway и Kafka (опционально, взаимодействие между сервисами может быть реализовано напрямую), а также визуализировать полученную архитектуру с помощью диаграмм C4.

Что нужно сделать?

  1. Декомпозируйте приложение на микросервисы. Основывайте решение на доменах и границах контекстов, которые вы выделили в предыдущем задании, разбейте систему на новые микросервисы. При этом также учитывайте и бизнес-цели компании — они могут потребовать разработки микросервисов с нуля. У вас должны получиться домены как для As-Is решения, так и для To-Be. В ходе декомпозиции ориентируйтесь на наилучшие практики архитектуры микросервисов и паттерны проектирования.
  2. Определите взаимодействия между:
    • микросервисами,
    • API Gateway,
    • шиной данных ((например, Kafka) (опционально)),
    • базой данных.
  3. Визуализируйте архитектуру, которая у вас получилась:
    • C4 — Уровень контейнеров (Containers) Создайте диаграмму, показывающую основные контейнеры (приложения, базы данных, очереди сообщений) и их взаимодействие.
    • C4 — Уровень компонентов (Components) Детализируйте взаимодействие внутри выбранных микросервисов, выделив ключевые компоненты и их ответственности. Например, для микросервиса «Управление устройствами» можно выделить компоненты: API, обработчик команд, менеджер состояния устройств.
    • C4 — Уровень кода (Code) Для самых критичных частей системы можно создать диаграммы на уровне кода (например, UML диаграммы классов или последовательностей), чтобы детально показать, как они реализованы. Необязательно описывать весь код — выберите только самые критичные части.

В результате вы

  • Научитесь разрабатывать архитектуру микросервисов, определять ключевые микросервисы и спроектировали их взаимодействие с использованием API Gateway и, при желании, Kafka.
  • Научитесь визуализировать полученную архитектуру с помощью диаграмм C4, что позволит вам получить четкое представление о структуре и взаимодействиях в системе.

Перед отправкой проверьте, что

  • Система разбита на микросервисы в соответствии с выделенными доменами и границами контекстов.
  • Определено взаимодействие между микросервисами, API Gateway, базой данных и, если используется, шиной данных (например, Kafka).
  • Созданы C4 диаграммы на уровне контейнеров (Containers) и компонентов (Components), визуализирующие архитектуру системы.
  • При необходимости созданы C4 диаграммы на уровне кода (Code) для самых критичных частей системы.
  • Все диаграммы созданы с использованием PlantUML и соответствуют стандартам C4.

Подзадание 1.3: ER-диаграмма

Суть бизнес-задачи

К началу этого подзадания вы определили ключевые микросервисы и спроектировали их взаимодействие с использованием API Gateway и Kafka. А ещё визуализировали полученную архитектуру с помощью диаграмм C4, что позволило вам получить чёткое представление о структуре и взаимодействиях в системе.
В этом задании вам предстоит глубже погрузиться в структуру данных будущей экосистемы. Необходимо определить ключевые сущности (такие как «Устройство», «Модуль», «Пользователь», «Телеметрия») и смоделировать их взаимосвязи, чтобы создать логическую модель базы данных.

Что нужно сделать?

  1. Идентификация сущностей: На основе анализа предметной области и спроектированных микросервисов, определите основные сущности вашей системы.
    Примеры сущностей:
    • Пользователь (User)
    • Дом (House)
    • Устройство (Device)
    • Тип устройства (DeviceType)
    • Модуль (Module)
    • Телеметрия (TelemetryData)
  2. Определение атрибутов: Для каждой сущности определите необходимые атрибуты. Например:
    Сущность «Устройство»:
    • id — уникальный идентификатор устройства.
    • type_id — идентификатор типа устройства — внешний ключ к таблице DeviceType.
    • house_id — идентификатор дома, к которому принадлежит устройство — внешний ключ к таблицеHouse.
    • serial_number — серийный номер устройства.
    • status — текущее состояние устройства (включено/выключено).
  3. Описание связей: Определите связи между сущностями (один-к-одному, один-ко-многим, многие-ко-многим).
    Например:
    • Пользователь — Дом: один пользователь может иметь доступ к нескольким домам, но каждый дом связан только с одним пользователем.
    • Дом — Устройство: один дом может содержать несколько устройств, и каждое устройство принадлежит только одному дому.
    • Устройство — Телеметрия: одно устройство может генерировать множество записей телеметрии.
  4. Построение ER-диаграммы: Используйте PlantUML для создания ER-диаграммы на основе определенных сущностей, атрибутов и связей.

В результате вы

  • Разработаете ER-диаграмму, которая описывает основные сущности системы и их взаимосвязи.
  • Определите ключевые сущности, например как «Пользователь», «Дом», «Устройство», «Тип устройства», «Модуль» и «Телеметрия».
  • опишете атрибуты для каждой сущности и определили связи между ними.
  • Создадите ER-диаграмму с использованием PlantUML, что позволит вам визуализировать структуру данных системы и понять, как сущности взаимодействуют друг с другом.

Перед отправкой проверьте, что

  • Определены основные сущности системы, например как «Пользователь», «Дом», «Устройство», «Тип устройства», «Модуль» и «Телеметрия».
  • Для каждой сущности определены необходимые атрибуты.
  • Описаны связи между сущностями (один-к-одному, один-ко-многим, многие-ко-многим).
  • Создана ER-диаграмма с использованием PlantUML.
  • ER-диаграмма корректно отображает все сущности, их атрибуты и связи между ними.

Подзадание 1.4: Создание и документирование API

Суть бизнес-задачи

После успешной разработки ER-диаграммы вы получили чёткое представление о структуре данных будущей экосистемы. Теперь настало время перейти к следующему этапу — созданию и документированию API.
Микросервисы должны уметь «общаться» друг с другом. Ваша задача — спроектировать API (интерфейс программного приложения) для взаимодействия между двумя ключевыми микросервисами, которые вы определили ранее, например «Управление устройствами» и «Телеметрия». Вам нужно определить необходимые эндпойнты, методы запросов, форматы данных и описать контракты взаимодействия, чтобы микросервисы могли эффективно обмениваться информацией.

Что нужно сделать?

  1. Выбор типов API: В зависимости от специфики взаимодействия между вашими микросервисами, вы можете использовать:
    • REST API: Хорошо подходит для синхронного взаимодействия, когда клиенту (в данном случае — другому микросервису) нужен немедленный ответ на запрос.
    • AsyncAPI: Используется для асинхронного взаимодействия, когда клиенту не нужно ждать ответа немедленно (например, отправка уведомления о новом измерении температуры). Kafka может быть использована для реализации асинхронного взаимодействия.
  2. Проектирование API для микросервиса «Управление устройствами». Например, определите эндпойнты и методы запросов для выполнения основных операций:
    Получение информации об устройстве:
    • Эндпойнт: /devices/{device_id}
    • Метод: GET
    • Описание: Возвращает подробную информацию о конкретном устройстве по его ID.
    Обновление состояния устройства:
    • Эндпойнт: /devices/{device_id}/status
    • Метод: PUT
    • Описание: Позволяет изменить состояние устройства (например, включить/выключить).
    Отправка команды устройству:
    • Эндпойнт: /devices/{device_id}/commands
    • Метод: POST
    • Описание: Отправляет команду устройству (например, «установить температуру 22 градуса»).
  3. Проектирование API для микросервиса «Телеметрия»
    Получение последних данных телеметрии:
    • Эндпойнт: /devices/{device_id}/telemetry/latest
    • Метод: GET
    • Описание: Возвращает последнее полученное значение телеметрии для устройства.
    Получение исторических данных телеметрии:
    • Эндпойнт: /devices/{device_id}/telemetry
    • Метод: GET
    • Описание: Возвращает исторические данные телеметрии для устройства за определённый период времени.
  4. Описание контрактов взаимодействия:
    Для каждого эндпойнта укажите:
    • Формат запроса: опишите структуру JSON для тела запроса (если применимо).
    • Формат ответа: опишите структуру JSON для ответа.
    • Коды ответа: укажите HTTP-коды статуса, которые будут возвращаться в различных ситуациях (например, 200 — успех, 404 — устройство не найдено, 500 — ошибка сервера).
    • Примеры запросов и ответов: укажите наглядные примеры в блоке examples.
  5. Документирование API:
    Используйте Swagger/OpenAPI (для REST API) или AsyncAPI для создания интерактивной документации. Это упростит интеграцию микросервисов и позволит другим разработчикам легко понимать, как использовать ваши API.

В результате вы

  • Оцените роль API Gateway при проектировании взаимодействия микросервисов.
  • Определите, когда необходимо использовать асинхронное взаимодействие, (например через Kafka), и проектировать API с учетом этого.

Перед отправкой проверьте, что

  • Выбраны типы API (REST, AsyncAPI или их комбинация) для взаимодействия между микросервисами «Управление устройствами» и «Телеметрия».
  • Спроектированы эндпойнты и методы запросов для основных операций микросервисов.
  • Описаны контракты взаимодействия для каждого эндпойнта, включая форматы запросов и ответов, коды ответа и примеры.
  • Создана интерактивная документация API с использованием Swagger/OpenAPI (для REST API) или AsyncAPI.
  • Документация API покрывает все эндпойнты и содержит исчерпывающую информацию для их использования.

Задание 2: Разработка MVP

Подзадание 2.1: Новые микросервисы и интеграция с монолитом

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

Суть бизнес-задачи

На этом этапе вам предстоит создать два новых микросервиса: «Управление телеметрией» и «Управление устройствами». Эти микросервисы будут выполнять базовые функции, соответствующие своим названиям, и интегрироваться с существующим монолитным приложением. Взаимодействие между микросервисами и монолитом может осуществляться через шину данных Kafka (опционально), что позволит постепенно переносить функциональность из монолита в микросервисы, или напрямую, если вы решите не использовать Kafka на данном этапе.
  • Микросервис «Управление телеметрией»: Ответственен за приём, обработку и хранение данных телеметрии от устройств.
  • Микросервис «Управление устройствами»: Отвечает за регистрацию новых устройств, управление их состоянием (вкл/выкл) и отправку команд.

Необходимая инфраструктура

  • Система контроля версий Git для хранения кода.
  • IDE для разработки (например, IntelliJ IDEA, VS Code).
  • Postman для тестирования API.
  • СУБД: Выберите и разверните СУБД, подходящую для ваших микросервисов, основываясь на ER-диаграмме, разработанной в Задании 1.
🔍 Фронтенд для взаимодействия с микросервисами не является обязательным на данном этапе.

Что нужно сделать?

  1. Выбор языка программирования: Выберите язык программирования для реализации микросервисов, основываясь на ваших знаниях и предпочтениях.
  2. Создание проекта: Создайте новый проект для каждого микросервиса в вашей IDE и настройте систему контроля версий Git.
  3. Разработка API: Используя спецификацию OpenAPI, определите эндпойнты, методы запросов, форматы данных и коды ответов для API каждого микросервиса.
  4. Реализация логики микросервисов: Напишите код для обработки запросов к API, взаимодействия с брокером сообщений Kafka (опционально) и выполнения бизнес-логики.
    • Интеграция с СУБД: Реализуйте взаимодействие микросервисов с выбранной СУБД для сохранения и получения данных, соответствующих сущностям и связям из ER-диаграммы.
  5. Интеграция с монолитом: Настройте взаимодействие микросервисов с существующим монолитным приложением (опционально: через брокер сообщений Kafka, или напрямую), чтобы была возможность постепенно переходить с монолита на микросервисы.
    • Взаимодействие с монолитом (через REST API):
      • Микросервис «Управление устройствами» предоставляет REST endpoint /devices/{deviceId}/status, который принимает HTTP PUT-запросы с JSON-телом, содержащим новое состояние устройства ({"status": "on/off"}). Монолит может вызывать этот endpoint для изменения состояния устройства.
      • Микросервис «Управление телеметрией» предоставляет REST endpoint /telemetry, который принимает HTTP POST-запросы с JSON-телом, содержащим данные телеметрии. Монолит, получая данные от датчиков, может отправлять их на этот endpoint для сохранения.
    • Взаимодействие с монолитом (через Kafka):
      • Микросервис «Управление устройствами» подписывается на Kafka-топик device_commands и ожидает сообщений с командами для устройств. Монолит публикует сообщения в формате JSON, например, {"deviceId": 123, "command": "turn_on"}.
      • Микросервис «Управление устройствами» публикует сообщения о статусе устройств в Kafka-топик device_statuses. Монолит может подписаться на этот топик и получать актуальную информацию о состоянии устройств.
      • Микросервис «Управление телеметрией» подписывается на Kafka-топик sensor_data и ожидает сообщений с данными от датчиков. Монолит, получая данные от датчиков, публикует их в этом топике в формате JSON, например, {"deviceId": 123, "temperature": 25.5}.
  6. Развертывание в Minikube:
    • Установите и запустите Minikube.
    • Создайте Kubernetes Deployment и Service для каждого микросервиса. Подробнее о Kubernetes
    • Если используется Kafka, разверните Kafka в Minikube, используя, например, Helm chart. Подробнее о Helm
    • Настройте взаимодействие между микросервисами и монолитом, используя Kubernetes Service для адресации.

Дополнительная часть (опционально):

  • Проектирование с помощью Saga: Реализуйте паттерн Saga для управления распределенными транзакциями между микросервисами, если это необходимо. Использование Saga позволит обеспечить согласованность данных в распределенной системе. Подробнее о Saga.
  • Применение CQRS: Разделите операции чтения и записи данных в микросервисах с помощью паттерна CQRS, если это целесообразно. CQRS позволит оптимизировать производительность системы и упростить масштабирование. Подробнее о CQRS.
  • Расширенное применение 12-факторных приложений: Примените дополнительные принципы 12-факторных приложений, такие как конфигурация через переменные окружения, логирование в stdout и независимое масштабирование. Это сделает ваши микросервисы более переносимыми, масштабируемыми и простыми в развертывании.
  • Использование Kafka кластера: Разверните полноценный Kafka кластер для обеспечения отказоустойчивости и масштабируемости. Kafka кластер обеспечит высокую доступность и пропускную способность системы.

Перед отправкой проверьте, что

Обязательные пункты:
  • Созданы два микросервиса: «Управление телеметрией» и «Управление устройствами».
  • Микросервисы реализованы на одном из языков программирования.
  • Микросервисы работают с выбранной СУБД.
  • Реализованы все сущности и связи, определенные в ER-диаграмме.
  • Для каждого микросервиса разработано API, соответствующее спецификации OpenAPI.
  • Микросервисы развернуты в Minikube.
  • Настроено взаимодействие микросервисов с монолитом (опционально: через Kafka, или напрямую).
  • Код микросервисов добавлен в Git репозиторий.
Дополнительные пункты:
  • Реализован паттерн Saga для управления распределёнными транзакциями (если применимо).
  • Применён паттерн CQRS для разделения операций чтения и записи (если применимо).
  • Применены дополнительные принципы 12-факторных приложений.
  • Развернут полноценный Kafka-кластер.

Подзадание 2.2: Подготовка 3rd party сервисов для связи микросервисов

🔍 В данном задании не требуется реализовывать фронтенд. Основная цель — настроить взаимодействие между микросервисами и внешним миром через Kafka и API Gateway.

Суть бизнес-задачи

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

Что такое Kusk Gateway?

Kusk Gateway — это open-source шлюз API, предоставляющий возможности для управления API на основе спецификации OpenAPI.
Преимущества использования Kusk Gateway:
  • Упрощенное управление API: Kusk Gateway позволяет определить маршрутизацию, политики безопасности, ограничения скорости и другие настройки API непосредственно из спецификации OpenAPI.
  • Интеграция с Kubernetes: Kusk Gateway разработан специально для работы в Kubernetes и легко интегрируется с Ingress.
  • Расширяемость: Kusk Gateway предоставляет возможность расширения функциональности с помощью плагинов.
  • Настройка Kafka(опционально): Если вы выбрали использовать Kafka в предыдущем подзадании, Необходимо развернуть и настроить кластер брокера сообщений Kafka для организации асинхронного обмена данными между микросервисами. Kafka обеспечит надёжную и масштабируемую коммуникацию между микросервисами.
  • Настройка API Gateway: Требуется развернуть и настроить шлюз API, который будет выступать единой точкой входа для всех внешних запросов к микросервисам. API Gateway упростит взаимодействие клиентов с микросервисами, обеспечит безопасность и балансировку нагрузки.

Необходимая инфраструктура

  • Микросервисы «Управление телеметрией» и «Управление устройствами» из предыдущего задания 2.1.
  • Helm charts для Kafka и API Gateway (например, Kong, Traefik, Ambassador, Kusk Gateway).

Что нужно сделать?

  1. Развертывание Kafka (опционально): Если вы используете Kafka, разверните её в Minikube с помощью Helm chart.
  2. Настройка Kafka (опционально): Настройте Kafka на прием сообщений от микросервисов и передачу их нужным потребителям.
  3. Развертывание API Gateway: Разверните API Gateway, (например, Kusk Gateway) в Minikube, используя Helm chart.
  4. Настройка API Gateway: Настройте маршрутизацию запросов от внешних клиентов к соответствующим микросервисам, используя Kubernetes Ingress и Services.
  5. Интеграция микросервисов: Подключите микросервисы «Управление телеметрией» и «Управление устройствами» к выбранной системе обмена сообщениями (например, Kafka, если она используется) для асинхронного обмена данными. Если вы не используете Kafka, настройте прямую интеграцию между микросервисами.
  6. Тестирование: Протестируйте взаимодействие между микросервисами и API Gateway. Убедитесь, что запросы от клиентов правильно маршрутизируются и обрабатываются.
Важно: В данном задании не требуется реализовывать фронтенд (необязательно). Основная цель — настроить взаимодействие между микросервисами и внешним миром через Kafka (опционально) и API Gateway.

Перед отправкой проверьте, что

Обязательные пункты:
  • Развернут и настроен API Gateway в Minikube.
  • Микросервисы «Управление телеметрией» и «Управление устройствами» подключены к Kafka (опционально).
  • API Gateway настроен на маршрутизацию запросов к микросервисам.
  • Протестировано взаимодействие между микросервисами и API Gateway (запросы корректно маршрутизируются и обрабатываются).
Дополнительные пункты:
  • Развернут и настроена Kafka в Minikube.
  • Реализована балансировка нагрузки на API Gateway.
  • Настроены механизмы безопасности на API Gateway (например, аутентификация, авторизация).
  • Проведены нагрузочные тесты для проверки работоспособности Kafka и API Gateway под нагрузкой.

Задание 3: Автоматизация поставки (опционально)

🔍 Выполнение этого задания опционально, но поможет вам получить практические навыки в области контейнеризации, CI/CD и управления микросервисами. Все эти навыки являются неотъемлемой частью современной разработки программного обеспечения.
Если вы не сталкиваетесь с подобными задачами в своей работе, можете пропустить это задание.

Подзадание 3.1: Контейнеризация микросервисов

Суть бизнес-задачи

В этом подзадании вам предстоит «упаковать» ваши микросервисы и фронтенд в Docker-контейнеры и подготовить систему к запуску в Minikube. Контейнеризация позволит запускать вашу систему в различных средах (на локальной машине, в тестовой среде, в продакшн) без необходимости каждый раз настраивать окружение.
Вам необходимо создать Docker-контейнеры для каждого из ваших микросервисов («Управление телеметрией», «Управление устройствами») и для фронтенда, а также конфигурацию для запуска системы целиком в Minikube. Каждый контейнер должен содержать все необходимые зависимости и конфигурацию для запуска соответствующего компонента системы. Выполнение данного задания необходимо для того, чтобы унифицировать способ запуска сервисов, упростить его и избавиться от проблем совместимости при запуске в различных окружениях.

Необходимая инфраструктура

  • Система контроля версий для хранения артефактов: Git (GitHub, GitLab, Bitbucket)
  • Хранилище артефактов: GitHub Container Registry необходимо для хранения Docker образов ваших микросервисов. Это позволит вам централизованно управлять версиями образов и легко развертывать их в различных окружениях.
  • Minikube: Для развертывания и запуска ваших микросервисов.
  • Helm: Для управления развертыванием приложений в Kubernetes.
  • Kafka, API GW шаблон в виде docker-compose: Docker Compose файл для запуска Kafka и API Gateway, который вы создали в Задании 2.
  • Микросервисы и фронт (необязательно) для интеграции с Kafka и API GW из подзадачи 2.1: Исходный код ваших микросервисов и фронтенда (необязательно).

Что нужно сделать?

  1. Создайте Dockerfile для каждого микросервиса:
    • Укажите базовый образ, который содержит необходимые зависимости (например, Java, Python).
    • Скопируйте код вашего микросервиса в образ.
    • Установите зависимости, специфичные для вашего микросервиса.
    • Укажите команду для запуска вашего микросервиса при запуске контейнера.
  2. Создайте Dockerfile для фронтенда:
    • Аналогично создайте Dockerfile для вашего фронтенда, учитывая его специфику.
  3. Создайте Helm чарты:
    • Опишите все ваши сервисы (микросервисы, Kafka, API Gateway, фронтенд (необязятельно)).
    • Укажите Docker образы, которые будут использоваться.
    • Укажите, как сервисы должны быть связаны друг с другом (порты, сети).
    • Используйте Kubernetes Deployment для запуска контейнеров.
    • Используйте Kubernetes Service для обеспечения доступа к сервисам.
  4. Соберите Docker-образы:
    • Используйте команду docker build для сборки образов для каждого микросервиса и фронтенда.
  5. Загрузите образы в хранилище артефактов:
    • Используйте команду docker push для загрузки образов в GitHub Container Registry или другое хранилище.
  6. Запустите сервисы с помощью Helm:
    • Используйте команду helm install для запуска всех сервисов, описанных в вашем Helm chart.
  7. Протестируйте работу сервисов:
    • Убедитесь, что все сервисы запускаются без ошибок и взаимодействуют друг с другом должным образом.

Перед отправкой проверьте, что

  1. Dockerfile:
    • Создан Dockerfile для каждого микросервиса и фронтенда.
    • В Dockerfile указан базовый образ с необходимыми зависимостями.
    • Код микросервиса/фронтенда скопирован в образ.
    • Установлены специфичные зависимости.
    • Указана команда для запуска микросервиса/фронтенда.
  2. Helm:
    • Создан Helm chart.
    • В Helm chart файле описаны все сервисы (микросервисы, API Gateway, фронтенд).
    • Указаны связи между сервисами (порты, сети).
    • Использованы Kubernetes Deployment и Service.
  3. Сборка и загрузка образов:
    • Docker-образы собраны для каждого микросервиса и фронтенда.
    • Docker-образы загружены в хранилище артефактов.
  4. Запуск и тестирование:
    • Все сервисы успешно запускаются с помощью Helm в Minikube.
    • Сервисы взаимодействуют друг с другом без ошибок.
    • Протестирована работоспособность системы в целом.

Подзадание 3.2: Настройка CI/CD пайплайнов

Суть бизнес-задачи

Теперь, когда ваши микросервисы «упакованы» в Docker-контейнеры, вы можете автоматизировать процесс их сборки, тестирования и развертывания с помощью CI/CD пайплайнов. Автоматизация этих процессов позволит вам быстрее и чаще выпускать новые версии вашего приложения, а также уменьшить количество ошибок при развертывании. GitHub Actions предоставляет удобный и гибкий инструмент для создания CI/CD пайплайнов непосредственно в вашем репозитории GitHub.
Ваша задача — настроить CI/CD пайплайны для каждого микросервиса и фронтенда. CI/CD пайплайны позволят автоматизировать следующие этапы:
  • Сборка: автоматическая сборка новых версий ваших микросервисов и фронтенда при каждом изменении кода.
  • Тестирование: автоматический запуск тестов для проверки работоспособности новых версий в Minikube.
  • Развёртывание: автоматическое развёртывание новых версий в Kubernetes кластер.
Настройка CI/CD пайплайнов позволит вам ускорить процесс разработки и доставки вашего приложения, повысить его качество и снизить риск ошибок при развертывании.

Необходимая инфраструктура

  • Сервер автоматизации (Github): Github Actions.
  • Minikube: Для развёртывания и запуска ваших микросервисов.
  • Helm: Для управления развертыванием приложений в Kubernetes.
  • Система контроля версий для хранения артефактов: Git (GitHub).
  • Хранилище артефактов: GitHub Container Registry.
  • Kafka, API GW шаблон в виде docker-compose: Docker Compose файл для Kafka и API Gateway.

Что нужно делать?

  1. Создайте Helm чарты для каждого микросервиса и фронтенда:
    • Helm чарт — это пакет для развертывания приложений в Kubernetes.
    • Опишите в Helm чарте, как ваш микросервис или фронтенд должен быть развернут (какие образы использовать, какие ресурсы выделять).
  2. Создайте CI/CD пайплайн для каждого микросервиса и фронтенда:
    • Используйте Github Actions для описания шагов вашего пайплайна.
    • Опишите шаги для сборки, тестирования, загрузки образов в хранилище артефактов и обновления Helm релиза в Minicube.
  3. Настройте триггеры для запуска пайплайнов:
    • Настройте пайплайны на запуск при каждом пуше кода в репозиторий.
  4. Проверьте работу пайплайнов:
    • Сделайте изменения в коде одного из микросервисов или фронтенда.
    • Убедитесь, что пайплайн запускается автоматически и успешно выполняет все этапы (сборка, тестирование, развертывание).

Перед отправкой проверьте, что

  1. Helm:
    • Созданы Helm чарты для каждого микросервиса и фронтенда.
    • В Helm чартах указаны необходимые ресурсы и зависимости для развертывания.
  2. CI/CD пайплайны:
    • Созданы CI/CD пайплайны для каждого микросервиса и фронтенда.
    • Пайплайны настроены на автоматический запуск при пуше кода в репозиторий.
    • Пайплайны выполняют сборку, тестирование и развертывание микросервисов/фронтенда.
    • Пайплайны интегрированы с Minicube и Helm для развертывания.
  3. Автоматизация:
    • Проверено автоматическое обновление микросервисов/фронтенда при изменении кода.
    • Настроено автоматическое масштабирование микросервисов.

Как сдать работу

Решите задания. Опишите свои решения в файле Readme.md. Вставьте ссылку на пул-реквест во вкладке «Ревью».
После того как отправите ссылку, не вносите изменения в проект. Сдайте проект и дождитесь комментариев ревьюера.

На что будет смотреть ревьюер

Ревьюер не примет работу, если она не будет соответствовать требованиям:
  • Репозиторий с решением публичный. Перед отправкой убедитесь, что репозиторий в вашем GitHub публичный. Иначе ревьюер не сможет проверить работу.
  • В работе нет вопросов к ревьюеру по условиям задания. Если у вас возникнут вопросы по проектной работе, обратитесь к наставнику в Пачке — он вам поможет. Ревьюер проверяет уже готовое решение.
  • Если вы повторно отправляете проект на ревью, вы исправили замечания ревьюера с прошлой проверки.