Итак, ваше приложение падает под нагрузкой. Нужно что-то делать, но вертикальное масштабирование дорогое, горизонтальное сложное, а кэш уже не помогает? Rate limiter спешит на помощь!

Зачем и как?

Rate limiter тарифицирует количество запросов, чтобы вашим приложением не злоупотребляли боты или реальные люди. Помните тот момент, когда вы третий раз просите прислать смс у сервиса, а вам говорят, что пришлют только через какое-то время? Или вы несколько раз вводите неверно логин и пароль, а сервис в ответ просит подождать некоторое время? Rate limiter работает по похожему принципу, но у него под капотом может много больше алгоритмов, которые мы разберём.

Какие бывают?

Вообще, rate limiter может быть внешним или внутренним. Внешний работает как прокси, принимает запрос, делает обработку, отклоняет или передаёт запрос вашему приложению.

Внутренний rate limiter расположен внутри вашего приложения, может работать как middleware.

Главное отличие в том, что внутренний может работать как библиотека на вашем языке программирования, либо вы сами можете его написать, а внешний может работать с любым стэком, особенно это актуально для приложений, которые написаны на скриптовых языках. Например, у вас приложение на php, а rate limiter написан на rust. Это даёт огромную производительность при небольших затратах.

Алгоритмы

Token Bucket

Работает так: есть ведро с токенами, оно пополняется с фиксированной скоростью, но есть потолок токенов, каждому запросу выдаётся токен. Если токенов не осталось, то есть ведро пусто, тогда запрос отклоняется.

Leaky Bucket

Тоже есть ведро, но худое, вода вытекает с постоянной скоростью. Если ведро становится полным, то есть наполняется запросами, то все лишние запросы отбрасываются.

Fixed Window

На определённый промежуток времени, окно, мы позволяем пройти определённому количество запросов, остальные отбрасываются.

Sliding Window

Отличается от предыдущего тем, что окно постоянно скользит во времени. Если Fixed Window на границах окна резко обнуляет лимит, то Sliding Window делает это плавно, двигаясь во времени, сглаживая нагрузку.

Это не все алгоритмы, но самые часто используемые, остальные вы можете разобрать сами.

А чтобы поиграть с рабочим rate limiter зайдите на мой гитхаб, я написал внешний rate limiter с этими 4 алгоритмами. Не забудьте поставить звёздочку.

После пары дней мне пришёл оффер, я также подумал пару дней и принял, предварительно договорившись, что мне понадобиться неделя, чтобы открыть ИП и расчётный счёт. Поскольку санкции актуальны, то ИП надо было открывать во внешнем контуре, выбирал между двумя странами: Грузия и Киргизия. В Грузии налог 1%, в Киргизии 2%, но поскольку я уже был в Киргизии и там остались незавершённые дела, то полетел туда. ИП открыл за день, открывают в момент обращения. С открытием расчётного счёта оказалось сложнее, большинство банков не хочет открывать счёт, если вы гражданин РФ и занимаетесь IT. В итоге открыл счёт в Doscredobank. Оглядываясь назад, понимаю, что если заранее знать все тонкости, то можно уложиться в один день - утром прилетел, сделал и вечером улетел.

Вернувшись на родину я радостный сообщил, что можем начинать работу. И начался онбординг, где неожиданно узнал, что работаем по трекеру - на свою машину надо установить тулзу, которая трекает время, активность (мышь, клавиатура), какие приложения и на какие сайты ходите, а также периодически делает скриншоты. Тогда я знатно приуныл сразу на встрече, мне стоило отказаться, но да, это тот самый эффект, когда вложил так много, что отказаться уже не можешь. Забегая вперёд скажу, что если у вас есть проблема с постоянным сменой контекста, то это может помочь, поскольку видно, что вы делаете, это держит в тонусе.

Вернёмся к проекту. Сервисы связаны между собой RabbitMQ, у некоторых отдельная БД, у кого-то базы данных нет совсем, но дублируют данные в S3 на случай сбоя, чтобы восстановить, и это также является пайплайном, то есть в одном сервисе сохранят в S3, в другом достают из S3. Используется и REST и Graphql для внешних и внутренних сервисов, для фронта и бэка. Есть своя БД с OpenStreetMap, но для гео-данных также используется несколько провайдеров. Всё это крутиться в Kubernetes. И над всем этим колдует только один разработчик, вторым был я.

Достаточно быстро я понял, что проект полумёртвый, дышит только за счёт искусственных средств. Readme давно не обновлялись, засетапить проект - уже боль, второй разработчик вместо докера всю инфру развернул локально, все его действия по сетапу нигде не описаны, пришлось потратить пару часов вместе с ним в лайве, чтобы просто запустить проект. Ну, и начались сыпаться задачи, которые я, вроде как, начал решать. Самое унизительно, помимо трекера, что "тестов мы не пишем", отлавливать баги надо из веб ui, а дебажить через REPL.

