Блог

Я недавно начал работать с Google PubSub и использую то же самое с Push-подпиской для передачи данных между экземплярами облачного запуска.

Во время тестирования я заметил, что в нескольких случаях между публикацией и подпиской была задержка. Поэтому я напрямую использовал вызовы API REST вместо того, чтобы отправлять их через PubSub.

Пожалуйста, помогите мне разобраться в приведенных ниже 2 пунктах:

1. Что быстрее?
2. Что является эффективным?

Спасибо тебе, Кей Кей

Прямая связь между вашими облачными экземплярами запуска по сравнению с выполнением ее через облачный Паб/Суб, скорее всего, будет иметь большее значение, чем просто то, что быстрее. В «хорошем» случае, когда и издатель, и подписчик работают и не перегружены, прямое общение, вероятно, будет быстрее.

Причины использования Pub/Sub заключаются в двух основных моментах: открытость и надежность. Для удобства обнаружения гарантируется ли, что ваш экземпляр облачного запуска для публикации всегда будет знать URL-адрес подписавшегося экземпляра облачного запуска? Всегда ли будет так, что передача данных происходит от одного к одному? Могли бы вы когда-нибудь иметь несколько экземпляров облачного запуска, которые хотели бы получать сообщения? Если да, то как вы ожидаете обновить издателя, чтобы отправлять сообщения обоим? Если вы общаетесь напрямую, вам, скорее всего, придется отправлять индивидуальные запросы каждому целевому экземпляру облачного запуска и ждать ответа от обоих. Если вы используете Cloud Pub/Sub, об этом позаботятся за вас: вашему экземпляру публикации Cloud Run достаточно отправить сообщение только один раз в Cloud Pub/Sub, и любой заинтересованный экземпляр Cloud Run будет зарегистрирован как подписка и получит все сообщения.

Другая основная причина использования Pub/Sub заключается в надежности. Что делает ваш экземпляр облачного запуска публикации, если подписывающийся экземпляр облачного запуска не работает или перегружен? Будет ли он буферизировать сообщения? Записать их в постоянное хранилище? Как он управляет этим буфером или хранилищем и, в конечном счете, повторно доставляет сообщения? Что делать, если экземпляр Cloud Run перезапустится в течение этого времени? С Cloud Pub/Sub вам, как правило, не нужно беспокоиться ни о каких из этих соображений, поскольку служба предназначена для обеспечения высокой доступности и быстрого буферизации сообщений при необходимости, не влияя на производительность издателя.

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

Но если какие-либо из этих соображений необходимо принять во внимание, то Cloud Pub/Sub будет гораздо лучшим выбором. Потенциально он будет медленнее из-за того, что он проходит несколько этапов. Вероятно, есть некоторые вещи, которые вы можете сделать, чтобы убедиться, что задержка сведена к минимуму. Двумя распространенными из них являются:

1. Убедитесь, что вы создаете экземпляр клиента издателя только один раз и повторно используете его, а не воссоздаете клиент для каждой публикации.
2. В настройках пакета издателя установите значение maxMessages равным 1, чтобы каждое сообщение отправлялось сразу после его получения по вызову publish . Если ваша пропускная способность сообщений относительно невелика, это будет полезно. Если ваша пропускная способность высока, то главное-убедиться, что вы не ждете результата синхронной публикации, особенно если вы публикуете сообщения в цикле. Ожидая асинхронно, вы сможете паковать больше сообщений вместе и, следовательно, отправлять их более эффективно.

Таким образом, на эффективный вопрос нет единого ответа. Это во многом зависит от варианта использования и желаемого поведения. Но, по всей вероятности, с точки зрения эффективности с точки зрения объема работы, которую вам придется выполнить, чтобы получить надежную доставку, Pub/Sub-лучший выбор.