Комментарии 15
всё-таки для этого нужен определённый талант - накатать такую простыню, при этом ничего конкретно не сказав. что на бэкенде? почему? какие js-библиотеки нужны для того, чтобы выбрать ответ из списка? столько вопросов...
Алиса, я им десять часов говорил, но так ничего и не сказал.
что на бэкенде? почему?
В 2023 еще важен стек на бекенде?) С таким же успехом там могло быть что угодно, в данном случае php + laravel просто потому что коллегам из компании этот стек хорошо знаком.
какие js-библиотеки нужны для того, чтобы выбрать ответ из списка?
На фронтенд можно было притащить десяток библиотек, но мы обошлись лишь react'ом и парой утилитарных вещей типо inputmask или jspdf. Остальное кастом, чтобы следовать дизайну.
всего 1,5 для реализации сайта
Полтора землекопа?
Какой был общий расход в рублях?
Обычно стоимость решения является самым важным фактором, который определяет, есть ли деньги на оплату этого варианта.
Дайте угадаю, фин. грамотность в районе 0?
Там хотя бы сотня РПС в прыжке была?
Это можно делать как угодно и на чем угодно. С учетом одноразовости наверно на Питоне стоит. Базы и все остальное просто не нужно. Все влезет в инмемори мапу. Результаты писать в Кафку, если есть опасения (у меня их нет) по нагрузке. И дальше асинхронно разбирать и писать в любой ОЛАП по вкусу спокойно.
В этом проекте мы использовали методологию 12-факторного приложения
Хорошо хоть не под трёхфаным напряжением)). Можете уточнить как методология стала приложением?
Это значит, что база данных (БД), кэш и пользовательские сессии представляют собой подключаемые к бэкенду ресурсы.
Разве базы данных бэкенда (SQL и noSQL), менеджеры очередей (у вас их нет, но всё же) не являются неотъемлимой частью бэкенда?
Балансировщики нагрузки распределяют пользовательский трафик на пул бэкендов.
В 12 factors нет ни слова об этом. И чтобы нормально заработало горизонтальное масштабирование, часто надо выполнить ряд иных условий.
CDN и кэширование часто используемых элементов сайта. Это помогает: Снизить нагрузку на бекенд, увеличивая эффективность обработки бизнес-логики
У вас статику бэкенд отдаёт? Обычно для кэширования статики используется CDN.
Если говорить в контексте балансировки нагрузки, то у нас имеется веб-сервер, принимающий пользовательские запросы. На него приходил основной трафик, который обрабатывался либо с помощью кэша, либо за счет проксирования этого запроса на бэкенд.
Тут какая-то неразбериха. Есть веб сервер, он принимает запросы, если надо обрабатывает и отдаёт их бэкенду (у тебя он проксирует на бэкенд) -- здесь всё стандартно. Зачем на него заварачивать ещё кэшированный трафик (с CDN???)?
Пиковая посещаемость — 425 000 пользователей за день
Даже если такое количество пользователей в час будет не так уже много. Около 120 rps.
Хорошо хоть не под трёхфаным напряжением)). Можете уточнить как методология стала приложением?
Это просто явный перевод названия методологии, не стал оставлять англицизмом, на мой взгляд "методология 12-факторного приложения" эквивалентна официальному переводу как "приложение двенадцати факторов - методология ..."
Разве базы данных бэкенда (SQL и noSQL), менеджеры очередей (у вас их нет, но всё же) не являются неотъемлимой частью бэкенда?
Тут смотря что рассматривать, если бэкенд в целом, то вы правы, если структуру самого бэкенда, то отдельно есть серверный код, который работает условно на сервере приложений и дополнительные ресурсы по отношению к этому инстансу в лице бд, кеша, хранилища, иногда внешних api и т.д.
В 12 factors нет ни слова об этом. И чтобы нормально заработало горизонтальное масштабирование, часто надо выполнить ряд иных условий.
Самособой, это относится уже к непосредственной реализации. Методология задает лишь необходимые факторы, чтобы это было возможно.
У вас статику бэкенд отдаёт? Обычно для кэширования статики используется CDN.
Сама статика отдается с CDN, но запрос из браузера всё равно должен долететь до бекенда, чтобы получить ссылки на актуальные ресурсы.
Тут какая-то неразбериха. Есть веб сервер, он принимает запросы, если надо обрабатывает и отдаёт их бэкенду (у тебя он проксирует на бэкенд) -- здесь всё стандартно. Зачем на него заварачивать ещё кэшированный трафик (с CDN???)?
Кешированный трафик на него не заворачивается, запрос приходит стандартно на веб-сервер (фронтенд прокси в лице nginx), ответ отдается либо из локального кеша, либо проксируется дальше. Если ответом от бека является html-ка, то она кладется в локальный кеш фронтенд прокси и отдается клиентам напрямую, не долетая в последствии до бекенда. Внутри этой html-ки ссылки на ресурсы ведут на CDN и браузерные клиенты запрашивают ресурсы оттуда.
Даже если такое количество пользователей в час будет не так уже много. Около 120 rps.
Дневная нагрузка действительно не очень большая. Проблема только в пиках. До бекенда иногда прилетало чистых 1400 rps, что тоже не очень много, но к этому надо быть готовым.
Это просто явный перевод названия методологии
Больше похоже на подгонку по звучанию без попыток понять. Приложения, разработанные согласно положения методологии 12 factors. Не помню такого, чтобы приложения разработанные согласно методологии SOLID называли солидными))
Тут смотря что рассматривать, если бэкенд в целом, то вы правы, если структуру самого бэкенда, то отдельно есть серверный код, который работает условно на сервере приложений и дополнительные ресурсы по отношению к этому инстансу в лице бд, кеша, хранилища, иногда внешних api и т.д.
А что тут смотреть? Есть веб сервер. И суть его дихотомии проста. Существует фронтенд и существует бэкенд. При желании притянуть козу на лозу, можно туда впихнуть хранилища для резервных копий, систему мониторинга и аналитики, да много чего ещё. Только обычно перечисленное много чего ещё не касаются при рассмотрении веб сервера. И, кстати, если есть т. н. серверный код, что тогда несерверный?
Методология задает лишь необходимые факторы, чтобы это было возможно.
Если в методологии нет ни слова про балансировщики, зачем их приплетать?
запрос из браузера всё равно должен долететь до бекенда, чтобы получить ссылки на актуальные ресурсы
Если читать первоначальный текст: "CDN и кэширование часто используемых элементов сайта. Это помогает: Снизить нагрузку на бекенд" - то получается картина, что первоначально элемент берётся с бэкенда и когда к нему часто обращаются, он помещается в CDN, откуда отдаётся потом.
запрос приходит стандартно на веб-сервер (фронтенд прокси в лице nginx), ответ отдается либо из локального кеша, либо проксируется дальше. Если ответом от бека является html-ка, то она кладется в локальный кеш фронтенд прокси и отдается клиентам напрямую, не долетая в последствии до бекенда. Внутри этой html-ки ссылки на ресурсы ведут на CDN и браузерные клиенты запрашивают ресурсы оттуда.
Почему сразу нельзя отдавать данные из CDN и зачем городить локальный кэш? Всю статику в хранилище (у вас там данных с гулькин нос), статические данные из хранилища отдавать через CDN.
Я правильно поняла, что сайт финзачета 2021 тоже ваша компания делала? Сайты 21 и 22 годов принципиально отличались с точки зрения бэкенда или еще с какой-то точки зрения? Или вы просто взяли сайт 21 года и поменяли фронт и это заняло 1.5 месяца?
Кстати, на офф. сайте написано, что зачет прошли 1 390 242 человека. Зачем использовать приближенные значения, если доступна официальная статистика?! Приближение в +- 100 тыс. человек - это как-то многовато.
Мне кажется у вас в маркированный список четвертый пункт не попал, либо я не поняла к чему относится Уровень сложности.
Уровня образования
Уровня сложности.
Как за 1,5 месяца создать сайт с нуля и подготовить его к нагрузкам ~230 000 пользователей в день? Кейс Финзачета