НИС Дизайн систем II 4 курс 2024/2025 homework — различия между версиями
Материал из Wiki - Факультет компьютерных наук
Smb1987 (обсуждение | вклад) (ДЗ общая формулировка) |
Smb1987 (обсуждение | вклад) |
||
| Строка 1: | Строка 1: | ||
== FR == | == FR == | ||
Описаны в лекции. | Описаны в лекции. | ||
| − | + | ||
| − | + | * кратко -- реализовать 3 http/grpc/... handler (обработчика, "ручки") | |
| − | + | * берите тот протокол, что лучше знаете -- смысл не в протоколе) | |
| − | + | * нужно предусмотреть получение данных от источников данных | |
| − | + | * должны быть тесты, (какая-то) БД для хранения итд | |
| + | * подсмотреть самую простую реализацию (чтоб не придумывать) можно в репозитории | ||
=== Источники данных === | === Источники данных === | ||
| − | + | * Данные о заказе | |
| − | + | * Данные о зоне заказа | |
| − | + | * Данные об исполнителе | |
| − | + | * Данные о конфигурационных настройках (см feature flags / feature toggles) | |
| − | + | * Данные о платных дорогах (пока не описано) | |
== NFR == | == NFR == | ||
| Строка 24: | Строка 25: | ||
=== Требования по Scalability === | === Требования по Scalability === | ||
==== Оригинальная формулировка (общая для всех) ==== | ==== Оригинальная формулировка (общая для всех) ==== | ||
| − | + | * Рассчитываем систему на X одновременно назначаемых заказов -- внешняя нагрузка | |
| − | + | * Рассчитываем систему на Y исполнителей -- кол-во пользователей системы | |
| − | + | * Каждый исполнитель раз в 1 минуту спрашивает про свой заказа | |
| − | + | * Каждый заказ занимает Z кб | |
| − | + | * Отмена каждого заказа происходит в среднем за 10 минут | |
| − | + | * Система должна линейно масштабироваться к нагрузке | |
Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability. | Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability. | ||
| Строка 49: | Строка 50: | ||
==== Возможный вариант домашнего задания ==== | ==== Возможный вариант домашнего задания ==== | ||
**Критичными** источниками данных являются: | **Критичными** источниками данных являются: | ||
| − | + | * данные об исполнителе | |
**Некритичными** источниками данных являются: | **Некритичными** источниками данных являются: | ||
| − | + | * данные по зоне заказа | |
| − | + | * Нам подойдет неактуальность данных их этого источника в течение `10 минут`. После этого следует показывать данные из конфига. | |
| − | + | * (подсказка по защите) ожидаю, что в тексте по защите домашнего задания вы покажете логи/скриншоты итд, которые реализуют все эти сценарии | |
| − | + | * конфиги | |
| − | + | * сервис должен на старте получать актуальные конфиги и не использовать походы в них при обработке запросов | |
| − | + | * при недоступности источника конфигов при старте сервис не должен запускаться | |
| − | + | * сервис может бесконечно долго использовать старые данные | |
*Должна быть предусмотрена идемпотентность выполняемых операций (может потребовать хранения дополнительных данных) | *Должна быть предусмотрена идемпотентность выполняемых операций (может потребовать хранения дополнительных данных) | ||
Версия 23:48, 23 сентября 2024
Содержание
FR
Описаны в лекции.
- кратко -- реализовать 3 http/grpc/... handler (обработчика, "ручки")
- берите тот протокол, что лучше знаете -- смысл не в протоколе)
- нужно предусмотреть получение данных от источников данных
- должны быть тесты, (какая-то) БД для хранения итд
- подсмотреть самую простую реализацию (чтоб не придумывать) можно в репозитории
Источники данных
- Данные о заказе
- Данные о зоне заказа
- Данные об исполнителе
- Данные о конфигурационных настройках (см feature flags / feature toggles)
- Данные о платных дорогах (пока не описано)
NFR
Тут подсмотреть негде :-) Но можно обсуждать в чате, в ЛС, ну или в вашей команде.
Требования по Maintainability
Система должна быть спроектирована с учетом высокой вероятности изменений как в количестве источников данных (могут появляться дополнительные), так и в непосредственной логике формирования заказа (для простоты дано буквально 3 варианта бизнес-логики, но в реальности там тысячи строк кода). Также, необходимо предусмотреть возможность выполнения дополнительных действий или после назначения заказа, или после его отмены.
Требования по Scalability
Оригинальная формулировка (общая для всех)
- Рассчитываем систему на X одновременно назначаемых заказов -- внешняя нагрузка
- Рассчитываем систему на Y исполнителей -- кол-во пользователей системы
* Каждый исполнитель раз в 1 минуту спрашивает про свой заказа
- Каждый заказ занимает Z кб
- Отмена каждого заказа происходит в среднем за 10 минут
- Система должна линейно масштабироваться к нагрузке
Итого, описание каждого варианта будет включать X, Y, Z и возможно еще некоторые требования по Scalability.
Возможный вариант домашнего задания
X == 100 Y == 10k Z == 5 kb
Могут быть дополнительные требования по Scalability
Требования по Reliability
Разрабатываемая система зависит от 5 источников данных. С теоретической точки зрения источники данных могут быть либо критичными, либо некритичными. В этой задаче источник данных с заказами является критичным. То есть никакие стратегии увеличения надежности для него реализовывать не нужно.
Все остальные источники данных будут разделены на 2 части примерно так:
Возможный вариант домашнего задания
- Критичными** источниками данных являются:
- данные об исполнителе
- Некритичными** источниками данных являются:
- данные по зоне заказа
* Нам подойдет неактуальность данных их этого источника в течение `10 минут`. После этого следует показывать данные из конфига. * (подсказка по защите) ожидаю, что в тексте по защите домашнего задания вы покажете логи/скриншоты итд, которые реализуют все эти сценарии
- конфиги
* сервис должен на старте получать актуальные конфиги и не использовать походы в них при обработке запросов * при недоступности источника конфигов при старте сервис не должен запускаться * сервис может бесконечно долго использовать старые данные
- Должна быть предусмотрена идемпотентность выполняемых операций (может потребовать хранения дополнительных данных)
