Двусторонний websocket-роутинг Сеть, бэкенд и web-разработка

Доклад принят в программу конференции
Денис Аникин
Райффайзенбанк

Много лет работает Python-разработчиком, верстает, делает фронтенды, занимается DevOps, до этого писал на PHP. Из интересных проектов довелось поучаствовать в разработке одной из крупнейших газет и биллинга для мобильного виртуального оператора. Ну и, конечно же, текущие проекты, над которыми Денис работает (чат-бот и чат-платформа), тоже можно отнести к интересным.
Сейчас совмещает позиции team lead и community lead Python-сообщества Райффайзенбанка.

https://github.com/xfenix/
https://www.linkedin.com/in/xfenix/
https://xfenix.ru/
Владислав Лаухин
Райффайзенбанк

Много лет разрабатывает на Python, занимается DevOps. Разрабатывал несколько интересных проектов: систему анализа сделок для Московской биржи (и не только) и один из крупнейших CDN в России.
Сейчас работает в Райффайзенбанке над чат-ботом и чат-платформой.

https://github.com/laukhin/
https://www.linkedin.com/in/laukhin/
Тезисы

С веб-сокетами на бэкенде работать не очень просто. Относительно понятно, как обрабатывать сообщения, поступающие в одном направлении, т.е. от клиента к серверу или от сервера к клиенту. Но когда возникает потребность полнодуплексного общения, еще и с асинхронным бэкендом и микросервисной архитектурой, то появляются сложности не только с роутингом во внутренние системы, но и, что важно, обратно от них к клиенту. К тому же стоит учесть, что сообщения к клиенту могут поступать не в режиме «запрос-ответ», а произвольно, т.е. в разном объеме и в разное время.

Обдумывая варианты решения проблемы, мы присматривались к centrifugo и, как оказалось, оно предоставляет надежный канал в одном направлении, но не в двух. Наш же сценарий представляет собой чат-приложение, где клиент и оператор могут отправлять друг другу сообщения в произвольное время в произвольном порядке. Это решение, конечно, основано на базе микросервисной архитектуры с использованием kafka для общения этих микросервисов.

Таким образом, мы разработали свой сервис, который устраняет проблему полнодуплексного общения клиента с сервером через веб-сокет. Полагались на то, что наше решение должно быть горизонтально масштабируемое, cloud-native и написано на современном асинхронном python. О сложностях роутинга и о том, как «прицелиться» и «попасть» в нужного пользователя сообщением, и есть наш доклад.