Я новичок в распределенных системах, и пришел к этой проблеме, когда-то нужно было развернуть службу gRP C в kubernetes (GKE). Насколько я знаю, когда клиент инициирует rp c, он создает длительное соединение http2 и на нем мультиплексируются дальнейшие вызовы. Мне нравится отправлять / pu sh уведомления или подобные сообщения клиенту через это соединение. Если я разверну к нескольким модулям, то соединения распределяются между ними, и я не уверен, каков наилучший способ найти экземпляр, где канал зарегистрирован для клиента. Возможным решением может быть, как только пользователь инициирует соединение, сохранить ссылку на clientId и pod ip (или некоторую идентификацию) в централизованной службе, а другие pods ищут модуль и пересылают ему сообщение. Является ли что-то подобное целесообразным или для этого существует решение? Я не знаком с этим пространством, и любое предложение высоко ценится.
Редактировать: (ответ на @ mebius99)
Рассматривая вариант развертывания, я наткнулся на GKE, и другие варианты развертывания облака были ограничено из-за моего использования gRPC / http2. Спасибо за упоминание об обнаружении службы, и, возможно, вариант или услуга me sh. С помощью gRP C клиент поддерживает долгоживущее соединение с одним модулем. Итак, я хочу, чтобы каждый модуль мог запрашивать, основываясь на уникальном clientId (клиенты могут выполнять начальный вызов rp c регистра), к какому модулю он подключен, поэтому он может использовать это соединение, а также способ отправки сообщение между ними. Итак, что-то вроде того, когда я получаю регистрационный звонок от клиента, я обновляю центральный реестр о клиенте и IP-адресе pod, затем просматриваю его из любого пакета pod и forward, чтобы он далее пересылался клиенту через существующее потоковое соединение. Вы направляете меня в правильном направлении, пожалуйста, дайте мне знать, что выше возможно в контейнерной среде.
спасибо.