Маршрутизация клиентского подключения к указанному c экземпляру серверной части SignalR в кластере Kubernetes - PullRequest
1 голос
/ 04 августа 2020

Пытаясь создать веб-приложение для совместного рисования, я столкнулся с проблемой, касающейся Kubernetes и масштабирования. Приложение использует бэкэнд ASP. NET Core с SignalR для обмена данными чертежа между пользователями. Для масштабирования приложения я использую развертывание для каждого микросервиса системы. Однако для части SignalR требуется дополнительная конфигурация.

После некоторых исследований я узнал о возможности синхронизации c всех экземпляров серверной части SignalR либо с помощью службы Azures SignalR, либо с помощью объединительная плата Redis. Последний из которых я получил поработать в своей локальной среде minikube. Я не очень доволен этим решением по следующим причинам:

  • Меня больше всего беспокоит то, что таким образом я создал узкое место в системе. В отличие от приложения чата, где данные отправляются только время от времени, сообщения отправляются для каждых нескольких точек, нарисованных в общем интерфейсе рисования любым клиентом. Проще говоря, может возникнуть много трафика, и весь он должен проходить через единую объединительную плату Redis.

  • Кроме того, мне кажется ненужным заставлять все экземпляры бэкэнда SignalR взаимодействовать с друг друга. В этом приложении общий рисунок происходит только в небольших группах, скажем, до 10 клиентов. Группы такого размера можно легко разместить в одном экземпляре.

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

Я узнал о StatefulSets , которые позволяют мне иметь постоянный адрес для каждого модуля серверной части в кластере. Затем я мог бы каким-то образом связать идентификаторы групп SignalR с адресами модулей, на которых они работают, скажем, еще один поиск микросервиса. Проблема в том, что клиент должен иметь возможность получить доступ к нужному модулю извне кластера, где этот внутренний адрес кластера на самом деле не помогает.

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

...