Взаимодействие приложения такси с сервером в реальном времени, какие протоколы и технологии использовать?

Question

[Александр]

1)Нужно чтобы такси в реальном времени отправляли местоположение на сервер,
2) Когда появляется новый заказ, необходимо всем таксистам отправить в реальном времени

Вариант которые пришли мне в голову
1) Websocket
2) Nats brocker или RabbitMq, но подключать их напрямую из клиента андроид такси выглядит небезопасно

Какие технологии, протоколы лучше использовать ? В данный момент есть приложение на Андроид и Серверное веб приложение, нужно связать их общение

Comments

[szQocks]

сокеты и очереди подойдут для этой задачи

[Александр]

szQocks, обычные TCP сокеты или вебсокеты, которые поверх них ?

[szQocks]

Александр, сокеты разве не используют tcp ? socket.io или websocket подойдут

[szQocks]

Александр, я бы заюзал socket.io + парсер socket.io-msgpack-parser и не парился бы, отслеживал бы каждую секунду каждую машину ( синхронизировал бы данные с сервером каждую секунду

[Александр]

szQocks, есть обычный tcp сокет, когда устанавливается соединение, а поверх уже можно слать данные как угодно, но нужно согласовать некий протокол, чтобы взаимодействовать с другими приложениями

[Александр]

szQocks, ну это да, но нужно придумать ещё как сохранять данные в редис, базу данных и прочее, если делать прямо в вебсокете, то на 20 тысяч соединений упадёт

[szQocks]

Александр, к примеру ты таксист, ты вышел на смену, нажал на кнопку - начать смену, и каждую секунду отправляешь по сокетам своё местоположении на сервер, на сервер когда прилетает это сообщение, создаётся задача - всё, дальше логика думаю будет понятна, что любой свободный инстанс/сервис забирает эту задачу и выполняет её тем самым обновляет информацию на всеобщей карте

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

[szQocks]

Александр, если не до конца понял к чему я это написал, то на каждом инстансе будет своё кол-во подключенных пользователей, то есть там не должно быть такого что 20к будут на одном

[Александр]

szQocks, совсем не понимаю о чём речь((( Пользователь отправил своё местоположение, оно пришло мне в вебсокет. Теперь мне надо разослать это соощение в микросервисы мои, один на python, другой elixir. Потэому я и был вопрос про брокеры

[szQocks]

Александр, тогда тебе потребуется просто создавать 2 задачи, одна для python другая для elixir ( когда с клиента на сервер поступает инфа о местоположении машины )

я всего лишь попытался описать поверхностно о том как примерно работать это могло бы

[szQocks]

Александр, задачи я и имею ввиду брокеры ( брокер создаёт задачу и помещает в очередь, работники - могут быть сервисы разные типа там python, elixir как у тебя, которые могут взять задачу и выполнить её ), если правильно я тебя понял, просто есть брокеры задач, брокеры сообщений ( вещаний ), но да ладно

[Александр]

szQocks, спасибо за дискуссию, возможно так и сделаю socket.io + брокер

[szQocks]

Александр, только там надо сделать так что бы сервер об изменении машин всех, вещал каждую секунду всем пользователям которые просматривают эту карту

если вещать изменения при каждом запросе с клиента юзера, то это будет не очень оптимизированное решение

грубо говоря, вещаем изменения накопленные в течении секунды, а не на каждый чих юзеров

[szQocks]

Александр, можно даже ещё оптимизировать

с клиента отправлять на сервер не постоянно каждую секунду, как только он вышел на смену
а начинать отправлять каждую секунду лишь только тогда - когда локация хоть чуть чуть изменилась + водитель находился в состоянии работы ( то есть на смене / в состоянии работы ), то есть не на паузе

если быть ещё точнее, то отправлять инфу на сервер лишь тогда, когда водитель был в состоянии работы + локация изменилась на сколько то ( сверяя с прошлой локацией ) + прошла секунда с предыдущей отправки данных на сервер, о своём местоположении

Answer 1

[rPman]

Это как сравнивать тарелку и посудомойку, ну несравнимые вещи, которые могут существовать вместе.

Наружу выпускать лучше только http, а это значит Websocket или http/3 WebTransport, особенно если подразумевается браузерный клиент (есть еще webrtc но он тут не нужен).

На сервере обработку очередей ты можешь организовывать как тебе угодно. Можешь и RabbitMq брать, но не вижу особого в этом смысла.

По твоему ТЗ (оно скорее всего не полно, но маловероятно что будет что то значимое) у тебя нет особой сложности в разработке... особенно если нагрузка предполагается не высокая, которую способен потянуть один сервер, т.е. одно приложение, которое не нужно делить на ноды, реализовывать их добавление или замену на лету от нагрузки и т.п... но даже в этом случае, я точно помню были готовые брокеры, встраиваемые прямо в веб сервер nginx как прослойка между бакэндом и клиентами, бегло погуглил, есть https://nchan.io .

Comments

[Александр]

Ну я почитал как работает Uber, они отправляют через Websocket, дальше у них стоит слой Kafka

[Александр]

rPman брокер сообщения мне нужен, чтобы взаимодействовать с другими сервисами, если я буду напрямую в Websocket делать кучу операций, это замедлит поток

Answer 2

[VoidVolker]

Веб-сокеты плюс любой бинарный сериализатор плюс какое-нибудь шифрование поверх в рамках ваших требований: bson, protobuf и прочее что-то популярное (непопулярное - устанете искать адекватную либу). Гнать текстовый трафик через мобильные сети не самое лучше решение, а шифрование надо просто чтобы осложнить жизнь любителям всяких манипуляций и взломов.

Comments

[Александр]

VoidVolker спасибо, ещё стоит вопрос как работать за вебсокетами. Мне нужно сохранять и обрабатыывть данные, если делать напрямую в вебсокете, я буду тормозить поток. Поэтому я думал использовать брокер

[VoidVolker]

Александр, точно так же как в любым сетевым соединением: есть сервер, есть клиент, между ними есть соединение, которое может оборваться в любой момент времени и всякое такое. Для этого используются готовые библиотеки. Как именно - смотрите в документации библиотек.

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

Веб-Сокеты - это протокол, а не что-то, внутри чего можно что-то делать или вычислять. Скорость обработки соединений и переданных по ним данных зависят от кода, который это всё обрабатывает. Если вам так важны миллисекунды на обработке некоего вашего потока, тогда используйте голые сокеты в вашем приложении с любым бинарным сериализатором без дополнительных протоколов поверх, а так же используйте C/C++/Rust и прочие компилируемые быстрые языки для обработки ваших данных. Кроме того, судя по описанию вашей задачи несколько миллисекунд на работу никак не повлияет на ваши процессы.

Поэтому я думал использовать брокер

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

Answer 3

[Zanak]

1. А зачем отслеживать местоположение такси? Пусть таксист сам, когда готов, или за пару минут до того, автоматически, с известной периодичностью, стучится на сервер запросом, типа: "я здесь, ..., ищу заказ, чего есть". Сервис вычисляет расстояние до активных клиентов и кидает варианты о тех, например, до кого менее 3 километров. Такси, чей аппарат выключен, или находится в пути, не тратится на интернет и не создает ненужной нагрузки на сервере.
2. Новый заказ должен попадать тем, кто может его взять сейчас, или через несколько минут, разве нет?

Протоколы обмена и способы хранения данных на сервере могут быть почти любые, http/rest/websocket, на чистых sql базах, или какой нибудь nosql, с очередями или без. Чего лучше знаешь, то и используй, кмк.

Comments

[Александр]

Вы не видели сервисы такси ? Клиент в приложении включает показать такси в радиусе 5км, и он видит все такси. И когда он делает заказ, то только эти водители получат сообщение о заказа, что он доступен

[Zanak]

Видел. Когда я запускаю программу такси, меня интересует время ожидания, количество мест, если нас больше чем один и опции, вроде детского кресла, оценка, если она совсем в районе плинтуса. Остальное мало важно.
Я больше про то, что каждое твое желание имеет свою цену в ресурсах.
Например, ты хочешь каждую секунду знать, где находится конкретная машина, независимо от того, везет водитель клиента, стоит в пробке, пошел в кафе покушать или просто спит - я уточняю, зачем это нужно. Все варианты нужно отслеживать и адекватно на них реагировать, а их, даже в общении с водителями может быть масса, кмк. Не проще разделить логику работы с водителем и клиентом? Водитель видит все заказы с ранжиром по расстоянию/времени от его текущего места, клиент, по степени соответствия его запросу по характеристикам авто и времени на ожидание (просто, с какого - то момента, клиент, скорее всего, перестанет просматривать варианты авто и уйдет к другому оператору, поэтому, в начале и должны быть те, кто точно имеет шанс забрать этот заказ, а не тот, у кого есть время нажать по кнопкам).

Впрочем, на вопрос я ответил в начале: стоит, кмк, использовать инструменты, которые лучше всего знаешь, задача не на столько сложна, чтобы городить огород на ровном месте.

[szQocks]

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

[szQocks]

Zanak,

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

я в комментариях написал как это можно оптимизировать ( нагрузку на сервер ), и если сделать так как я написал то получиться что если машина стоит на месте то она не будет отправлять запросы на сервер, лишь только когда водитель в пути + выполняет заказ