Получается выделить отдельно boilerplate базового приложения(в дополнение к текущему примеру там есть обвязка из раздела «А что дальше»).
А так же код из папки «modules» хорошо ложится во внешнюю библиотеку, чтобы единообразно его подтягивать во все проекты как внешнюю зависимость.
Спасибо за замечание
Возможно FastApi в будущем станет новым стандартом для асинхронных python веб сервисов, т к многие возможности предоставляет из коробки.
К сожалению я пока не получил достаточно опыта использования FastApi на нагруженных проектах в prod. Но если эксперименты с этим фреймворком не выявят узких мест — то скорее всего будем новые сервисы делать на нём
Нагруженный сервис на Python (если он выполняет простую операцию) имеет смысл переписать на C/C+
Наверное есть смысл новый сервис переписать на Go — это будет менее затратно по ресурсам(при наличии экспертизы в языке), а в скорости по сравнению с Python прирост будет значительным.
Либо «узкое горлышко» в коде переписать на Cython, без переписывания сервиса целиком.
Спасибо за статью, было интересно посмотреть все «зелёные» подходы, собранные в одном месте
помимо ускорения запросов преследовались и другие цели.
БД стала слишком объёмной, что сказывалось на скорости разворачивания дампов и проведения технических работ. Ретроданные нужны только для аналитиков и аудиторов, для текущей работы приложения достаточно данных за текущий год. Поэтому было принято решение об «архивировании» данных, т к облегчалась эксплуатация текущих таблиц, а архивные таблицы можно перенести в отдельную бд
alexey_and_kazakov у нас в проекте через реббит ретраи организованы с помощью следущего механизма:
если сообщение нужно исключить из очереди(возникла ошибка) — то оно попадёт в другую очередь с ttl и увеличенным на один счётчиком ретраев. через время из ttl очереди оно вернётся в основную. если же счётчик ретраев превышает какое то значение — то сообщение попадает в очередь отстойник для дальнейшего изучения. На очередь отстойник стоят алерты с нотификацией в телеграм
т е разница с описанной выше схемой — что есть третья очередь для разбора почему сообщение не получается обработать консюмером(причина — либо долго лежат другие сервисы, либо ошибка в коде. в обоих случаях сообщение можно вернуть в основную очередь после фикса)
А так же код из папки «modules» хорошо ложится во внешнюю библиотеку, чтобы единообразно его подтягивать во все проекты как внешнюю зависимость.
В базовой библиотеке оставил Integer для упрощения понимания концепта
Возможно FastApi в будущем станет новым стандартом для асинхронных python веб сервисов, т к многие возможности предоставляет из коробки.
К сожалению я пока не получил достаточно опыта использования FastApi на нагруженных проектах в prod. Но если эксперименты с этим фреймворком не выявят узких мест — то скорее всего будем новые сервисы делать на нём
Наверное есть смысл новый сервис переписать на Go — это будет менее затратно по ресурсам(при наличии экспертизы в языке), а в скорости по сравнению с Python прирост будет значительным.
Либо «узкое горлышко» в коде переписать на Cython, без переписывания сервиса целиком.
Спасибо за статью, было интересно посмотреть все «зелёные» подходы, собранные в одном месте
БД стала слишком объёмной, что сказывалось на скорости разворачивания дампов и проведения технических работ. Ретроданные нужны только для аналитиков и аудиторов, для текущей работы приложения достаточно данных за текущий год. Поэтому было принято решение об «архивировании» данных, т к облегчалась эксплуатация текущих таблиц, а архивные таблицы можно перенести в отдельную бд
если сообщение нужно исключить из очереди(возникла ошибка) — то оно попадёт в другую очередь с ttl и увеличенным на один счётчиком ретраев. через время из ttl очереди оно вернётся в основную. если же счётчик ретраев превышает какое то значение — то сообщение попадает в очередь отстойник для дальнейшего изучения. На очередь отстойник стоят алерты с нотификацией в телеграм
т е разница с описанной выше схемой — что есть третья очередь для разбора почему сообщение не получается обработать консюмером(причина — либо долго лежат другие сервисы, либо ошибка в коде. в обоих случаях сообщение можно вернуть в основную очередь после фикса)