Интеграция Google Cloud IoT в мобильное приложение

Разработчики мобильных IoT-приложений на GCP часто сталкиваются с необходимостью обеспечить двустороннюю связь между сотнями устройств и мобильными клиентами в реальном времени. Телеметрия с датчиков поступает с интенсивностью до 1000 сообщений в секунду, а задержка свыше 500 мс делает систему бесполезной для критических сценариев. При этом MQTT-брокер должен аутентифицировать каждое устройство без встраивания секретов в клиент. Google Cloud IoT Core упрощал задачу, но его отключение заставило искать альтернативы. Мы реализовали гибридную архитектуру на EMQX, Cloud Pub/Sub и Firestore для 20+ проектов с парком от 100 до 5000 устройств. Ниже — рабочие схемы и конкретные конфигурации, проверенные в бою. Если вам нужна надёжная IoT-инфраструктура — получите консультацию. Наши инженеры подготовят архитектуру за 2 дня.

Как интегрировать Google Cloud IoT в мобильное приложение

Ключевая задача — обеспечить двустороннюю связь между устройствами и мобильным клиентом с минимальной задержкой. Решение — гибридная архитектура на базе собственного MQTT-брокера, Cloud Pub/Sub и Firestore. Ниже разберём рабочие схемы.

Проблемы, которые решаем

• Устройства отправляют телеметрию (до 1000 сообщений в секунду), но мобильное приложение не получает её в реальном времени — задержка свыше 2 секунд неприемлема.
• Нужна обратная связь: отправить команду на устройство (например, включить клапан) с подтверждением выполнения.
• Push-уведомления о событиях не приходят или приходят с опозданием; критично для систем безопасности.
• Безопасность: встраивание Service Account ключей в клиент недопустимо — используем JWT-токены Firebase Auth.
• Миграция с готового IoT Core — страх перед вендор-локом и сложностью перехода.

Каждая проблема имеет готовое решение в GCP-стеке. Мы используем Firestore как единый шлюз между устройствами и мобильным клиентом, а MQTT-брокер — для сбора телеметрии.

Альтернативы Google Cloud IoT Core

Google рекомендует несколько путей:

1. MQTT-мост через Cloud Pub/Sub напрямую с собственным брокером (EMQX, HiveMQ, Mosquitto). EMQX в 2 раза выше пропускная способность по сравнению с Mosquitto при равных ресурсах.
2. Партнёрские платформы — Clearblade IoT Core, Cognite. Миграция на Clearblade минимально меняет клиентский код.
3. Другие облака — AWS IoT Core или Azure IoT Hub. Но если вы остаётесь в GCP, гибридная схема выгоднее на 30–50% по стоимости.

Мы чаще всего рекомендуем Cloud Pub/Sub + EMQX для клиентов, желающих остаться в GCP.

Архитектура мобильного приложения на базе GCP

Для мобильного клиента прямое подключение к Cloud Pub/Sub через gRPC требует Google Cloud credentials, которые нельзя встраивать в приложение. Используем Firebase Authentication + Cloud Firestore как транспортный слой для IoT-состояний.

Схема работы (подтверждена на парке 500+ устройств):

1. IoT-устройства публикуют телеметрию → MQTT-брокер (EMQX) → Cloud Pub/Sub (через Rule Engine).
2. Cloud Function читает из Pub/Sub и пишет в Firestore.
3. Мобильное приложение (Flutter/React Native) подписывается на изменения Firestore через snapshots().
4. Команды от приложения пишутся в коллекцию commands → Cloud Function публикует обратно в MQTT-брокер.
5. Push-уведомления о критических событиях — через FCM.

Задержка от события до обновления в приложении — менее 500 мс (в типовой конфигурации). Экономия до 40% по сравнению с прямым MQTT-шлюзом без Pub/Sub.

Flutter реализация:

