Abonnements für Apps und App-Skalierung

Anwendungen können mehrere Ereignisproduzenten abonnieren, aber nur eine Anwendung kann Ereignisse von jedem Abonnement empfangen. Dabei ist zu beachten, dass sich Abonnements auf die Skalierung einer Anwendung auswirken können. Wenn Sie z. B. erwarten, dass Ihre Anwendung viele Ereignisse gleichzeitig empfängt und die Verarbeitung jedes Ereignisses mehrere Minuten dauert, benötigen Sie möglicherweise einen höheren maximalen Skalierungswert als wenn jedes Ereignis schnell verarbeitet werden kann. Weitere Informationen finden Sie im Abschnitt Anwendungsskalierung konfigurieren.

Alle Ereignisse, die an Anwendungen übergeben werden, werden als HTTP-Nachrichten empfangen. Ereignisse enthalten bestimmte HTTP-Header, die Ihnen dabei helfen, schnell die wichtigsten Informationen zu den Ereignissen zu ermitteln, ohne den Hauptteil (die Geschäftslogik) des Ereignisses durchsuchen zu müssen. Weitere Informationen finden Sie unter Beispiel HTTP headers für ein IBM Cloud Object Storage Ereignis, das an eine Anwendung gesendet wird.

Subskriptionen für Jobs und Jobausführungseinschränkungen

Abonnements können sich darauf auswirken, wie viele Aufträge gestartet werden. Wenn Ihr Job beispielsweise das Löschen von Änderungen in einem Object Storage-Bucket abonniert und dieses Bucket gelöscht wird, wird ein Job für jedes Objekt ausgeführt, das sich in diesem Bucket befand, und Sie können Ihre Begrenzung auf 100 Jobausführungen schnell erreichen. Darüber hinaus müssen Sie die Laufzeit für jede Jobausführung berücksichtigen, die durch ein Ereignis ausgelöst wird. Wenn Ihr Ereigniserzeuger beispielsweise 10 oder mehr Ereignisse pro Sekunde auslöst und jeder Job ungefähr 20 Sekunden lang ausgeführt wird, wird die Jobausführungsbegrenzung von 100 in etwa 10 Sekunden erreicht und alle nachfolgenden Jobausführungen gehen verloren, bis die zuvor gestarteten Jobausführungen abgeschlossen sind. Wählen Sie einen Job nur dann als Ziel für den Ereignisabonnenten, wenn die Anzahl der eingehenden Ereignisse im Allgemeinen gering ist und die in einem bestimmten Zeitrahmen erwartete Spitzenanzahl von Ereignissen niedrig genug ist, um die Anzahl der laufenden Jobs unter der Quotengrenze zu halten. Weitere Informationen finden Sie im Abschnitt Grenzwerte und Kontingente für Code Engine.

Nach 10 Minuten werden von Subskriptionen erstellte Jobausführungen gelöscht. Weitere Informationen finden Sie unter Wo wird mein Job ausgeführt?.

Alle Ereignisse, die an Aufträge geliefert werden, werden als Umgebungsvariablen empfangen. Weitere Informationen finden Sie unter Beispielumgebungsvariablen für ein IBM Cloud Object Storage-Ereignis, das an einen Job gesendet wird.

Metadaten für die Ereigniserstellung

Ereignisse, die von Code Engine verwaltet werden, wenn Sie ein Abonnement erstellen, werden so geändert, dass sie den CloudEvents-Spezifikation In dieser Spezifikation ist eine Gruppe von allgemeinen Attributen definiert, die in jedes Ereignis einbezogen werden kann, um eine allgemeine Gruppe von Metadaten bereitzustellen. Durch Anzeigen der Metadaten verstehen Sie rasch die zentralen Bestandteile der Nachricht ohne Parsing und ohne die Gesamtheit der Ereignisnutzdaten verstehen zu müssen. So enthält beispielsweise jedes Ereignis, das an eine Anwendung geliefert wird, einen HTTP Header mit der Bezeichnung ce-type, der die semantische Bedeutung (oder den "Grund") des Ereignisses angibt. Ein Ereignis aus einer Datenbank enthält möglicherweise den ce-type-Wert com.example.row.deleted. Dieser Wert gibt an, dass das Ereignis generiert wurde, weil in der Datenbank eine Zeile gelöscht wurde.

In der folgenden Tabelle sind einige allgemeine Schlüsselattribute aufgelistet. Bei jedem Attribut ist angegeben, ob es ein erforderliches Attribut für das eingehende Ereignis oder ob es optional ist.

Weitere Informationen über die vollständige Liste der Attribute finden Sie in der Spezifikation CloudEvents.

Wenn in Code Engine Ereignisse an Anwendungen übergeben werden, werden die CloudEvent-Attribute als HTTP-Header mit dem Präfix ce- angezeigt. Wenn Ereignisse an Batch-Jobs zugestellt werden, werden die Attribute als Umgebungsvariablen mit dem Präfix CE_ angezeigt und der gesamte Variablenname wird in Großbuchstaben angegeben.

ce-id: 3fb2c04e-a660-4640-8899-b82efb8169b6
ce-source: https://cloud.ibm.com/catalog/services/cloud-object-storage/mybucket
ce-specversion: 1.0
ce-subject: object-69-144
ce-time: 2021-08-17T20:22:02.917Z
ce-type: com.ibm.cloud.cos.document.delete

CE_DATA={"bucket":"mybucket","endpoint":"","key":"Notes.rtf","notification":{"bucket_name":"mybucket","content_type":"text/rtf","event_type":"Object:Delete","format":"2.0","object_length":"4642","object_name":"Notes.rtf","request_id":"b59727ee-9c4e-446a-9261-5616f6d1283b","request_time":"2021-04-13T20:10:37.631Z"},"operation":"Object:Delete"}  
CE_ID=b59727ee-9c4e-446a-9261-5616f6d1283b  
CE_SOURCE=https://cloud.ibm.com/catalog/services/cloud-object-storage/mybucket  
CE_SPECVERSION=1.0  
CE_TIME=2021-08-17T20:22:02.917Z  
CE_TYPE=com.ibm.cloud.cos.document.delete  

Was passiert, wenn ich ein Abonnement erstelle?

Standardmäßig prüfen die Befehle subscription cron create, subscription cos create und subscription kafka create zuerst, ob die Zielanwendung oder der Zieljob vorhanden sind. Wenn die Zielprüfung fehlschlägt, weil die Anwendung oder der Job nicht in Ihrem Projekt vorhanden ist, geben die Befehle für die Erstellung der Subskription einen Fehler zurück. Wenn Sie ein Abonnement erstellen möchten, ohne zuerst die Anwendung zu erstellen, verwenden Sie die Option --force. Bei Verwendung der Option --force umgeht der Befehl die Zielprüfung. Bitte beachten Sie, dass im Feld für Ready (Ready) des Abonnements so lange der Wert 'false' angezeigt wird, bis die Zielanwendung bzw. der Zieljob erstellt worden ist. Anschließend wird das Abonnement automatisch in den Status Ready: true versetzt.

Nach dem Erstellen des Abonnements wird wiederholt der Status des Abonnements abgefragt, um dessen Bereitschaft zu überprüfen. Diese Statusabfrage dauert standardmäßig 15 Sekunden, danach wird das Zeitlimit überschritten. Sie können die Zeitdauer bis zur Zeitlimitüberschreitung des Befehls ändern. Verwenden Sie dazu die Option --wait-timeout. Sie können die Statusabfrage auch umgehen, indem Sie die Option --no-wait auf false setzen.

Sie können den Status Ihrer Subskription mithilfe der subscription cron get, subscription cos get oder der subscription kafka get-CLI-Befehle anzeigen.