Комментарии 2
Смущает, что проблему балансировки TCP вместо инкапсуляции на четвертом, мы перекладываем на седьмой. Есть ли изящное решение, которое будет удерживать вебсокет и во время деплоя новой версии приложения?
Я таких не знаю. Подобное решение можно придумать: делаем "умный" прокси, который "прячет" от клиента смену бэкенда, и сам переподключается к новым. Пока мы работаем с обычными очередями, у нас будут только две проблемы: задержки при переключении бэкендов и проблемы при обновлении самого прокси. Проблемы с потенциальной потерей сообщений можно решить на уровне типа очередей брокера (использовать гарантию at least once). С пользовательскими очередями будет сложнее, но если мы используем внешнюю схему аутентификации типа OAuth2, то тоже все будет работать. Но готовых решений такого типа я не встречал.
Просто проблема, которую я рассматриваю в статье, не в том, что мы рвем TCP-соединение с конкретным бэком при обновлении. У нас есть 2 независимых API: с клиентом вебсокет-сервера и с генератором событий. А так как API независимы, мы не можем на маршрутизаторах достичь того, чтобы сообщение автоматически попадало на нужный бэкенд. Отсюда и необходимость в брокере.
Ну, по крайней мере, в общем случае не можем такого достичь. Когда это сделать получается, рассматриваемой проблемы по сути и нет: если сообщение сразу падает на нужный бэкенд, он его может сразу переслать клиенту, брокер просто не нужен (например, если оба API основаны на REST и используют одинаковые балансировшики). Но что делать, когда, как например в рассмотренном примере, за балансировку клиентов отвечает сервис Kubernetes, а за балансировку генераторов - консюмеры AMQP-очередей?
Публикации
SpringBoot и вебсокеты: едем в кластер