НИС Дизайн систем II 4 курс 2024/2025 homework

FR

Описаны в лекции.

• кратко -- реализовать 3 http/grpc/... handler (обработчика, "ручки")
• берите тот протокол, что лучше знаете -- смысл не в протоколе)
• нужно предусмотреть получение данных от источников данных
• должны быть тесты, (какая-то) БД для хранения итд
• подсмотреть самую простую реализацию (чтоб не придумывать) можно в репозитории

Источники данных

• Данные о заказе
• Данные о зоне заказа
• Данные об исполнителе
• Данные о конфигурационных настройках (см feature flags / feature toggles)
• Данные о платных дорогах (пока не описано)

NFR

Тут подсмотреть негде :-) Но можно обсуждать в чате, в ЛС, ну или в вашей команде.

Требования по Maintainability

Система должна быть спроектирована с учетом высокой вероятности изменений как в количестве источников данных (могут появляться дополнительные), так и в непосредственной логике формирования заказа (для простоты дано буквально 3 варианта бизнес-логики, но в реальности там тысячи строк кода). Также, необходимо предусмотреть возможность выполнения дополнительных действий или после назначения заказа, или после его отмены.

Требования по Scalability

Оригинальная формулировка (общая для всех)

• Рассчитываем систему на X одновременно назначаемых заказов -- внешняя нагрузка. X измеряется в RPS
• Рассчитываем систему на Y исполнителей -- кол-во пользователей системы. Y измеряется в штуках

   * Каждый исполнитель раз в 1 минуту спрашивает про свой заказа

• Каждый заказ занимает Z кб
• Отмена каждого заказа происходит в среднем за 10 минут -- старый вариант

 * Обновление
 * Каждую секунду отменяется W (процент от рейта заказов) заказов
 * Если за секунду создается 100 заказов, то в эту же секунду отменяется 50 из них (ну вот такая неэффективная система назначения получается).
 * Отмененные заказы нельзя показывать исполнителю.

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

Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability.

Возможный вариант домашнего задания

X == 100 Y == 10k Z == 5 kb

Могут быть дополнительные требования по Scalability

Требования по Reliability

Разрабатываемая система зависит от 5 источников данных. С теоретической точки зрения источники данных могут быть либо критичными, либо некритичными. В этой задаче источник данных с заказами является критичным. То есть никакие стратегии увеличения надежности для него реализовывать не нужно.

Все остальные источники данных будут разделены на 2 части примерно так:

Возможный вариант домашнего задания

• • Критичными** источниками данных являются:
• данные об исполнителе

• • Некритичными** источниками данных являются:
• данные по зоне заказа

   * Нам подойдет неактуальность данных их этого источника в течение `10 минут`. После этого следует показывать данные из конфига. 
   * (подсказка по защите) ожидаю, что в тексте по защите домашнего задания вы покажете логи/скриншоты итд, которые реализуют все эти сценарии

• конфиги

   * сервис должен на старте получать актуальные конфиги и не использовать походы в них при обработке запросов
   * при недоступности источника конфигов при старте сервис не должен запускаться
   * сервис может бесконечно долго использовать старые данные

• Должна быть предусмотрена идемпотентность выполняемых операций (может потребовать хранения дополнительных данных)

Как сдавать домашнее задание

Из семинара:

• Нужно описать дизайн системы, отвечающей требованиям

 * Должен получиться ADR определенной/фиксированной структуры 

• Нужно реализовать систему, отвечающую требованиям

 * Должен получиться сервис / несколько сервисов + БД для хранения
 * Детали реализации остаются на ваше усмотрение

• Нужно показать/продемонстрировать выполнение ключевых FR / NFR

 * Должен получиться текстовый отчет произвольной структуры 

Что должно входить в ADR (Architecture Design Record)

Для вдохновения можно почитать: - https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman - https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/templates/decision-record-template-of-the-madr-project

Расчет нагрузки

Должен входить расчет нагрузки, с пересчетом RPS на каждый endpoint/ручку Должен входить расчет по читающим/пишущим запросам в БД (прям вот буквально -- ожидается 100 RPS на запись, 300 RPS на чтение) Точно должен входить расчет хранения на БД -- нужно хранить ХХХ Гб

Схема системы

- Должны быть показаны пользователи системы (внешние потребители, внешние системы итд) - Должны быть показаны микросервис/микросервисы - Должны быть показаны БД - Могут быть показаны L7-балансировщики - Должны быть показаны схемы выполнения запросов, в случае нескольких микросервисов

Основные сущности

- Должны быть представлены сущности, которые будут храниться в БД. С описанием полей

Что должно входить в детали реализации

- Исходный код реализованных микросервисов (>=1 штуки) - Схема выбранной БД на SQL/любом другом диалекте - Обратите внимание на следование принципам SOLID, выполнение всех требований по надежности и других требований вашего варианта ДЗ

Что должно входить в "текстовый отчет произвольной структуры"

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

Например -- требование про "executer -- реализовать поход на фоллбэк-источник данных (service substitution)"

Вы должны показать корректную работу сервиса (через логи, графики итд) при работающем сервисе "executer" Вы должны показать корректную работу сервиса (через логи, графики итд) при _неработающем_ сервисе "executer" -- должны быть запросы к другому источнику данных. Сервис должен продолжать корректно отвечать на запросы при этом и выдавать понятные сообщения в логи.

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