Одним утром, идя в спортзал, я отчётливо понял, что на этой работе я не буду развиваться, лишь бесконечно фиксить баги и разруливать огроменный тех. дол, сгорю и буду смотреть в стену часами.

Несомненный плюс работы контрактором в том, что вы можете разорвать трудовые отношения одним днём. Теперь у меня открыто ИП и расчётный счёт в другой стране, всё также нет работы. И самое забавное, что после отправки денег по свифту, компании вернулись деньги, но на $50 меньше, а мой банк говорит, что перевод ему не поступал и вообще, разбирайся сам.

Парам-парам-пам.

Как выглядят эндпоинты в этой статье - Создаю онлайн-сервис для чтения книг. День 4. Обработка первого запроса.

Архитектура папок теперь выглядит вот так:

Всего реализовано 38 эндпоинтов , и это еще не конец — их количество будет расти! Последний из них ощущался как будто я пробежал марафон.

Разработка дизайна 🎨

Но как делать веб без дизайна? Верно, никак! 🤔
Зайдя в Figma и подсмотрев интерфейс GitHub'а , я накидал ориентировочный дизайн страниц регистрации и входа.

Верстка 🖥️

Верстка — это немного рутинное занятие, но результат того стоит!
Могу сказать, что получилось почти идентично дизайну.

Frontend с Vue.js

Почему Vue.js ? Просто такие условия 🙃. Если бы выбор был за мной, я бы взял React .

Добавлю в решение новый проект Веб-приложение ASP.NET Core (MVC) . Стандартный шаблон создаст такие папки:

• wwwroot
  Это корневая папка для статических файлов, которые будут доступны напрямую через браузер.

• Controllers
  Папка содержит классы контроллеров, которые управляют маршрутизацией.

• Models
  Папка содержит модели данных, которые представляют сущности приложения.

• Views
  Папка содержит представления — файлы, которые отвечают за отображение HTML-страниц пользователю.

В папку wwwroot/lib добавлю клиентскую библиотеку Vue.js .

Создам новый контроллер для страниц аутентификации.

В папке Views есть еще 2 папки:

• Home

• Shared

В папку Shared добавлю новый шаблон страницы Razor с названием _LoginLayout для страниц аутентификации.

Создам папку Auth, добавив туда пустую страницу Razor с названием _ViewStart. Этот файл указывает какой шаблон будут использовать страницы.

@{

Layout = "_LoginLayout";

}

Теперь закину в wwwroot/css свой файл со стилем, который наверстал.

Логика фронтенда 🧠

Начну со страницы входа, добавив HTML-разметку, которую наверстал.

Снизу файла напишу блок скриптов:

@Section scripts {

<script src="~/lib/vue/vue.global.js"></script>

<script>

...тут будут все скрипты...

</script>

}

Пример запроса на бэкенд:

На скрине показан метод ассинхронный метод login(), в нем реализована отправка запроса на эндпоинт /auth/login, если запрос проходит успешно, я записываю Access-токен в локальное хранилище и перенаправляю пользователя на страницу по адресу /home. В противном случае я показываю ошибку пользователю.

В ответе сервера я получаю Access и Refresh токены.

• Access-токен записываю в локальное хранилище.

• Refresh-токен храню в Http-only куках для большей безопасности 🛡️.

Пример записи куки на сервере:

Здесь я записал новую куку с под названием refreshToken, и значением, равным Refresh-токену.

Вообще для чего мне Refresh-токен, если есть Access? Все очень просто, у Access-токена срок жизни 15 минут, поэтому через 15 минут его необходимо будет сгенерировать заново. Для этого как раз и понадобится Refresh-токен.

По истечению Access-токена я буду посылать на сервер запрос со своими куками. Сервер прочитает Refresh-токен из них и, если он валидный, вернет новый Access-токен.

Как это реализовано со стороны сервера:

Со стороны клиента:

При загрузке страницы сразу же срабатывает метод checkRefreshToken, далее отправляется запрос на /auth/refresh. Если сервер возвращает положительный ответ, записываю новый Access в локальное хранилище и продолжаю пользоваться сервисом.

Тестирование 🧪

Запущу бэкенд и фронтенд.

После запуска я сразу попадаю на страницу входа.

Войду в аккаунт, который я создвал еще на начальных этапах.

Если сейчас обратиться по адресу /home, меня перекинет назад на страницу авторизации.

Попробую сначала ввести неправильный пароль.

Теперь введу правильный пароль. Все сработало! Я попал на домашнюю страницу.

Зайдя в консоль разработчика, можно посмотреть локальное хранилище и найти там Access-токен.

Теперь я могу пользоваться сервисом, отправляя запросы на эндпоинты, передавая данный токен в заголовке.