Funcții fără server și pornire la rece

1) Ce este începutul rece și de ce apare

1. Alocare medie (container/micro-VM, runtime loading).

2. VPC/ENI amorsare, secrete, fișiere, configurare.

3. Inițializarea codului (importul de module, conectarea la baza de date, încărcarea modelelor).

4. Executie Handler.

Pornire caldă (reutilizare) sare peste pașii 1-3. Probabilitatea de pornire la rece crește la vârfuri, după downtime, cu paralelism în creștere și cu actualizări de cod/config.

2) Cum se măsoară și țintă (SLO)

Metrics: 'init _ duration' (initializare), 'duration _ total', 'share of cold starts', p95/p99 latency, eroare de conectare la dependencies after downtime.
Îndepărtarea telemetriei: jurnalele platformei + etichetele proprii (de exemplu, "rece = adevărat/fals' dacă există un 'context. esteColdStart "sau propriul pavilion în închiderea statică).
Obiective SLO (exemplu): API „login” p95 ≤ 200 ms, cota rece ≤ 3%; locuri de muncă de fundal - p95 ≤ 1 s. pentru rutele „bani” - separate, mai stricte.

3) Principalele pârghii de reducere a pornirii la rece

3. 1 Control concarrence și încălzire

Concurrency Provisioned/Min Instances: Deține N medii calde. Utilizare pentru mânere critice.
Încălzitoare/încălzire: apeluri programate (cron/scheduler) pentru a menține încălzirea lucrătorilor. Fă-o cu înțelepciune (regiune, timp, sarcină).
Tampoane de explozie: Ridicați limita de concurență în avans înainte de vârfurile așteptate.

3. 2 Ambalaje și dependențe

Mic implementare-artefact: tremurând copac, "- numai prod' dependențe, straturi (AWS Straturi) pentru libs mari.
Lazy-init: importați module grele în interiorul dispozitivului de manipulare la primul acces; conexiuni deschise leneș.
Resurse calde: clienții cache SDK/conexiune în domeniul global de reutilizare la început cald.

3. 3 Rețea și VPC

Fără VPC pentru funcții care nu au nevoie de intimitate (altfel ENI-atașare adaugă zeci la sute de ms).
Dacă este necesar VPC, utilizați modul de economie VPC al furnizorului (ENI pools/optimization), proxy la baza de date (RDS Proxy/Cloud SQL Auth Proxy) și pooling de conexiune.

3. 4 Limbi și runtime

Nod. js/Go începe cel mai rapid; Python - de obicei rapid, dar sensibil la importuri mari; Java/.NET este mai greu fără GraalVM/AOT și profilare.
Pentru JVM, luați în considerare SnapStart/CRaC/Graal Native; pentru. NET - împodobite autonom.

3. 5 Inițializare și stare

Puneți inițializarea costisitoare în cârligul de inițializare (faza de init) și nu în calea de solicitare.
Utilizați încărcarea la cerere a configurațiilor/secretelor cu memoria cache locală (TTL).
Nu stocați starea utilizatorului în memorie - numai semnale/conectori cache.

4) Modele arhitecturale care reduc impactul pornirii la rece

4. 1 Asincron și cozi

Acceptăm solicitarea de → valida → pune-l în coadă/autobuz (SQS/PubSub/Queue Storage) → să răspundă la 202/Accepted → să-l proceseze cu fundal.
Potrivit pentru operațiuni non-interactive (plăți, rapoarte, calcule grele).

4. 2 Precompute/Pre-cache

Generarea de accese/directoare/caracteristici steaguri în avans de către declanșatoare (CRON/evenimente) și de stocare în KV/cache/margine.

4. 3 Fan-out/Fan-in

Împărțim o operație lungă în mai multe funcții scurte (Map/Reduceți-like) → un risc mai mic de întreruperi de timp și de frig repetat.

4. 4 Edge-offload

Cele mai simple verificări (JWT/HMAC, geo-redirecționare, antiboot) sunt efectuate pe margine (Workers/Functions @ Edge) pentru a salva RTT și a descărca originea.

5) Practică: configurații și tehnici

5. 1 AWS Lambda (provizionat + RDS Proxy)

hcl
Terraform sketch: enable provisioned concurrency on the sales version of the resource "aws_lambda_provisioned_concurrency_config" "api" {
function_name = aws_lambda_function. api. function_name qualifier   = aws_lambda_alias. prod. name provisioned_concurrent_executions = 20
}

RDS Proxy for connection pool "aws_db_proxy" "rds_proxy" {
name          = "pg-proxy"
engine_family     = "POSTGRESQL"
idle_client_timeout  = 1800 require_tls      = true
}

js let pgClient ;//reuse between warm runs let cold = true;

exports. handler = async (event, ctx) => {
const isCold = cold; cold = false;
if (!pgClient) {
const { Client } = await import('pg');     // lazy import pgClient = new Client({ host: process. env. PG_PROXY, ssl: true });
await pgClient. connect();
}
const t0 = Date. now();
const data = await pgClient. query('select 1');
return {
statusCode: 200,
headers: { 'x-cold-start': String(isCold), 'x-elapsed-ms': String(Date. now()-t0) },
body: JSON. stringify({ ok: true })
};
};

