На воркшопе создавали свой LRU, а чуть раньше говорили о кэшировании и об инструментах для него.
Нужно в сервис нотификаций добавить возможность получения истории уведомлений пользователя за конкретный период и закэшировать её:
- Если пользователь уже запрашивал историю за конкретный период, то возвращать её из кэша
- Для кэширования использовать либо LRU с воркшопа, либо любое другое решение, например, Redis
- Функционал покрыть unit тестами
- Требуется обеспечить простоту замены конкретной реализации кэша
- 💎 На алмазик реализовать кэширование (с практической пользой) в другом сервисе/участке системы на свое усмотрение
Дедлайн: 15 июля 23:59 (сдача) / 18 июля, 23:59 (проверка)
Описание предыдущих дз
Перед запуском проекта убедитесь, что у вас есть config.yaml. Для справки приведен стандартный вид конфига в
файле config.yaml.example, который можно использовать как default
- Создать скелеты трёх сервисов по описанию АПИ из файла contracts.md
- Структуру проекта сделать с учетом разбиения на слои, бизнес-логику писать отвязанной от реализаций клиентов и хендлеров
- Все хендлеры отвечают просто заглушками
- Сделать удобный враппер для сервера по тому принципу, по которому делали на воркшопе
- Придумать самостоятельно удобный враппер для клиента
- Все межсервисные вызовы выполняются. Если хендлер по описанию из contracts.md должен ходить в другой сервис, он должен у вас это успешно делать в коде.
- Общение сервисов по http-json-rpc
- должны успешно проходить make precommit и make run-all в корневой папке
- Наладить общение с product-service (в хендлере Checkout.listCart). Токен для общения с product-service получить, написав в личку @badger_za
Дедлайн: 27 мая, 23:59 (сдача) / 30 мая, 23:59 (проверка)
Перевести всё взаимодействие c сервисами на протокол gRPC.
Для этого:
- Использовать разделение на слои, созданное ранее, заменив слой HTTP на GRPC.
- Взаимодействие по HTTP полностью удалить и оставить только gRPC.
- В каждом проекте нужно добавить в Makefile команды для генерации кода из proto файла и установки нужных зависимостей.
Дополнительное задание на алмазик: добавить HTTP-gateway и proto-валидацию.
Дедлайн: 3 июня, 23:59 (сдача) / 6 июня, 23:59 (проверка)
- Для каждого сервиса(где необходимо что-то сохранять/брать) поднять отдельную БД в docker-compose.
- Сделать миграции в каждом сервисе (достаточно папки миграций и скрипта).
- Создать необходимые таблицы.
- Реализовать логику репозитория в каждом сервисе.
- В качестве query builder-а можно использовать любую библиотеку (согласовать индивидуально с тьютором). Рекомендуется https://github.com/Masterminds/squirrel.
- Драйвер для работы с postgresql: только pgx (pool).
- В одном из сервисов сделать транзакционность запросов (как на воркшопе).
Задание на алмазик:
- Для каждой БД полнять свой балансировщик (pgbouncer или odyssey, можно и то и то). Сервисы ходят не на прямую в БД, а через балансировщик
Дедлайн: 10 июня, 23:59 (сдача) / 13 июня, 23:59 (проверка)
- Уменьшить время ответа Checkout.listCart при помощи worker pool. Запрашивать не более 5 SKU одновременно.
Worker pool нужно написать самостоятельно. Обязательное требование - читаемость кода и покрытие комментариями.
- При общении с Product Service необходимо использовать лимит 10 RPS на клиентской стороне.
Допускается использование библиотечных рейт-лимитеров. В случае собственного читаемый код и комментарии обязательны.
- Во всех слоях сервиса необходимо использовать контекст для возможности отмены вызова.
Задания на алмазик:
- Синхронизировать рейт-лимитер при помощи БД.
- Аннулировать заказы старше 10 минут в фоне. Позаботиться о том, чтобы реплики сервиса не штурмовали БД все вместе.
Дедлайн: 17 июня, 23:59 (сдача) / 20 июня, 23:59 (проверка)
Необходимо обеспечить полное покрытие бизнес-логики ручек ListCart или Purchase модульными тестами (go test
-coverprofile).
Если вдруг ваши слои до сих пор не изолированны друг от друга через интерфейсы, необходимо это сделать.
В качестве генератора моков можете использовать, что душе угодно: mockery, minimoc, gomock, ...
Задание на алмазик: добавить интеграционные тесты для проверки слоя взаимодействия с базой данных.
Дедлайн: 24 июня 23:59 (сдача) / 27 июня, 23:59 (проверка)
- LOMS пишет в Кафку изменения статусов заказов
- Сервис нотификаций должен их вычитывать и отправлять нотификации об изменениях статуса заказа (писать в телегу)
- Нотификация должна быть доставлена гарантированно и ровно один раз
- Нотификации должны доставляться в правильном порядке
Алмазик: Весь новый функционал покрыт юнит тестами плюс сам код написан таким образом, что конфигурацию для нотификаций можно задавать в конфиге и прокидывать в основную логику
Нотификации отправляют в группу по ссылке https://t.me/route255kafka
Дедлайн: 01.07.2023 (сдача) / 04.07.2023 (проверка)
- Перевести логи всех сервисов на структурные. Советую zap, но можете использовать любой другой удобный пакет. Должна быть поддержка уровней логирования.
- Покрыть все операции трейсами, настроить сбор трейсов в Jaeger, который должен подниматься в композе вместе со всеми сервисами. Должен быть доступ к веб-интерфейсу Jaeger-а.
- Настроить отдачу сервисами метрик и их сбор Прометеем, запущенным в отдельном контейнере. Обязательно иметь счетчик запросов с детализацией по хендлерам и гистограмму времени обработки запросов с детализацией по кодам ответа и хендлерам для серверов, для клиентов только гистограмму. Сделать это лучше всего через интерсепторы. Плюсом можно добавить еще метрик от себя по вкусу, например для баз данных и запросам в апи продакт-сервиса.
- 💎 На алмазик добавить в композ контейнер алерт-менеджера и настроить себе в телеграм алерты на падение сервисов и на высокое количество ошибок от запросов в сервисы.
- 💎 На алмазик сделать универсальную платформенную библиотеку, через которую удобно было бы создавать grpc-клиенты, уже обернутые метриками и базовыми трейсами, плюс удобно было бы оборачивать метриками и трейсами grpc-сервер.
- 💎 На алмазик сделать универсальную платформенную библиотеку, которой удобно было бы создават клиента к базе данных, уже обернутого метриками и трейсами. Трейс должен быть правильно наполнен данными о запросе автоматически. Метрики должны давать детализацию по разным запросам автоматически.
Дедлайн: 8 июля 23:59 (сдача) / 11 июля, 23:59 (проверка)