Открытый вебинар
Тестирование в микросервисной архитектуре

Приложение в docker-образ и запушить его на Dockerhub . В этом и последующих ДЗ у вас будет два варианта задания на выбор:
- Вариант с кодом для глубокого погружения в тему
- Вариант без кода, сфокусированный на представлении архитектуры


**! Важно !**

**В проектной работе необходимо написание кода**. Если вы планируете выполнять проект, рекомендуем выбирать вариант ДЗ с кодом - это облегчит подготовку к защите.

---

**Вариант 1 (С КОДОМ)**

Шаг 1. Создать минимальный сервис, который
1) отвечает на порту 8000
2) имеет http-метод:
- GET /health/
- RESPONSE: {"status": "OK"}


Шаг 2. Cобрать локально образ приложения в докер контейнер под архитектуру AMD64.

Запушить образ в dockerhub


На выходе необходимо предоставить
1) имя репозитория и тэг на Dockerhub
2) ссылку на github c Dockerfile, либо приложить Dockerfile в ДЗ


*Обратите внимание*, что при сборке на m1 при запуске вашего контейнера на стандартных платформах будет ошибка такого вида:

*standard_init_linux.go:228: exec user process caued: exec format error*


Для сборки рекомендую указать тип платформы linux/amd64:
*docker build --platform linux/amd64 -t tag*


Более подробно можно прочитать в статье: https://programmerah.com/how-to-solve-docker-run-error-standard_init_linux-go219-exec-user-process-caused-exec-format-error-39221/

---

**Вариант 2 (БЕЗ КОДА)**

**Необходимо подготовить:**

Деплоймент диаграмму проекта включая сервис аутентификации в С4 model.

Основы работы с Kubernetes. **Вариант 1 (С КОДОМ)**

**Шаг 1.** Создать минимальный сервис, который
1) отвечает на порту 8000
2) имеет http-метод


GET /health/


RESPONSE: {"status": "OK"}


**Шаг 2.** Cобрать локально образ приложения в докер.

Запушить образ в dockerhub


**Шаг 3.** Написать манифесты для деплоя в k8s для этого сервиса.


Манифесты должны описывать сущности: Deployment, Service, Ingress.

В Deployment могут быть указаны Liveness, Readiness пробы.

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


Хост в ингрессе должен быть arch.homework. В итоге после применения манифестов GET запрос на http://arch.homework/health должен отдавать {“status”: “OK”}.


**Шаг 4.** На выходе предоставить

0) ссылку на github c манифестами. Манифесты должны лежать в одной директории, так чтобы можно было их все применить одной командой kubectl apply -f .

1) url, по которому можно будет получить ответ от сервиса (либо тест в postmanе).


*Задание со звездой*:

В Ingress-е должно быть правило, которое форвардит все запросы с /otusapp/{student name}/* на сервис с rewrite-ом пути. Где {student name} - это имя студента.

Например: curl arch.homework/otusapp/aeugene/health -> рерайт пути на arch.homework/health


**Рекомендации по форме сдачи дз:**
- использовать nginx ingress контроллер, установленный через хелм, а не встроенный в миникубик:
kubectl create namespace m && helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx/ && helm repo update && helm install nginx ingress-nginx/ingress-nginx --namespace m -f nginx-ingress.yaml (файл приложен к занятию)
- https://kubernetes.github.io/ingress-nginx/user-guide/basic-usage/
необходимо в новых версиях nginx добавлять класс ингресса
ingressClassName: nginx
- прикладывать к 2 дз урл для проверки: curl http://arch.homework/health или как указано в дз со *.

К 3 ДЗ и далее прикладывать коллекцию postman и проверять ее работу через newman run имя_коллекции (прикладывать кроме команд разворачивания приложения, команду удаления)
- прописать у себя в /etc/hosts хост arch.homework с адресом своего миникубика (minikube ip), чтобы обращение было по имени хоста в запросах, а не IP.
- Обратите внимание, что при сборке на m1 при запуске вашего контейнера на стандартных платформах будет ошибка такого вида:
standard_init_linux.go:228: exec user process caued: exec format error


Для сборки рекомендую указать тип платформы linux/amd64:
docker build --platform linux/amd64 -t tag .


Более подробно можно прочитать в статье: https://programmerah.com/how-to-solve-docker-run-error-standard_init_linux-go219-exec-user-process-caused-exec-format-error-39221/

---

**Вариант 2 (БЕЗ КОДА)**

Предложить тест на основные сущности кубера из 10 вопросов.

Инфраструктурные паттерны. **Вариант 1 (С КОДОМ)**

Сделать простейший RESTful CRUD по созданию, удалению, просмотру и обновлению пользователей.

Пример API - https://app.swaggerhub.com/apis/otus55/users/1.0.0


Добавить базу данных для приложения.

Конфигурация приложения должна хранится в Configmaps.

Доступы к БД должны храниться в Secrets.

Первоначальные миграции должны быть оформлены в качестве Job-ы, если это требуется.

Ingress-ы должны также вести на url arch.homework/ (как и в прошлом задании)


На выходе должны быть предоставлена
1) ссылка на директорию в github, где находится директория с манифестами кубернетеса
2) инструкция по запуску приложения.
- команда установки БД из helm, вместе с файлом values.yaml.
- команда применения первоначальных миграций
- команда kubectl apply -f, которая запускает в правильном порядке манифесты кубернетеса
3) Postman коллекция, в которой будут представлены примеры запросов к сервису на создание, получение, изменение и удаление пользователя. Важно: в postman коллекции использовать базовый url - arch.homework.
4) Проверить корректность работы приложения используя созданную коллекцию newman run коллекция_постман и приложить скриншот/вывод исполнения корректной работы


*Задание со звездочкой:*

Добавить шаблонизацию приложения в helm чартах

---

**Вариант 2 (БЕЗ КОДА)**

В данном ДЗ нужно будет более детально показать как произошло распределение моделей данных(сущностей) между микросервисами.

Подготовить:

ER-диаграмму структуры базы данных (БД) для микросервисов, на которой будут отражены связи между сущностями, ограничения (констрейнты), ключи(foreign keys, primary keys).

Желательно подготовить ddl скрипты проектируемой структуры БД для одного или нескольких ключевых микросервисов.

Prometheus. Grafana. **Вариант 1 (С КОДОМ)**

Сделать дашборд в Графане, в котором были бы метрики с разбивкой по API методам:
1. Latency (response time) с квантилями по 0.5, 0.95, 0.99, max
2. RPS
3. Error Rate - количество 500ых ответов


Добавить в дашборд графики с метрикам в целом по сервису, взятые с nginx-ingress-controller:
1. Latency (response time) с квантилями по 0.5, 0.95, 0.99, max
2. RPS
3. Error Rate - количество 500ых ответов


Настроить алертинг в графане на Error Rate и Latency.


На выходе должно быть:

0) скриншоты дашборды с графиками в момент стресс-тестирования сервиса. Например, после 5-10 минут нагрузки.

1) json-дашборды.


*Задание со звездочкой*

Используя существующие системные метрики из кубернетеса, добавить на дашборд графики с метриками:
1. Потребление подами приложения памяти
2. Потребление подами приолжения CPU


Инструментировать базу данных с помощью экспортера для prometheus для этой БД.

Добавить в общий дашборд графики с метриками работы БД.

---

**Вариант 2 (БЕЗ КОДА)**

Подготовить постановку задачи для DevOps.

Предложить 2-3 варианта бизнес-метрик мониторинга, а также технических метрик мониторинга, которые должны будут обеспечить наблюдаемость за системой в процессе ее эксплуатации.

Backend for frontends. Apigateway. **Вариант 1 (С КОДОМ)**

Добавить в приложение аутентификацию и регистрацию пользователей.


Реализовать сценарий "Изменение и просмотр данных в профиле клиента".

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


На выходе должны быть

0) описание архитектурного решения и схема взаимодействия сервисов (в виде картинки)

1) команда установки приложения (из helm-а или из манифестов). Обязательно указать в каком namespace нужно устанавливать.
1) команда установки api-gateway, если он отличен от nginx-ingress.
2) тесты постмана, которые прогоняют сценарий:
- регистрация пользователя 1
- проверка, что изменение и получение профиля пользователя недоступно без логина
- вход пользователя 1
- изменение профиля пользователя 1
- проверка, что профиль поменялся
- выход* (если есть)
- регистрация пользователя 2
- вход пользователя 2
- проверка, что пользователь2 не имеет доступа на чтение и редактирование профиля пользователя1.


В тестах обязательно
- наличие {{baseUrl}} для урла
- использование домена arch.homework в качестве initial значения {{baseUrl}}
- использование сгенерированных случайно данных в сценарии
- отображение данных запроса и данных ответа при запуске из командной строки с помощью newman.

---

**Вариант 2 (БЕЗ КОДА)**

**Необходимо подготовить:**

Диаграммы последовательности (сиквенс-диаграммы) реализующие сценарий аутентификации и следующий за ним ключевой сценарий из ДЗ1:
- Сценарий 1. Пользователь не аутентифицирован, проходит аутентификацию и дальше идет переход на выполнение ключевого сценария.
- Сценарий 2. Пользователь аутентифицирован, осуществляет попытку доступа к данным, которые ему не принадлежат или не доступны в виду ролевой модели.

Stream processing. **Вариант 1 (С КОДОМ)**

Реализовать сервис заказа. Сервис биллинга. Сервис нотификаций.


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


Сервис нотификаций позволяет отправить сообщение на email. И позволяет получить список сообщений по методу API.


Пользователь может создать заказ. У заказа есть параметр - цена заказа.

Заказ происходит в 2 этапа:
1) сначала снимаем деньги с пользователя с помощью сервиса биллинга
2) отправляем пользователю сообщение на почту с результатами оформления заказа. Если биллинг подтвердил платеж, должно отправиться письмо счастья. Если нет, то письмо горя.


Упрощаем и считаем, что ничего плохого с сервисами происходить не может (они не могут падать и т.д.). Сервис нотификаций на самом деле не отправляет, а просто сохраняет в БД.


ТЕОРЕТИЧЕСКАЯ ЧАСТЬ:

0) Спроектировать взаимодействие сервисов при создании заказов. Предоставить варианты взаимодействий в следующих стилях в виде sequence диаграммы с описанием API на IDL:
- только HTTP взаимодействие
- событийное взаимодействие с использование брокера сообщений для нотификаций (уведомлений)
- Event Collaboration cтиль взаимодействия с использованием брокера сообщений
- вариант, который вам кажется наиболее адекватным для решения данной задачи. Если он совпадает одним из вариантов выше - просто отметить это.


ПРАКТИЧЕСКАЯ ЧАСТЬ:

Выбрать один из вариантов и реализовать его.

На выходе должны быть

I) описание архитектурного решения и схема взаимодействия сервисов (в виде картинки)

II) команда установки приложения (из helm-а или из манифестов). Обязательно указать в каком namespace нужно устанавливать.

III) тесты постмана, которые прогоняют сценарий:
1. Создать пользователя. Должен создаться аккаунт в биллинге.
2. Положить деньги на счет пользователя через сервис биллинга.
3. Сделать заказ, на который хватает денег.
4. Посмотреть деньги на счету пользователя и убедиться, что их сняли.
5. Посмотреть в сервисе нотификаций отправленные сообщения и убедиться, что сообщение отправилось
6. Сделать заказ, на который не хватает денег.
7. Посмотреть деньги на счету пользователя и убедиться, что их количество не поменялось.
8. Посмотреть в сервисе нотификаций отправленные сообщения и убедиться, что сообщение отправилось.


В тестах обязательно
- наличие {{baseUrl}} для урла
- использование домена arch.homework в качестве initial значения {{baseUrl}}
- отображение данных запроса и данных ответа при запуске из командной строки с помощью newman.

---

**Вариант 2 (БЕЗ КОДА)**

Сформировать формат сообщений, которые будут передаваться асинхронно между микросервисами (Json-схема и т.п.) с их описанием.

Распределенные транзакции. **Вариант 1 (С КОДОМ)**

Сценарий для интернет-магазина:

Реализовать сервисы "Платеж", "Склад", "Доставка".

Реализовать сервисы "Платеж", "Склад", "Доставка".


Для сервиса "Заказ", в рамках метода "создание заказа" реализовать механизм распределенной транзакции (на основе Саги или двухфазного коммита).

Во время создания заказа необходимо:
1) в сервисе "Платеж" убедиться, что платеж прошел
2) в сервисе "Склад" зарезервировать конкретный товар на складе
3) в сервисе "Доставка" зарезервировать курьера на конкретный слот времени.


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


На выходе должно быть:

0) описание того, какой паттерн для реализации распределенной транзакции использовался

1) команда установки приложения (из helm-а или из манифестов). Обязательно указать в каком namespace нужно устанавливать и команду создания namespace, если это важно для сервиса.

2) тесты в postman


В тестах обязательно
- использование домена arch.homework в качестве initial значения {{baseUrl}}

---

**Вариант 2 (БЕЗ КОДА)**

Сформировать сиквенс-диаграмму распределенной транзакции.

При необходимости, актуализировать деплоймент и контейнерную диаграммы проекта, которые выполнялись в ДЗ1 и ДЗ2.

Идемпотентость и коммутативность API в HTTP и очередях. **Вариант 1 (С КОДОМ)**

На выходе должно быть:

0) описание того, какой паттерн для реализации идемпотентности использовался

1) команда установки приложения (из helm-а или из манифестов). Обязательно указать в каком namespace нужно устанавливать и команду создания namespace, если это важно для сервиса.

2) тесты в postman


В тестах обязательно
- использование домена arch.homework в качестве initial значения {{baseUrl}}

---

**Вариант 2 (БЕЗ КОДА)**

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

Проектная работа. 1. Выбрать тему
2. Утвердить темы в чате по дз
3. Презентовать проект


-----------

Основные требования:

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