Наш корпоративный чат-бот построен на микросервисной архитектуре и активно взаимодействует с клиентами через чат. В ходе разработки мы столкнулись с нетривиальной задачей: нам нужно было не только получать входящие сообщения, отправляя их в MQ (RabbitMQ) для обработки DS-ядром, но и правильно маршрутизировать ответы обратно в нужный процесс.
Ключевая сложность — долгоживущий процесс внутри микросервиса, который собирает сообщения в обоих направлениях:
— От клиента — для корректной обработки фраз, составленных из нескольких сообщений («привет», «как», «дела»).
— К клиенту — для реагирования на срочные и несрочные обращения, а также для обработки сообщений с запросом на оценку сервиса.
В условиях распределенной системы на Kubernetes процессы могут находиться на разных серверах (нодах), что делает задачу обратной маршрутизации особенно сложной. Как доставить ответ в тот же процесс, который отправил запрос, если сервисы динамически масштабируются и мигрируют между узлами?
Ранее наши коллеги рассказывали, как маршрутизация устроена в чат-системах (https://speakerdeck.com/xfenix/dvustoronnii-websocket-routingh). В этом докладе мы поделимся нашим опытом:
— Как мы решали проблему обратного роутинга в микросервисной среде.
— Как эволюционировали наши архитектурные решения и какие ошибки мы допустили.
— Какие существуют методы решения проблемы обратной маршрутизации (название придумали сами, так как тема ранее не была освещена).
Если вы работаете с микросервисами, распределенными системами и очередями сообщений — этот доклад поможет вам избежать наших ошибок и выбрать эффективные архитектурные паттерны для двустороннего роутинга.
