Comments 14
А что такое средненагруженный проект?
А что тут можно добавить, самая обычная схема, через uvicorn ещё и асинхронная. Высоконагруженные сервисы так же работают, там другие пути оптимизации.
Выглядит логично. Так же логично как то что суп надо есть ложкой, в макароны вилкой.
Redis у вас на схеме к gunicorn подключен, это как, можно подробнее? Может его к приложению надо? Балансировка у вас через nginx и несколько контейнеров бекенда – тогда зачем внутри несколько gunicorn воркеров? Можно так, можно эдак, но оба варианта сразу избыточно.
путаница
Клиентская часть (Next.js, Angular)
Фронтенд отвечает за рендеринг интерфейса и взаимодействие с сервером через API. Он развёрнут отдельно и обслуживается через Nginx. Такой подход позволяет легко масштабировать фронтенд независимо от других частей системы.
не клиентская часть а
1. Frontend-ресурсы
Скомпилированные файлы приложения: Это могут быть статические файлы (HTML, CSS, JavaScript) или файлы, генерируемые на сервере (SSR — Server-Side Rendering).
Бандлы приложения: Скомпилированные файлы JavaScript, CSS и другие ассеты (изображения, шрифты и т.д.).
Статическая генерация (SSG): В случае с Next.js, сервер может генерировать статические страницы на этапе сборки и отдавать их клиенту без дополнительной обработки.
2. Серверный рендеринг (SSR)
Next.js поддерживает SSR (Server-Side Rendering), что позволяет рендерить страницы на сервере и отправлять готовый HTML клиенту. Это может быть полезно для SEO и улучшения первоначальной загрузки страницы.
Angular Universal также поддерживает SSR, позволяя рендерить страницы на сервере.
По мере роста нагрузки наверное в такой последовательности
денормализация данных, избавляться от тяжелых join
шардирование БД
подумать про распределенный кеш - space based architecture (не пробовал)
репликация (добавить второй инстанс как приложения, так и БД + синхронизация БД)
выносить аналитику в отдельный сервис и БД с денормализацией
stateless сервисы (для начала внутри монолита)
изоляция данных внутри boundary context с сокращением сложных запросов с несколькими доменами и подготовка к разделению на микросервисы
---
На уровне бэкенда используются несколько рабочих процессов (воркеров), что позволяет обрабатывать больше запросов одновременно.
Непонятно с терминологией. Несколько инстансов? Как их синхронизировать уже придумали?
Реализуйте пет проджект и проведите тестирование нагрузкой (например с помощью яндекс танк). Потом смотрите на полученные RPS и принимайте решение подойдёт вам или нет.
О, Тостер просочился...
Из моего DevOps опыта:
Примерно так и выглядит сейчас архитектура MVP приложения, кажется что более усложнять не стоит, пока не будет показан экономический эффект
В случае если планируется какое-то масштабирование в будущем, рекомендую сразу адаптировать продукт под k8s, заказывать небольшой кластер, писать Helmfiles для развертывания представленных сервисов, также k8s позволит более гибко управлять ресурсами. Но тут конечно все зависит от Ваших ресурсов заложенных на инфраструктуру. В целом на первое время можно разворачивать данную инфраструктуру и с помощью Docker Compose на Docker Host установленном на виртуалку, проблемы начнуться при попытках масштабировать такое решение. Также рекомендовал бы задуматься о микросервисе с ролью API Gateway - очень поможет разрулировать запросы в случае увеличения кол-ва микросервисов, но также увеличит сложность и время выхода в MVP.
Инструмент для создания CI/CD пайплайна рекомендую выбирать исходя из того в каком репозитории публикуется Ваш код (GitHub - GitHub Actions, GitLab - GitLab CI/CD)
P.S. Слышал что у Redis в прошлом году изменилась лицензионная политика, если это для Вас важно стоит поискать аналог/форк.
Зачем нужен Redis?
Почему не хранить все это же в отдельной таблице Postgres?
а где в этой архитектуре находится модуль/подсистема, контролирующая бизнес процесс?
подсказка: у вас не архитектура "среднегагруженного проекта" - у вас архитектура "проекта в котором нет бизнес процессов" или они (процессы) примитивны - на уровне задач фейсбука, твиттера или вконташечки. нагрузка - это не только "тысячи примитивных рест-запросов к мьетлесс-микросервтсам", это ещё и "сотня ниток сложных бизнес процессов", которые дают вам такую же, а то и большую нагрузку.
пс: даже миллион микросервисных муравьев не вытащат из карьера промышленный бульдозер хоть сколько нибудь сложного бизнес-процесса. тут нужен другой бульдозер.
пс2: и если вы не контролируете юизнес-логику на сервере - у вас начинается утекание бизнес логики в код клиента, и в итоге вы получаете систему в которой высока вероятность "сделать запрещенное", послав запросы не в том порядке, как это предусмотрено нужным вам процессом.
Архитектура для средненагруженных приложений: делюсь опытом и ищу ваши советы