Новый бэкенд для сервиса вызова эвакуаторов по Москве и области: заявки из приложения и колл-центра, несколько сотен машин партнёров и поток GPS-координат. Шина событий здесь Apache Kafka, основные сервисы написаны на Golang, обработка координат на Rust, а старый расчёт тарифа на Scala остался как был. Всё это сделал Евгений Росляков. Серверную часть сервисов он пишет с 2016 года, он самозанятый, заключает договор до начала работ и отдаёт юрлицам закрывающие документы. Живёт в Москве, а проекты ведёт и удалённо.
На каждой машине стоит GPS-трекер, и точка от него приходит раз в несколько секунд. Умножьте на сотни эвакуаторов, и получится постоянный шквал мелких сообщений. Параллельно идут заявки: кто-то звонит в колл-центр, кто-то нажимает кнопку в приложении.
Всё это держал монолит на PHP. Пока машин было мало, хватало. Потом парк вырос, и монолит стал захлёбываться. Ближайшего эвакуатора система искала минутами. В часы пик заявки терялись, а иногда одну и ту же получали сразу два водителя, и один ехал зря.
Диспетчеры смотрели на карту, где машины стояли там, где были полчаса назад, и обзванивали водителей. Клиент ждал, партнёры злились, часть заказов уходила конкурентам.
Остановить сервис даже на день нельзя: он работает круглосуточно. Нужно было построить новый бэкенд, который выдержит пик, и дойти до него по частям, не потеряв ни одной заявки.
Архитектура решений шла первой, до кода. Я нарисовал схему сервисов и разобрал, что случится при отказах: упала диспетчеризация, замолчал трекер, обработчик получил одно событие дважды. Каждое решение записал коротко, с причиной: почему так, а не иначе. Заказчик читает эти записи сам и понимает, за что платит.
Apache Kafka стала общей шиной. Координаты идут в один топик, ключом служит машина, поэтому точки одной машины читаются строго по порядку. События заказа идут в другой топик с ключом «заказ». Сообщения хранятся в топике, так что обработчик, который ошибся или был выключен, может прочитать их заново. Сами обработчики сделаны идемпотентными: повторное событие не меняет результат. Поэтому один заказ не уйдёт двум водителям.
Приём заказов, диспетчеризацию и API для приложений написал на Golang. Код простой, сервис стартует быстро, а поддерживать его сможет любой разработчик, не только я.
Rust взял точечно. Он работает в сервисе, который читает поток координат, отсекает шум («прыгнувшую» на километр машину), хранит актуальное положение каждого эвакуатора и проверяет геозоны. Здесь важны задержки и память, а в Rust нет сборщика мусора, способного вдруг встать на паузу. Всё остальное на нём писать не стал: сложность оправдана только в одном месте.
Расчёт тарифа и времени подачи несколько лет назад написал прежний разработчик на Scala. Формулы там непростые, но считает он верно. Переписывать его значило бы рисковать без выгоды. Логику я не трогал, а подключил сервис к Kafka: он читает события заказа и возвращает расчёт.
Языков три по делу, а не из любви к новому. Go по умолчанию, Rust в одном месте, Scala потому, что код уже есть и работает.
Переносил поэтапно, старый и новый контуры работали рядом. Сначала новый получал копию потока и только считал, диспетчеры сравнивали его ответы со старыми. Потом функции переключали по одной, и вернуться назад можно было в любой момент.
Диспетчеры видят машины на карте в реальном времени и выбирают ближайшую, не обзванивая водителей. Назначение занимает секунды вместо минут.
Двойных назначений нет. Заявки не пропадают в часы пик: когда сервис перегружен, события ждут в Kafka и разбираются, как только освободятся ресурсы. Раньше они просто терялись. Отказ одного сервиса не роняет остальные, это проверили на учебных отключениях, а не на живых клиентах.
Записи о решениях лежат в репозитории рядом с кодом. Новый разработчик читает их и видит, почему система устроена так.
Старый монолит пока не выключен. В нём остались личные кабинеты партнёров и бухгалтерские выгрузки. Они работают, нагрузки от них почти нет, и переносить их в спешке незачем. Эту часть можно двигать спокойно, когда дойдут руки.
Дальше заказчик хочет прогноз спроса по районам, чтобы заранее отправлять машины туда, где вечером будет много заявок. Данные для этого уже копятся в Kafka, осталось выбрать модель.
Если бэкенд захлёбывается от потока данных с машин, курьеров или датчиков, напишите мне здесь, на freelance.ru: сколько событий в секунду приходит и в каком месте всё ломается. Отвечу, что вынести первым, и набросаю схему.