5. 2 GCP Cloud Run/Cloud Funcții (min instanțe)

yaml
Cloud Run service. yaml apiVersion: serving. knative. dev/v1 kind: Service metadata: { name: api }
spec:
template:
metadata:
annotations:
autoscaling. knative. dev/minScale: "5" # keep warm run containers. googleapis. com/cpu-throttling: "false"
spec:
containerConcurrency: 80 containers:
- image: gcr. io/proj/api:latest env:
- { name: DB_HOST, value: "10. 0. 0. 5" }

5. 3 Funcții Azure (AlwaysOn/PreWarm)

Planuri premium/elastice cu AlwaysOn; cazuri pre-încălzite ≥ concurență predictivă p95.

6) Timeout, retrageri, termene limită

Treceți termenul general (client-side) prin antet ("x-deadline-ms'/" grpc-timeout"), scurtați "per-hop timeout" în interiorul funcției.
Se repetă numai pentru operațiuni idempotente; Utilizați tasta Idempotency și eliminarea duplicatelor.
Pentru API-ul frontal - acoperire (cerere duplicat după p90) și întrerupător de circuit pentru dependențe pe distanțe lungi.

7) Lucrul cu baze de date/cache/secrete

Pools/proxy-uri (RDS Proxy/Cloud SQL Proxy/pgBouncer) în loc de mii de conexiuni scurte.
Scurt TTL secret + în memorie cache cu actualizare de fundal.
Cache (Redis/Memcached/KV): încărcarea directoarelor „grele” pe init, dar cu o limită de timp.

8) Organizarea și asamblarea codului

Dispozitive de manipulare separate pentru cazuri de utilizare îngustă; un pachet „gros” = init lung.
ESBuild/Rollup: excludeți neutilizate, combinați numai critice.
Straturi/extensii - pentru liburi mari (modele OpenSSL, SDK) pentru a reutiliza memoria cache a furnizorului.

9) Testarea și simularea vârfului

Sintetica „rece” începe: opriți forțat instanțele min și conduceți traficul paralel în trepte.
A/B: comparați cota de rece, p95, eroare de conectare la DB/secrete, costuri.
GameDay: vârf de sarcină × 2 de la all-time de mare, warm-up off.

10) Cost (FinOps)

Min instances/provisioned concurrency cost money - activați numai pentru rutele fierbinți.
Reduceți durata de funcționare: memorie cache, scurte intervale de timp, evitând SDK-urile inutile.
Luați în considerare ieșirea (apeluri la API-uri externe) și înregistrarea (volumul jurnalelor crește rapid la vârfuri reci).

11) Antipattern

Un handler monolit cu zeci de megaocteţi de dependenţe.
Conectarea obligatorie la baza de date pe fiecare apel (fără reutilizare/proxy).
VPC pentru toate funcțiile „pentru orice eventualitate”.
Perioade lungi de timp și retrageri oarbe → „cozi” și phantom write-off.
Încălzirea „totul într-un rând” non-stop.
Inițializare secretă în calea de solicitare (lentice init> 100 ms - transfer la init/cache).

12) Specificul iGaming/Finanțe

Căi bănești (depuneri/retrageri): păstrați instanțele provizionate/min, SLO-uri separate, limitarea strictă a termenelor și repetițiilor (idempotența este obligatorie).
KYC/PSP: API-uri externe instabile - împachetați în coadă + lucrător, în față - 202/votare/cârlig web.
Reglementare și audit: jurnale imuabile (WORM), jurnal de evenimente de intrare cu 'Idempotency-Key', corelație 'trace _ id'.
Rezidența datelor: implementați funcții care procesează PII în conturi/proiecte regionale; fără memorie cache cu PII.

13) Lista de verificare Prod Readiness

• SLI/SLO definit: p95/p99, fracție rece, obiective de traseu.
• Instanțele provizionate/min pe funcțiile critice sunt activate; predicţia concarenţei.
• Pachet minimizat; fețele grele sunt efectuate în straturi; leneș-import/inițializare.
• Reutilizați clienții SDK/DB; RDS/SQL Proxy este configurat; piscină de conexiune.
• VPC numai acolo unde este necesar; ENI/proxy-uri optimizate; secrete prin manager + cache local TTL.
• Timeout/termene limită/retrageri: backoff + jitter; numai repetări idempotente.
• Sintetice „la rece” + teste de sarcină; alerte pentru creșterea ponderii frigului și a p99.
• Runbooks: cum să creșteți provizionate, cum să schimbați minScale, cum să includeți degradarea.
• Pentru iGaming: separate SLO/tablouri de bord „moduri de bani”, Idempotency-Key, WORM audit.

14) TL; DR

Începutul rece este inevitabil, dar ușor de gestionat: păstrați cazuri calde în care contează, reduceți pachetul, aplicați conexiuni leneșe și reutilizați conexiunile, evitați VPC inutile, scoateți operațiunile grele în linie/lucrători și utilizați marginea pentru reguli ușoare. Pentru căile financiare critice - SLO-uri separate, idempotență și timeout-uri stricte; măsoară cota de frig și pornește încălzirea numai acolo unde se plătește.