INTEGRITY Dokumentace

← Cloudflare Workers / workers / runtime-apis / bindings

Service bindings

O Service bindings

Service bindings umožňují jednomu Workeru volat druhý, aniž by musel procházet přes veřejně dostupnou URL. Service binding umožňuje Workeru A zavolat metodu na Workeru B, nebo přeposlat požadavek z Workeru A na Worker B.

Service bindings poskytují stejné oddělení odpovědností jako mikroslužby nebo architektury orientované na služby, ale bez bolestivé konfigurace, výkonnostní režie nebo nutnosti učit se protokoly RPC.

Service bindings jsou abstrakce bez režie

Service bindings se běžně používají k:

Konfigurace

Service binding přidáte úpravou Konfigurační soubor Wrangler volajícího: Workeru, který má mít možnost iniciovat požadavky.

Pokud chcete, aby Worker A mohl volat Worker B, přidejte do Konfigurační soubor Wrangler pro Worker A:

{
	"services": [
		{
			"binding": "<BINDING_NAME>",
			"service": "<WORKER_NAME>"
		}
	]
}
[[services]]
binding = "<BINDING_NAME>"
service = "<WORKER_NAME>"

Rozhraní

Worker A, který deklaruje Service binding na Worker B, může Worker B volat dvěma různými způsoby:

  1. RPC vám umožňuje komunikovat mezi Workery pomocí funkčních volání, která si sami definujete. Například await env.BINDING_NAME.myMethod(arg1). Toto doporučujeme pro většinu případů použití, protože si tak můžete vytvořit vlastní interní API, které váš Worker zpřístupní ostatním Workerům.
  2. HTTP vám umožňuje komunikovat mezi Workery voláním fetch() handler od jiných Workers a odesílá Request objekty a přijímání Response objekty. Například env.BINDING_NAME.fetch(request).

Příklad: vytvořte první Service binding pomocí RPC

Tento příklad rozšiřuje WorkerEntrypoint třída pro podporu Service bindings založených na RPC. Nejprve vytvořte Worker, se kterým chcete komunikovat. Budeme mu říkat "Worker B". Worker B zpřístupňuje veřejnou metodu add(a, b):

{
	"$schema": "./node_modules/wrangler/config-schema.json",
	"name": "worker_b",
	"main": "./src/workerB.js"
}
"$schema" = "./node_modules/wrangler/config-schema.json"
name = "worker_b"
main = "./src/workerB.js"
import { WorkerEntrypoint } from "cloudflare:workers";

export default class WorkerB extends WorkerEntrypoint {
	// Currently, entrypoints without a named handler are not supported
	async fetch() {
		return new Response(null, { status: 404 });
	}

	async add(a, b) {
		return a + b;
	}
}

Dále vytvořte Worker, který bude volat Worker B. Budeme mu říkat "Worker A". Worker A deklaruje binding na Worker B, čímž získává oprávnění volat veřejné metody Workeru B.

{
	"$schema": "./node_modules/wrangler/config-schema.json",
	"name": "worker_a",
	"main": "./src/workerA.js",
	"services": [
		{
			"binding": "WORKER_B",
			"service": "worker_b"
		}
	]
}
"$schema" = "./node_modules/wrangler/config-schema.json"
name = "worker_a"
main = "./src/workerA.js"

[[services]]
binding = "WORKER_B"
service = "worker_b"
export default {
	async fetch(request, env) {
		const result = await env.WORKER_B.add(1, 2);
		return new Response(result);
	},
};

Chcete-li spustit Worker A i Worker B v místním vývojovém prostředí, musíte spustit dvě instance Wrangler ve vašem terminálu. Pro každý Worker otevřete nový terminál a spusťte npx wrangler@latest dev.

Každý Worker se nasazuje samostatně.

Životní cyklus

The Service bindings API is asynchronous, you must await libovolnou metodu, kterou zavoláte. Pokud Worker A vyvolá Worker B prostřednictvím Service bindingu a Worker A nepočká na dokončení Workeru B, Worker B se předčasně ukončí.

Více informací o životním cyklu volání Workeru přes Service Binding pomocí RPC najdete v Životní cyklus RPC dokumentaci.

Lokální vývoj

Lokální vývoj je podporován pro Service bindings. Pro každý Worker otevřete nový terminál a použijte wrangler dev v příslušném adresáři. Při spuštění wrangler dev, service bindings se zobrazí jako connected/not connected v závislosti na tom, zda Wrangler najde spuštěnou wrangler dev relaci pro daný Worker. Například:

$ wrangler dev
...
Your worker has access to the following bindings:
- Services:
  - SOME_OTHER_WORKER: some-other-worker [connected]
  - ANOTHER_WORKER: another-worker [not connected]

Wrangler také umožňuje jedním příkazem spustit více Workerů najednou. Chcete-li to vyzkoušet, předejte více -c příznaky Wrangleru, například takto: wrangler dev -c wrangler.json -c ../other-worker/wrangler.json. První konfigurace bude považována za primární workeru, který bude jako obvykle zpřístupněn přes HTTP na http://localhost:8787. Zbývající konfigurační soubory budou považovány za sekundární a bude přístupný pouze prostřednictvím service bindingu z primárního Workeru.

Nasazení

Workers používající Service bindings se nasazují samostatně.

To při prvním nastavení a nasazení znamená, že cílový Worker (Worker B ve výše uvedených příkladech) musí být nasazen dříve než Worker A. Jinak nasazení Workeru A selže, protože Worker A deklaruje binding na Worker B, který ještě neexistuje.

Při provádění změn ve stávajících Workerech byste ve většině případů měli:

Smart Placement

Smart Placement automaticky umístí váš Worker do optimální lokality, která minimalizuje latenci.

Smart Placement můžete kombinovat se Service bindings a rozdělit svůj Worker na dvě služby:

Smart Placement a Service Bindings

Viz dokumentace ke Smart Placement další informace.

Limity

Service bindings mají následující limity: