Wenn Sie nach einer Google Cloud IoT Core Alternative suchen, migrieren Sie entweder eine Geräteflotte, die durch die Abschaltung gestrandet ist, oder Sie planen ein neues Projekt auf Google Cloud ohne nativen Geräte-Gateway. Dieser Leitfaden erklärt, was IoT Core geleistet hat, vergleicht die realistischen Ersatzoptionen fair, überträgt IoT-Core-Konzepte auf Standard-MQTT und führt Sie durch den Umzug von Geräten zu einem verwalteten MQTT-Broker, während Ihre Daten weiter in Google-Cloud-Dienste fließen.
Was mit Google Cloud IoT Core passiert ist
Google kündigte 2022 an, Cloud IoT Core einzustellen, und der Dienst wurde am 16. August 2023 abgeschaltet. Seit diesem Datum können sich Geräte nicht mehr mit seinen MQTT- und HTTP-Bridges verbinden. Google hat keinen direkten Nachfolger eingeführt, sondern Kunden auf Partnerlösungen und auf den Aufbau mit allgemeinen Google-Cloud-Diensten verwiesen. Andere Google-Cloud-Produkte wie Pub/Sub, Dataflow und BigQuery waren nicht betroffen und bleiben gängige Ziele für IoT-Daten.
IoT Core vereinte drei Funktionen, und jede braucht einen Ersatz:
- Geräteanbindung: ein MQTT-Endpunkt unter
mqtt.googleapis.comauf Port 8883 (und 443). - Geräteregistrierung und Authentifizierung: Geräte wurden über lange Client IDs der Form
projects/PROJECT/locations/REGION/registries/REGISTRY/devices/DEVICEidentifiziert und mit einem JWT authentifiziert, das mit einem gerätespezifischen privaten Schlüssel signiert und als MQTT-Passwort gesendet wurde. - Datenrouting: An
/devices/DEVICE_ID/eventspublizierte Telemetrie wurde an Pub/Sub-Topics weitergeleitet; Konfiguration und Befehle kamen über/devices/DEVICE_ID/configund/devices/DEVICE_ID/commands/#herunter, und der Gerätezustand ging über/devices/DEVICE_ID/statehinauf.
Optionen für eine Google Cloud IoT Core Alternative im Vergleich
Es gibt nicht die eine richtige Antwort. Der beste Ersatz hängt davon ab, wie intensiv Sie IoT-Core-Funktionen genutzt haben und wo Ihre Daten liegen sollen.
| Option | Was Sie bekommen | Passend, wenn | Nachteile |
|---|---|---|---|
| Verwalteter MQTT-Broker (etwa ConnectMQ) | Standard-MQTT-Endpunkt, Zugangsdaten, Konsole | Sie reines, portables MQTT wollen und die Verarbeitung in Google Cloud behalten | Sie ergänzen einen kleinen Weiterleitungsdienst zu Pub/Sub |
| IoT-Dienst eines anderen Hyperscalers (AWS IoT Core, Azure IoT Hub oder Event Grid MQTT) | Geräteregistrierung, Regeln, tiefe Integration in diese Cloud | Sie bereit sind, die Verarbeitung in diese Cloud zu verlagern | Proprietäre Topic-Konventionen und Cloud-übergreifender Datentransfer |
| Bei der Abschaltung empfohlene Partnerplattformen | Teilweise IoT-Core-kompatible APIs | Sie möglichst wenige Änderungen an den Geräten wollen | Eine weitere herstellerspezifische API als Abhängigkeit |
| Selbst gehosteter Broker auf GKE oder Compute Engine | Volle Kontrolle, Open-Source-Optionen | Sie Betriebskapazität haben | Patches, Skalierung, Zertifikate und Rufbereitschaft liegen bei Ihnen |
| IoT-Anwendungsplattformen | Dashboards, Geräteverwaltung, Regeln | Sie eine vollständige Anwendungsschicht brauchen, nicht nur Transport | Schwergewichtiger, oft mit festen Vorgaben |
Jede Option ist legitim. IoT-Dienste der Hyperscaler bieten umfangreiche Regel-Engines und Integrationen; Partnerplattformen können Firmware-Änderungen reduzieren; Selbsthosting bietet maximale Kontrolle. Ein verwalteter MQTT-Broker liegt in der Mitte: Standardprotokoll, minimaler Lock-in und keine Server, die Sie betreiben müssen, dafür bauen Sie die Weiterleitung in Google Cloud selbst. Einen breiteren Vergleich der Hyperscaler-Dienste finden Sie in unserem Leitfaden zur AWS IoT Core Alternative.
IoT-Core-Konzepte auf reines MQTT übertragen
Der Wechsel zu einem Standard-Broker ist größtenteils eine Übersetzungsaufgabe:
| IoT-Core-Konzept | Standard-MQTT-Entsprechung bei ConnectMQ |
|---|---|
mqtt.googleapis.com:8883 |
broker.connectmq.com:8883 (TLS) oder 8084 für sichere WebSockets |
| Lange Registry-Client-ID | Im Portal ausgegebene Client ID |
| Mit Geräteschlüssel signiertes JWT | Benutzername und Passwort pro Zugangsdatensatz |
/devices/ID/events |
Ihre eigene Hierarchie, z. B. fleet/site1/ID/telemetry |
/devices/ID/state |
Retained Topic, z. B. fleet/site1/ID/state |
/devices/ID/config |
Retained Topic, das das Gerät abonniert, z. B. fleet/site1/ID/config |
/devices/ID/commands/# |
Befehls-Topic mit QoS 1 und idempotenten Payloads |
| Pub/Sub-Routing | Ein Subscriber-Dienst, der an Pub/Sub weiterleitet |
| Registry-Metadaten | Ihre eigene Inventardatenbank oder Retained-Metadaten-Topics |
Das Topic-Layout gestalten Sie jetzt selbst. Verzichten Sie auf den führenden Schrägstrich, den IoT Core verwendete, da er eine leere erste Ebene erzeugt, und ziehen Sie eine Hierarchie im ISA-95-Stil in Betracht, wenn Sie in der Fertigung arbeiten. Dort lohnt es sich, die Migration gleich zum Aufbau eines Unified Namespace (UNS) zu nutzen: Die ISA-95-Gerätehierarchie (Enterprise, Site, Area, Line, Cell) wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Pub/Sub, BigQuery, MES und Dashboards finden Daten dann über den Ort im Werk statt über Geräte-IDs. Hintergründe liefert der Beitrag zu Sparkplug B und dem Unified Namespace.
Schritt für Schritt: Geräte zu einem verwalteten MQTT-Broker umziehen
1. Broker vorbereiten
Registrieren Sie sich unter app.connectmq.com, wählen Sie einen Plan passend zu Ihren maximalen Verbindungen, erstellen Sie einen Broker und geben Sie Zugangsdaten aus. Der kostenlose Serverless-Plan (bis zu 25 Verbindungen, QoS bis 1) reicht aus, um Firmware und Weiterleitungsdienst zu validieren; Serverless Paid unterstützt bis zu 1.000 Verbindungen und QoS 2.
2. Geräte-Firmware aktualisieren
Ersetzen Sie die JWT-Erzeugung und die IoT-Core-Client-ID durch den ausgegebenen Benutzernamen, das Passwort und die Client ID, ändern Sie den Host und passen Sie die Topic-Namen an. Behalten Sie TLS auf Port 8883 bei; ConnectMQ verwendet ein Let's-Encrypt-Zertifikat, daher muss Ihr Trust Store statt der Google-Root-Zertifikate das ISRG-Root-X1-Zertifikat enthalten. Entfernen Sie die JWT-Erneuerungslogik, die bei IoT-Core-Geräten häufig Reconnect-Fehler verursacht hat. Wenn Ihre Geräte auf dem ESP32 basieren, zeigt das ESP32-MQTT-Tutorial einen vollständigen TLS-Client.
3. Telemetrie an Pub/Sub weiterleiten
ConnectMQ enthält keine Cloud-Daten-Bridges, daher gelangen die Daten über einen kleinen Weiterleitungsdienst zu Pub/Sub, der sich als gewöhnlicher MQTT-Client verbindet. Betreiben Sie ihn auf Cloud Run, GKE oder einer VM mit einem Dienstkonto, das in das Topic publizieren darf. Installation mit pip install "paho-mqtt>=2.0" google-cloud-pubsub.
import os
import ssl
import paho.mqtt.client as mqtt
from google.cloud import pubsub_v1
PROJECT = os.environ["GCP_PROJECT"]
PUBSUB_TOPIC = os.environ.get("PUBSUB_TOPIC", "device-telemetry")
MQTT_FILTER = os.environ.get("MQTT_FILTER", "fleet/+/+/telemetry")
publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path(PROJECT, PUBSUB_TOPIC)
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(MQTT_FILTER, qos=1)
def on_message(client, userdata, msg):
device_id = msg.topic.split("/")[2]
future = publisher.publish(
topic_path,
msg.payload,
mqtt_topic=msg.topic,
device_id=device_id,
)
future.add_done_callback(
lambda f: f.exception() and print("Pub/Sub publish failed:", f.exception())
)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=os.environ["MQTT_CLIENT_ID"],
protocol=mqtt.MQTTv5,
)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Setzen Sie MQTT_USERNAME, MQTT_PASSWORD und MQTT_CLIENT_ID auf die Werte aus dem Portal (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), idealerweise aus dem Secret Manager. Attribute wie device_id ermöglichen es nachgelagerten Subscribern und Dataflow-Jobs zu filtern, ohne Payloads zu parsen, ähnlich wie IoT Core Geräteattribute ergänzte. Die offizielle Dokumentation der Pub/Sub-Client-Bibliothek behandelt Batching und Flusssteuerung für hohe Volumina. Zum Skalieren betreiben Sie mehrere Instanzen mit einer MQTT-5-Shared-Subscription wie $share/forwarders/fleet/+/+/telemetry, verfügbar ab Serverless Paid.
4. Konfiguration und Befehle ersetzen
Die Konfigurationsnachrichten von IoT Core lassen sich ganz natürlich auf Retained MQTT Messages abbilden: Publizieren Sie die Konfiguration jedes Geräts als Retained Message auf sein Config-Topic, und das Gerät erhält sie bei jeder Verbindung. Befehle werden auf ein Befehls-Topic mit QoS 1 abgebildet. Machen Sie Befehle mit einer eindeutigen ID und einem Ablaufzeitpunkt idempotent, wie in unserem Leitfaden zum Überstehen eines MQTT-Broker-Ausfalls beschrieben.
5. In Wellen ausrollen
Ziehen Sie zuerst eine Pilotgruppe um, beobachten Sie den Verbindungsstatus unter $SYS/broker/connection/{clientId}/state und im Topic-Explorer des Portals und migrieren Sie dann den Rest nach Region oder Produktlinie. Wenn sich manche Geräte nicht schnell aktualisieren lassen, kann ein lokales Gateway deren alte Topics übersetzen und in die neue Hierarchie republizieren.
Checkliste vor dem Wechsel
- Bestandsaufnahme von Geräten, Firmware-Versionen und genutzten IoT-Core-Funktionen.
- Neue Topic-Hierarchie entworfen und dokumentiert.
- Broker-Plan passend zu maximalen Verbindungen, QoS und Nachrichtengröße dimensioniert.
- Zugangsdaten pro Gerät ausgegeben und sicher gespeichert.
- Firmware für neuen Host, Trust Store, Zugangsdaten und Topics aktualisiert.
- Weiterleitungsdienst läuft und ist in Pub/Sub verifiziert.
- Konfigurations- und Befehlsflüsse Ende-zu-Ende getestet.
- Rollout-Plan mit Pilotgruppe und Rollback-Schritten.
Wenn ein Teil Ihrer Flotte bereits an einem lokalen Broker läuft, behandelt der Leitfaden Mosquitto in die Cloud migrieren Bridging und die wellenweise Umstellung ausführlicher.
Ziehen Sie Ihre Flotte zu ConnectMQ um
Erstellen Sie unter app.connectmq.com einen kostenlosen Broker im Serverless-Plan, ohne Kreditkarte, und validieren Sie Firmware und Weiterleitungsdienst, bevor Sie die Flotte migrieren. ConnectMQ ist ein verwalteter MQTT-Broker mit Standard-MQTT 3.1.1 und 5.0, TLS, WebSockets und einem Portal mit Live-Topic-Explorer. Lesen Sie den Leitfaden zum Cloud-MQTT-Broker für Bereitstellungsoptionen, oder testen Sie zunächst den kostenlosen öffentlichen MQTT-Broker.
Häufig gestellte Fragen
Wann wurde Google Cloud IoT Core abgeschaltet?
Google hat Cloud IoT Core am 16. August 2023 eingestellt, nachdem die Einstellung 2022 angekündigt worden war. Geräte können sich nicht mehr mit seinen Endpunkten verbinden.
Kann ich Pub/Sub und BigQuery nach dem Wechsel zu einem anderen Broker weiter nutzen?
Ja. Diese Dienste waren nicht betroffen. Ein kleiner Subscriber-Dienst leitet MQTT-Nachrichten vom Broker an Pub/Sub weiter, und bestehende Pipelines laufen von dort aus weiter.
Brauche ich bei einem neuen MQTT-Broker eine JWT-Authentifizierung?
Nicht unbedingt. Die meisten verwalteten MQTT-Broker, einschließlich ConnectMQ, verwenden Benutzername und Passwort pro Gerät über TLS, wodurch die JWT-Erneuerungslogik aus der Firmware entfällt.
Was ersetzt die Gerätekonfiguration von IoT Core am ehesten?
Retained MQTT Messages. Publizieren Sie die Konfiguration jedes Geräts als Retained Message auf sein eigenes Config-Topic, und das Gerät erhält bei jeder Verbindung die neueste Version.