FirebaseFirestore.instance .collection('devices') .doc(deviceId) .snapshots() .listen((snapshot) { final state = DeviceState.fromJson(snapshot.data()!); // обновляем UI }); 

React Native — аналогично через @react-native-firebase/firestore.

Сравнение архитектур

Как выбрать MQTT-брокер для Google Cloud IoT?

EMQX — наш выбор для продакшена: Rule Engine снижает задержки и исключает лишние Cloud Functions.

Cloud Run + MQTT для IoT

Более правильная архитектура для production: EMQX или HiveMQ на Cloud Run / GKE → Cloud Pub/Sub → Cloud Functions → Firestore. EMQX поддерживает Rule Engine (аналог AWS IoT Rules): можно прямо из брокера публиковать в Pub/Sub по условиям без отдельных Cloud Functions.

Мобильный клиент подключается к EMQX через MQTT over WebSocket с JWT-аутентификацией (выдаётся Firebase Auth). EMQX проверяет токен через HTTP Authentication hook — запрос к вашему бэкенду при каждом подключении.

Почему гибридная архитектура EMQX + Firestore выгоднее?

Чистый MQTT без Pub/Sub приводит к потере сообщений при перегрузках и сложной интеграции с мобильными клиентами. Firestore как буфер обеспечивает at-least-once доставку и упрощает отслеживание состояния. По нашим замерам, такая смешанная схема на 40% дешевле при той же нагрузке. Свяжитесь с нами для аудита вашего IoT-проекта — мы подберём оптимальную архитектуру.

Firebase Cloud Messaging для IoT-событий

Push-уведомления по IoT-событиям — нативная сильная сторона GCP-стека. Cloud Function триггерится по Pub/Sub сообщению, отправляет FCM notification через Admin SDK:

await admin.messaging().send({ token: userFcmToken, notification: { title: 'Датчик движения', body: 'Движение обнаружено в прихожей' }, data: { deviceId: '...', eventType: 'motion' } }); 

На Flutter firebase_messaging обрабатывает уведомления в background через onBackgroundMessage handler. Важно: на Android обработчик должен быть top-level функцией, не методом класса — иначе крэш при получении уведомления в killed state.

Как мы это делаем: пошаговый план

Для клиента с парком 500+ устройств (температурные датчики в логистике) реализовали:

1. Развернули EMQX на Cloud Run с вертикальным автоскейлингом (обрабатывает 10 000 сообщений/с).
2. Настроили Rule Engine — фильтр аномалий (превышение порога температуры) с публикацией только аномалий в Pub/Sub (снижение объёма данных в 3 раза).
3. Cloud Function пишет аномалии в Firestore; обычные данные — в BigQuery для аналитики.
4. Мобильное приложение на Flutter подписывается на Firestore через snapshots().
5. Команды (например, «отключить питание») пишутся в commands и доставляются через MQTT обратно.
6. Push-уведомления о критических событиях — через FCM (время доставки <1 с).

Результат: задержка от события до уведомления <500 мс, экономия 40% на облачных расходах по сравнению с предыдущей архитектурой на чистом MQTT.

Типичные ошибки при интеграции GCP IoT

• Встраивание Service Account key в IPA/APK — грубейшее нарушение безопасности. Всегда используйте Firebase Auth + JWT.
• Игнорирование лимитов Firestore: до 1 MiB на документ, до 10 000 записей в секунду на базу. Для высоконагруженных сценариев — буферизация через Pub/Sub.
• Отсутствие механизма подтверждения доставки команд. Используйте отдельную коллекцию ack в Firestore для обратной связи с устройством.

Что входит в работу и сроки

• Архитектурная документация со схемой потоков данных.
• Прототип мобильного приложения с интеграцией Firestore и FCM.
• Конфигурация MQTT-брокера (EMQX/HiveMQ) с JWT-аутентификацией через HTTP Hook.
• Настройка Cloud Pub/Sub и Cloud Functions.
• Инструкция по развёртыванию и эксплуатации.
• Обучение команды заказчика.

Сроки: базовая архитектура (MQTT-брокер + Pub/Sub + Firestore + мобильный клиент) — 3–4 недели. Добавление push-уведомлений и автоматизации на Cloud Functions — ещё 1–2 недели. Стоимость рассчитывается индивидуально, исходя из объёма сообщений и требуемых вычислительных ресурсов.

Если вы ищете надёжную IoT-инфраструктуру на GCP — получите консультацию. Наши инженеры подготовят архитектуру за 2 дня.