So funktioniert ein Aufruf

your code ── invoke('hello') ──▶ gateway (data plane)
                                   • checks the key and the user's token
                                   • finds the project from the host
                                   • adds x-aura-role, x-aura-user-id, x-aura-project-id
                                   │  message bus (request / reply)
                                   ▼
                           functions service
                                   • access policy: only invoke is public
                                   • reads the function, reserves one invocation of the plan quota
                                   │  HTTP
                                   ▼
                            edge runtime
                                   • loads code, limits and variables
                                   • starts an isolated V8 worker
                                   • rebuilds the request you described
                                   ▼
                             your function ── Response ──▶ back along the same path

Das Gateway und der Funktionsdienst kommunizieren über einen Nachrichtenbus. Eine Nachricht auf diesem Bus hat eine Größenbeschränkung, weshalb eine Anfrage oder Antwort über etwa 256 KiB nicht durchgelassen wird: siehe -Grenzwerte.

• Ein Arbeiter pro Anruf. Die Edge-Laufzeit startet bei jedem Aufruf einen neuen isolierten V8-Worker mit dem Speicherlimit und dem Timeout der Funktion. Nichts im Speicher bleibt von einem Aufruf zum nächsten erhalten: Behalten Sie den Zustand nicht in einer Variablen bei. Nutzen Sie Ihre Datenbank oder Ihren Speicher.
• Code wird einige Sekunden lang zwischengespeichert. Die Laufzeit behält den Code und die Grenzen einer Funktion 5 Sekunden lang bei und löscht sie bei der Bereitstellung. Variablen werden bei jedem Aufruf gelesen.
• Ihre Anfrage wurde neu erstellt. Die Laufzeit erstellt die von Ihnen beschriebene Anforderung (method, path, headers, body) und übergibt sie an Ihren Deno.serve-Handler. Eine Funktion verhält sich daher wie jeder HTTP-Server.
• Die Laufzeit erzwingt das Timeout. Wenn timeout_secs abläuft, wird der Worker abgebrochen; Nach etwa dieser Verzögerung sieht der Anrufer einen Fehler.
• WASM-Funktionen werden innerhalb des Dienstes selbst ausgeführt, mit Einschränkungen hinsichtlich Speicher, Zeit und Anweisungen. Eine WASM-Funktion kann Protokollzeilen melden, die im Feld logs der Antwort erscheinen; Eine Deno-Funktion kann dies nicht.

Der Dienst verfügt über zwei Möglichkeiten, die Antwort Ihrer Funktion zurückzugeben, die durch den Anforderungsheader X-Aurabase-Invoke-Mode ausgewählt werden.

Der Umschlag ist vorhanden, sodass eine JSON-Antwort den Status, die Header und die Dauer des Anrufs enthalten kann. Die Grenze besteht darin, dass Bytes in JSON nicht übertragen werden können. Aus diesem Grund benötigt eine binäre Antwort den Rohmodus. Das SDK wählt den Modus aus responseType.

Im Rohmodus fügt der Dienst x-aurabase-invoke-origin: function zu den Antworten Ihrer Funktion hinzu. Ein Fehler, der vom Gateway oder der Laufzeit stammt, trägt ihn nicht. Auf diese Weise trennt das SDK FunctionsHttpError (Ihre Funktion hat beantwortet) von FunctionsRelayError (die Plattform ist ausgefallen).

Drei Timeouts sind verschachtelt, sodass keines vor dem darin enthaltenen endet:

gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

Der Dienst wartet zur Laufzeit auf timeout_secs plus einen Spielraum. Da die Laufzeit den Worker bei timeout_secs abbricht, sehen Sie in diesem Moment normalerweise einen Fehler der Funktion und nur dann einen 504 TIMEOUT, wenn die Laufzeit selbst nicht mehr antwortet. Ein 504 bedeutet daher, dass die Funktion gestartet wurde und möglicherweise Auswirkungen hatte: Wiederholen Sie einen nicht idempotenten Aufruf nicht blind.

Messung und Quote:

1. Vor dem Aufruf reserviert der Dienst einen Aufruf aus dem Plankontingent. Ist das Kontingent erschöpft, stoppt der Aufruf hier mit 403.
2. Nach dem Aufruf zeichnet es den Aufruf und seine Dauer in Millisekunden auf.
3. Wenn der Anruf fehlschlägt, bevor Ihre Funktion antwortet, wird die Reservierung freigegeben und nichts gezählt.

• Halten Sie jeden Anruf kurz und zustandslos. Für lange Arbeiten einen Job in die Warteschlange stellen.
• Halten Sie Anfragen und Antworten klein; Legen Sie Dateien im Speicher ab und übergeben Sie eine Referenz.
• Machen Sie Funktionen idempotent: Ein wiederholter Job, ein Client-Wiederholungsversuch nach einem Netzwerkfehler oder eine doppelte Cron-Zustellung können Ihren Code zweimal ausführen.
• Autorisieren Sie die Identitätsheader der Plattform, da diese die einzigen Werte sind, die der Aufrufer nicht fälschen kann. Siehe Sicherheit.
• Messen Sie Ihre eigene Latenz: Jeder Anruf zahlt für den Start eines Workers. Eine Minimalfunktion hat duration_ms: 74 auf einem lokalen Stapel gemeldet.