Vor genau vor einem Jahr gab mir Cloudflare einen Auftrag: Mach es möglich, dass man an Cloudflares Edge Code ausführen kann. Damals wussten wir noch nicht, wie das aussehen würde. Würde es Container-basiert sein? Eine neue Turing-unvollständige, domänenspezifische Sprache? Lua? „Funktionen“? Wir hatten viele Ideen.
Schließlich entschieden wir uns für das, was im Nachhinein als die naheliegende Wahl erscheint: JavaScript, das unter Verwendung der standardmäßigen Service Workers-API in einer neuen, auf V8 basierenden Umgebung läuft. Vor fünf Monaten haben wir Ihnen eine Vorschau auf das gegeben, was wir gebaut hatten, und die Beta gestartet.
Heute, mit Tausenden von bereitgestellten Skripten und vielen Milliarden von abgewickelten Anfragen, ist Cloudflare Workers für jeden zugänglich.
„Der Wechsel von VCL zu Cloudflare Workers wird uns ein kreatives Routing gestatten, mit dem wir JavaScript für die Millionen von Benutzern von npm noch schneller als bisher bereitstellen können. Wir werden unsere nächste Generation von Diensten auf der Plattform von Cloudflare erstellen, und zwar in JavaScript!“
– CJ Silverio, CTO, npm, Inc.
Was ist die Cloud überhaupt?
In der Vergangenheit wurde der Code von Webanwendungen zwischen Servern und Browsern aufgeteilt. Zwischen ihnen liegt ein riesiges, aber grundsätzlich dummes Netzwerk, das lediglich Daten von Punkt zu Punkt transportiert.
Wir glauben nicht, dass das die Erwartungen an „Die Cloud“ erfüllt.
Wir glauben, dass der wahre Traum von Cloud-Computing darin besteht, dass Ihr Code im Netzwerk selbst lebt. Ihr Code läuft nicht in „us-west-4“ oder „Süd-Zentralasien (Mumbai)“, er läuft überall.
Konkret sollte er dort laufen, wo er am meisten benötigt wird. Bei der Antwort an einen Benutzer in Neuseeland sollte Ihr Code in Neuseeland laufen. Bei der Verarbeitung von Daten in Ihrer Datenbank sollte Ihr Code auf den Rechnern laufen, auf denen die Daten gespeichert sind. Bei der Interaktion mit einer Drittanbieter-API sollte Ihr Code überall dort laufen, wo diese API gehostet wird. Wenn menschliche Entdecker den Mars erreichen, werden sie nicht glücklich sein, wenn sie eine halbe Stunde auf die Antwort Ihrer App warten müssen – Ihr Code muss auf dem Mars laufen.
Cloudflare Workers ist unser erster Schritt zur Verwirklichung dieser Vision. Wenn Sie einen Worker bereitstellen, wird er in weniger als 30 Sekunden im gesamten Edge-Netzwerk von Cloudflare mit über hundert Standorten weltweit bereitgestellt. Jede Anfrage für Ihre Domain wird von Ihrem Worker an einem Cloudflare-Standort in der Nähe des Endbenutzers bearbeitet, ohne dass Sie sich um einzelne Standorte kümmern müssen. Je mehr Standorte wir in Betrieb nehmen, desto mehr läuft Ihr Code „einfach überall“.
Nun, okay ... er wird nicht auf dem Mars laufen. Noch nicht. Hörst du zu, Elon?
Was ist ein Worker?
Cloudflare Workers leitet seinen Namen von Web Workers ab, genauer gesagt von Service Workers, der standardmäßigen W3C-API für Skripte, die im Hintergrund in einem Webbrowser laufen und HTTP-Anfragen abfangen. Cloudflare Workers ist auf Basis der gleichen Standard-API geschrieben, läuft aber auf den Servern von Cloudflare, nicht in einem Browser.
Hier sind die Werkzeuge, mit denen Sie arbeiten können:
- Ausführen von beliebigem JavaScript-Code mit den neuesten standardmäßigen Sprachfunktionen.
- Abfangen und Ändern von HTTP-Anfrage- und -Antwort-URLs, Status, Headern und Body-Inhalten.
- Antwort auf Anfragen direkt durch Ihren Worker oder Weiterleitung an einen anderen Ort.
- Senden von HTTP-Anfragen an Server von Drittanbietern.
- Senden multipler Anfragen, seriell oder parallel, und Verwendung der Antworten zur Erstellung einer endgültigen Antwort auf die ursprüngliche Anfrage.
- Senden asynchroner Anfragen, nachdem die Antwort bereits an den Client zurückgegeben wurde (z. B. für Protokollierung oder Analyse).
- Kontrolle anderer Cloudflare-Funktionen, wie z. B. Caching-Verhalten.
Die Einsatzmöglichkeiten für Workers sind unendlich, und wir sind gespannt, was unseren Kunden einfällt. Hier sind einige Ideen, die wir in der Beta gesehen haben:
- Weiterleitung verschiedener Arten von Anfragen an verschiedene Ursprungsserver.
- Erweiterung von HTML-Templates in der Edge, um die Datenübertragungskosten am Ursprung zu reduzieren.
- Anwendung von Zugriffskontrollen auf zwischengespeicherte Inhalte.
- Umleitung eines Bruchteils der Benutzer zu einem Staging-Server.
- Durchführung von A/B-Tests zwischen zwei völlig unterschiedlichen Back-Ends.
- Erstellen von „serverlosen“ Anwendungen, die vollständig auf Web-APIs basieren.
- Erstellen von benutzerdefinierten Sicherheitsfiltern, die nur für Ihre Anwendung gelten, um unerwünschte Zugriffe zu blockieren.
- Umschreiben von Anfragen zur Verbesserung der Cache-Trefferquote.
- Implementierung von benutzerdefinierter Lastverteilung und Failover-Logik.
- Schnellkorrekturen für eine Anwendung, ohne die Produktionsserver aktualisieren zu müssen.
- Sammeln von Analysen, ohne Code im Browser des Benutzers auszuführen.
- Und noch vieles mehr.
Hier ist ein Beispiel.
// A Worker which:
// 1. Redirects visitors to the home page ("/") to a
// country-specific page (e.g. "/US/").
// 2. Blocks hotlinks.
// 3. Serves images directly from Google Cloud Storage.
addEventListener('fetch', event => {
event.respondWith(handle(event.request))
})
async function handle(request) {
let url = new URL(request.url)
if (url.pathname == "/") {
// This is a request for the home page ("/").
// Redirect to country-specific path.
// E.g. users in the US will be sent to "/US/".
let country = request.headers.get("CF-IpCountry")
url.pathname = "/" + country + "/"
return Response.redirect(url, 302)
} else if (url.pathname.startsWith("/images/")) {
// This is a request for an image (under "/images").
// First, block third-party referrers to discourage
// hotlinking.
let referer = request.headers.get("Referer")
if (referer &&
new URL(referer).hostname != url.hostname) {
return new Response(
"Hotlinking not allowed.",
{ status: 403 })
}
// Hotlink check passed. Serve the image directly
// from Google Cloud Storage, to save serving
// costs. The image will be cached at Cloudflare's
// edge according to its Cache-Control header.
url.hostname = "example-bucket.storage.googleapis.com"
return fetch(url, request)
} else {
// Regular request. Forward to origin server.
return fetch(request)
}
}
Es ist wirklich schnell
Manchmal werden wir gefragt, ob JavaScript „langsam“ ist. Nichts könnte weiter von der Wahrheit entfernt sein.
Workers verwendet die von Google für Chrome entwickelte V8-JavaScript-Engine. V8 ist nicht nur eine der schnellsten Implementierungen von JavaScript, sondern auch eine der schnellsten Implementierungen aller dynamisch typisierten Sprachen, Punkt. Aufgrund des enormen Arbeitsaufwands, der in die Optimierung von V8 investiert wurde, übertrifft es nahezu jede gängige Server-Programmiersprache, mit den möglichen Ausnahmen von C/C++, Rust und Go. (Übrigens werden wir diese in Kürze über WebAssembly unterstützen.)
Das Fazit: Ein typisches Worker-Skript wird in weniger als einer Millisekunde ausgeführt. Die meisten Benutzer können keinen Latenzunterschied messen, wenn sie Worker aktivieren – außer natürlich, wenn ihr Worker die Latenzzeit tatsächlich verbessert, indem er direkt von der Edge aus antwortet.
Ein weiterer geschwindigkeitsbezogener Aspekt ist, dass Worker auch schnell bereitgestellt werden. Worker werden global in weniger als 30 Sekunden ab dem Zeitpunkt, zu dem Sie das Skript speichern und aktivieren, bereitgestellt.
Preis
Workers ist ein kostenpflichtiges Add-on zu Cloudflare. Wir wollten den Preis so einfach wie möglich halten, und so sieht er aus:
Erste Schritte
- Melden Sie sich in Ihrem Cloudflare-Konto an und besuchen Sie den Bereich „Workers“, um Workers zu konfigurieren.
- Experimentieren Sie mit Workers im Playground (kein Konto erforderlich).
- Lesen Sie die Dokumentation, um zu erfahren, wie Worker geschrieben werden.
- Schauen Sie sich den ursprünglichen Blogbeitrag mit der Ankündigung an, um weitere technische Details zu erfahren.
- Diskutieren Sie über Workers in der Cloudflare-Community.
„Cloudflare Workers spart uns viel Zeit. Die Verwaltung des Bot-Traffics ohne Workers würde wertvolle Entwicklungs- und Serverressourcen beanspruchen, die anderswo besser eingesetzt werden.“
– John Thompson, Senior System Administrator, MaxMind