orangeflag / itmo-microservice Goto Github PK

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

• Запуск системы в Docker Swarm.
• Проверка работоспособности системы при наличии нескольких работающих экземпляров каждого из сервисов.
• Проверка работоспособности (здесь речь скорее о правильной обработке частичных падений и т.д.) при отсутствии работающих экземпляров каждого из сервисов.

Требуется для упрощения сдачи 4 лабы. Если у нас будет простой инструмент для показа возможностей сервисов, то и сдавать будет проще

Добавить swagger-ui для каждого из микросервисов и просмотреть доступность странички с описанием по эндпоинту [сервис]/swagger-ui.html

Ориентируемся на ER и описание из лабы:
Публичное API:

1. Name: Get items
   Method: GET
   Path: api/warehouse/items
   Parameters: -
   Input: -
   Returns: коллекцию объектов представляющих товар (ItemDto), обязательные поля: идентификатор (id: integer), наименование (name: string), количество доступных для
   заказа (amount: integer), цена (price: money)
   Invariants: -

2. Name: Get item by id
   Method: GET
   Path: api/warehouse/items/{item_id}
   Parameters: not null {item_id} - идентификатор товара
   Input: -
   Returns: ItemDto {id, name, amount, price}
   Invariants: -

3. Name: Create item
   Method: POST
   Path: api/warehouse/items
   Parameters: -
   Input: ItemCreationDto {name, amount, price}
   Returns: ItemDto {id, name, amount, price}
   Invariants: До вызова объект не существует в базе данных, после вызова количество товаров с данным идентификатором становится равно amount

4. Name: Add existing items
   Method: PUT
   Path: api/warehouse/items/{id}/addition/{amount}
   Parameters: id - идентификатор товара, 0 > amount > 10_000 - количество добавляемых товаров
   Input: -
   Returns: ItemDto {id, name, amount} - обновленное состояние объекта
   Invariants: -

5. Name: Reserve items
   Method: POST
   Path: api/warehouse/items/{id}/reserve/{amount}
   Parameters: id - идентификатор товара, 0 > amount > 10_000 - количество резервируемого товаров
   Input: -
   Returns: ReserveItemDto {id, name, amount} - зарезервированная продукция
   Invariants: Если количество резервируемого товара больше чем на складе, то резервируется весь товар, который есть

6. Name: Unreserve items
   Method: POST
   Path: api/warehouse/items/{id}/unreserve/{amount}
   Parameters: id - идентификатор товара, 0 > amount > 10_000 - количество добавляемых товаров
   Input: -
   Returns: ItemDto {id, name, amount} - обновленное состояние объекта
   Invariants: -

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

• Реализация роутинга (направления) запросов к целевым сервисам.
• Интегрирование механизма балансировки нагрузки (client size / service side). Поддержание его при развертывании с помощью Docker-compose
• Использование паттерна circuit breaker
  blocked by #14

Ориентируемся на ER и описание из лабы:
Публичное API:
Name: Get orders
Method: GET
Path: api/orders
Parameters: -
Input: -
Returns: коллекцию объектов представляющих заказ (OrderDto), обязательные поля: идентификатор (id: integer), статус заказа (status {COLLECTING, PAYED, SHIPPING, COMPLETE, FAILED, CANCELLED} : string/enum ), суммарная стоимость (totalCost: money), количество товаров в заказе (totalAmount: integer), идентификатор пользователя (username: string), коллекция объектов представляющих (ItemDto[]).
Invariants: -

Name: Get order by id
Method: GET
Path: api/orders/{order_id}
Parameters: not null {order_id} - идентификатор заказа
Input: -
Returns: OrderDto {id, status, username, totalCost, totalAmount, ItemDto[]} - актуальное состояние объекта.
Invariants: -

Name: Add item to order
Method: POST
Path: api/orders/{order_id}/item
Parameters: nullable {order_id} - идентификатор заказа
Input: not null ItemAdditionParametersDto {id, 0< amount < 100, username}
Returns: -
OrderDto { id } - как минимум идентификатор заказа, которому была добавлена деталь.
Invariants: -
если переданный идентификатор заказа null, то в результате вызова в базе данных создается новый заказ и его идентификатор возвращается клиенту после вызова заказ содержит товары, которые содержал до вызова и новый товар с характеристиками, переданными в ItemAdditionParametersDto после вызова количество доступных товаров с данным дентификатором становится меньше на amount, но не может стать меньше нуля.

Name: Change order status
Method: PUT
Path: api/orders/{order_id}/status/{status}
Parameters: not null {order_id} - идентификатор заказа, not null {status} - {COLLECTING, PAID, SHIPPING, COMPLETE, FAILED, CANCELLED} - статус, в который переводится заказ.
Input: -
Returns: OrderDto {id, status} - как минимум идентификатор и статус заказа
Invariants: статус заказа меняется в соответствии с машиной состояний в зависимости от результата вызова в случае перевода в состояния {FAILED, CANCELLED} количество доступных товаров, которые были включены в данный заказ, увеличивается на количество их в заказе

Нужно сделать PR для https://github.com/microservices-course-itmo/designing_microservices_course

Контейнеризация, регистрация и обнаружение сервисов (service discovery), проверки жизнеспособности (health check)

• Создание Docker контейнеров для каждого из сервисов (микросервисов и инфраструктурных сервисов) на базе образов из общедоступных репозиториев
• Создание Docker-compose файла, способного запустить всю систему в работоспособном состоянии
• Интегрирование механизма service discovery (client side / service side). Поддержание его при развертывании с помощью Docker-compose.

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

Разобраться как там это делается в Hibernate, нужно ли нам это и где именно

OpenFeign, RabbitMQ
https://github.com/OrangeFlag/itmo-microservice/tree/service/labs/lab2

Ориентируемся на ER и описание из лабы:
Публичное API:

1. Name: Perform payment
   Method: PUT
   Path: api/payment/{order_id}
   Parameters: not null {order_id} - идентификатор заказа
   Input: UserDetailsDto {username, cardAuthorizationInfo {AUTHORIZED, UNAUTHORIZED}: string/enum} - оплата производится в зависимости от статуса карты.
   Returns: OrderDto { id } - как минимум идентификатор заказа.
   Invariants: статус заказа меняется в соответствие с машиной состояний в зависимости от результата вызова в случае неуспешной попытки количество доступных товаров, которые были включены в данный заказ, увеличивается на количество их в заказе