Использование экосистемы Google Cloud и создание собственной микросервисной архитектуры

Question

Создание в экосистеме Google Cloud действительно мощно.Мне очень нравится, как вы можете загружать файлы в облачное хранилище, затем поток данных обогащает, преобразует и объединяет данные, а затем, наконец, сохраняет их в BigQuery или Cloud SQL.

У меня есть пара вопросов, которые помогут мне лучшепонимание.Если вы хотите создать продукт с большими данными, используя службы Google.

1. Когда интерфейсное веб-приложение (может быть встроено в React) отправляет файл в облачное хранилище, это может занять некоторое время.время, прежде чем он полностью обрабатывается.Клиент может захотеть просмотреть состояние файла в конвейере.Затем они могут захотеть что-то сделать с результатом по завершении.Как ожидается, что клиентские интерфейсы узнают, когда файл завершен, обработан и готов?Нужно ли им опрашивать данные откуда-нибудь?

2. Если у вас в настоящее время есть микросервисная архитектура, в которой каждый сервис выполняет свой вид обработки.Например, один может анализировать файл, другой может обрабатывать сообщения.Сервисы общаются с помощью Kafka или RabbitMQ и хранят данные в Postgres или S3.Если вы адаптируете экосистему сервисов Google, можете ли вы заменить эту микросервисную архитектуру облачным хранилищем, потоком данных, облачным SQL / Store?

Answer 1

1) Поток данных не предлагает проверку промежуточных результатов. Если веб-интерфейс хочет большего прогресса в отношении элемента, обрабатываемого в конвейере потока данных, пользовательские отчеты о ходе выполнения должны быть встроены в трубопровод.

Одна из идей - записывать обновления прогресса в таблицу приемников и выводить молекулы в разные части конвейера. То есть есть приемник BigQuery, в котором вы пишете строки, такие как ["element_idX", "PHASE-1 DONE"]. Затем внешний интерфейс может запросить эти результаты. (Я бы не стал перезаписывать старые строки лично, но многие подходы могут работать).

Вы можете сделать это, используя PCollection как в новом приемнике, так и в следующем шаге вашего конвейера.

2) Использует ли ваша микросервисная архитектура подход конвейерного стиля "Трубы и фильтры"? То есть каждый сервис читает из источника (Kafka / RabbitMQ) и записывает данные, затем следующий потребляет их?

Вероятно, лучший способ настроить несколько различных конвейеров потока данных и вывести их результаты с использованием приемника Pub / Sub или Kafka, а следующий конвейер потреблять этот приемник Pub / Sub. Вы также можете отправить их в другое место, например BigQuery / GCS, чтобы при необходимости вы могли запросить эти результаты еще раз.

Существует также возможность использовать облачные функции вместо Dataflow, которые имеют Pub / Sub и триггеры GCS . Микросервисная система может быть настроена с несколькими облачными функциями.

Answer 2

Вы смотрели на Cloud Pub / Sub (тема подписки / публикации).

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

Я считаю, что Pub / Sub в большинстве случаев может заменить Kafka или RabitMQ.

Каким образом ожидается, что клиентские клиенты узнают, когда файл завершен, обработан и готов? Нужно ли им опрашивать данные откуда-то?

Например, если вы используете API потока данных для обработки файла, поток данных Cloud может опубликовать ход выполнения и отправить статус в topic . Ваш пользовательский интерфейс (движок приложений) просто должен подписаться на эту тему и получать обновления.