# #node.js #express #google-cloud-run
Вопрос:
У нас есть несколько облачных сервисов Google, работающих по API. Существует одна родительская служба и несколько дочерних служб. Когда родительская служба запускается, она загружает схему из всех дочерних элементов.
В настоящее время нет способа сообщить родительскому процессу о перезагрузке схемы, поэтому при развертывании нового дочернего элемента родительскую службу необходимо перезапустить, чтобы перезагрузить схему.
Мы понимаем, что существует 1 или более экземпляров Google Cloud Run, и у нас есть идеи по решению этой проблемы, но нам интересно, есть ли вообще способ перезапустить родительский процесс. Без способа его достижения один или несколько на данный момент не имеют значения. Единственный способ найти его-развернуть родителя, что кажется излишним.
Контейнеры, работающие в google cloud, — это Alpine Linux с Nodejs, в которых запущено экспресс-приложение/промежуточное программное обеспечение. Я могу остановить запуск приложения узла, но не перезапускать его. Если я остановлю службу, Google Cloud Run может по-прежнему продолжать обслуживать трафик в эти экземпляры, вызывая ошибки.
Возможно, я смогу остановить экспресс-службу, чтобы Google Cloud run заменил этот экземпляр? Есть ли такая возможность? Есть ли изящный способ сделать это так, чтобы он сначала пытался выполнить и текущие запросы (а не просто убить экспресс)?
Ищете какие-либо подходы к принудительному запуску Google Cloud для перезапуска или запуска новых экземпляров. Мысли?
Комментарии:
1. Запускаются ли дочерние службы внутри одного и того же контейнера (как на этой диаграмме gist.githubusercontent.com/igponce/… ) ?
2. Если файл схемы имеет решающее значение для запуска служб, вероятно, вам необходимо включить его в контейнер, в котором выполняется служба. Возможно, запустить для них облачную сборку при изменении файла, а затем повторно развернуть облачные службы запуска.
3. Спасибо вам за идею. Схема динамична для всех дочерних элементов и не принадлежит контейнеру.
4. Нет, каждый дочерний элемент работает в своем собственном контейнере как отдельный микросервис
Ответ №1:
Ваш дизайн, по-видимому, на высоком уровне представляет собой систему кэширования: родительская служба получает данные от дочерней службы и кэширует данные.
Таким образом, у вас есть все трудности с управлением кэшем, особенно с признанием кэша недействительным. Для этого нет простого решения, но я рекомендую использовать хранилище памяти, где все дочерние службы публикуют номер последней версии своей схемы (например, при запуске контейнера). Затем родительская служба проверяет (например, при каждом запросе) состояние в хранилище памяти (задержка в мс с одной цифрой), доступна ли новая версия not. Если новый, запросите дочернюю службу и обновите кэш схемы родительской службы.
Если это применимо, вы также можете установить TTL в своем кэше и, например, перезагружать его каждую минуту.
ПРАВКА 1
Если я сосредоточусь только на облачном запуске, вы можете только при одном условии перезапустить контейнер без развертывания новой версии: установите параметр max-instance равным 1 и реализуйте конечную точку выхода (просто сделайте os.exit() или аналогично в своем коде).
Хорошо, вы теряете всю масштабируемую емкость, но это единственный случай, когда с помощью специальной конечной точки выхода вы можете выйти из контейнера и заставить Cloud Run перезагрузить его при следующем запросе.
Если у вас более 1 экземпляра, вы не сможете перезапустить все запущенные экземпляры, но только этот, который обрабатывает запрос «выход».
Поэтому единственным решением является развертывание новой редакции (просто развертывание без изменения кода/конфигурации).
Комментарии:
1. Я действительно ценю ваш ответ! Я намеренно опустил детали приложения, так как хотел сосредоточиться на запуске Google Cloud, и если есть способ перезагрузить контейнер, следовательно, перезапустите службу. Поскольку нам, разработчикам, всегда нужны подробности, это конфигурация объединенного API GraphQL. Родитель-это шлюз, а дочерние элементы-конечные точки подграфа. Единственный способ обновить схему шлюзов-это опрос, который я действительно не хочу выполнять в Google Cloud.
2. Отлично, спасибо за редактирование. Если бы у нас был способ перезапустить процесс или контейнер из базы кода, чтобы получить все экземпляры, о которых можно было подумать, используя pub/sub, на которые все экземпляры подписались бы при запуске, и все могли бы сбросить, если бы пришло сообщение, которое проинструктировало его.
3. Это может сработать или нет, никакой гарантии. Во-первых, потому что вам нужно создать подписку на получение для каждого экземпляра. Здесь нет проблем, за исключением холодного запуска и очистки для управления (создайте подписку на получение при запуске и удалите ее, когда получите сигнал об отключении). Проблема связана с облачным запуском: для вашего процесса простоя не выделен (или очень мало) ЦП, и, следовательно, подключение по запросу может быть потеряно в любое время. И если сообщение опубликовано, оно может не быть обработано. Гарантии нет, но это может сработать
4. Да, я не думал, что подписка на вытягивание, опрос и запуск в облаке-не очень хорошее сочетание. Я вижу, что толчок не сработает, так как для каждого экземпляра нет уникальной конечной точки. Спасибо, полезный комментарий, чтобы прояснить мои мысли.
5. Имейте в виду свою идею, она может сработать к концу года 😉 И оставайтесь с нами!