Разработчики мобильных 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 рекомендует несколько путей:
- MQTT-мост через Cloud Pub/Sub напрямую с собственным брокером (EMQX, HiveMQ, Mosquitto). EMQX в 2 раза выше пропускная способность по сравнению с Mosquitto при равных ресурсах.
- Партнёрские платформы — Clearblade IoT Core, Cognite. Миграция на Clearblade минимально меняет клиентский код.
- Другие облака — 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+ устройств):
- IoT-устройства публикуют телеметрию → MQTT-брокер (EMQX) → Cloud Pub/Sub (через Rule Engine).
- Cloud Function читает из Pub/Sub и пишет в Firestore.
- Мобильное приложение (Flutter/React Native) подписывается на изменения Firestore через
snapshots(). - Команды от приложения пишутся в коллекцию
commands→ Cloud Function публикует обратно в MQTT-брокер. - 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.
Сравнение архитектур
| Архитектура | Преимущества | Недостатки |
|---|---|---|
| Pub/Sub + Firestore | Простота, интеграция с Firebase Auth, реалтайм | Лимиты Firestore на запросы |
| EMQX на GKE + Pub/Sub | Rule Engine, высокая производительность | Сложнее развёртывание |
| AWS IoT Core | Готовое решение, Device Shadow | Вендор-лок, миграция |
Как выбрать MQTT-брокер для Google Cloud IoT?
| Брокер | Масштабируемость | JWT-аутентификация | Лицензия |
|---|---|---|---|
| EMQX | Высокая (2000+ подключений на инстанс) | HTTP Auth Hook | Open Source |
| HiveMQ | Высокая | Плагин | Коммерческая |
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+ устройств (температурные датчики в логистике) реализовали:
- Развернули EMQX на Cloud Run с вертикальным автоскейлингом (обрабатывает 10 000 сообщений/с).
- Настроили Rule Engine — фильтр аномалий (превышение порога температуры) с публикацией только аномалий в Pub/Sub (снижение объёма данных в 3 раза).
- Cloud Function пишет аномалии в Firestore; обычные данные — в BigQuery для аналитики.
- Мобильное приложение на Flutter подписывается на Firestore через
snapshots(). - Команды (например, «отключить питание») пишутся в
commandsи доставляются через MQTT обратно. - 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 дня.