Scalarea nodurilor de rețea

(Secțiunea: Ecosistem și rețea)

1) Roluri de nod și bucle de trafic

Validare/producție (consens/bloc/rollup-sequencer): o cale critică de finalizare.
Reader/indexer (read-only/API/archive): servește cererilor de aplicație și analiză.
Releu/punte (cross-domain): transferul mesajelor/activelor între domenii.
Gateway/edge (ingress/gRPC/WebSocket/QUIC): primirea cererilor clientului, rate-limit, cache.
Tele metrice/observabilitate: colectarea de metrici/busteni/urme, probe sintetice.

Fiecare rol are propriul SLO, bugetul de eroare și politica de scalare.

2) Modele de scalare

2. 1 Scalare

Creșterea CPU/RAM/SSD/NIC. Rapid pentru vârfuri, dar limitat de fier și poate crește costul pe unitate de trafic.

2. 2 Scalare-out

Adăugarea de replici în spatele echilibrelor/cozilor. Necesită idempotență, politici lipicioase, cvorum și cache consistente (sau dizabilitatea lor).

2. 3 Diversitate funcțională

Separarea taxelor: nodurile de consens sunt izolate; RPC/API - separat; indexer/arhivă - separat; pod/relayer - separat.

2. 4 Geo-scară

Clustere regionale (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; Replicare cu finalizare/latență și cache-uri locale

2. 5 Sharding/partiționare

Separarea prin chei (chainId, shard, topic) pentru cozi/indexoare și depozite de coloane.

3) Calea de solicitare: echilibrare, caching, QoS

echilibrare L4/L7: controale de sănătate, lipicios de token/trace-id, circuit-breaker, outlier-ejection.

• pe margine (TTL scurt pentru RPC citite frecvent);
• în interiorul procesorului (citire, scriere pentru indici);
• cache-uri negative (nu au fost găsite).
• Clasele QoS: P0 (finalizare/punte/plăți), P1 (produs), P2 (vrac/arhivă).
• Backpressure: jetoane/credite, restricționarea cererilor concur, cozi cu DLQ.
• Admitere: pre-filtru (auth, limite, geo/sancțiuni), respingerea anticipată a cererilor „scumpe”.

4) Gestionarea stării: instantanee, tăiere, arhivă

Full/Pruned: noduri tăiate pentru RPC; Archive - pentru interogări retrospective într-un bazin separat.
Instantanee/fast-sync: instantanee regulate, bootstrap rapid de replici noi.
Stocare la cald/cald/rece: stare fierbinte pe NVMe, blocuri istorice - S3/object cu indici.
Garbadge-colectare/compactare: ferestre programate, nu în timpul vârfurilor.
DA/tampoane de lot (pentru L2/poduri): garanții de livrare și perioada de curățare cu chitanțe dovada.

5) Cozi și streaming

Intrare: Kafka/Pulsar/NATS с partiție-cheie = 'chainId' shard' topic '.
Grupuri de consumatori: scalarea de către părți, handler idempotent (outbox/inbox).
DLQ și retrai: backoff exponențial, otravă-mesaj carantină.
Ordin convenit: în cadrul partidului pentru determinism.

6) Optimizări de transport și rețea

QUIC/HTTP/2: multiplexare, corecție cap de linie.
Tuning TCP: BBR/CUBIC, tampoane crescute, 'SO _ REUSEPORT'.
Kernel/eBPF: stivă de rețea accelerată, hash consistent pentru echilibrare.
NIC offload и pinning IRQ к NUMA.
gRPC: parametrii keepalive/ping, constrângeri max-inflight.
WebSocket: piscine de conexiune, ping/pong, abonamente limită per client.

7) Fiabilitate: Cvorumuri, degradare, teste de haos

Citiți/scrieți cvorum (dacă este cazul), scrimă lider.
Moduri de degradare: readonly, „numai finalizat”, oprirea metodelor grele.
Inginerie haos: întârzieri/pierderi, reporniri, disc/eșec de rețea, scenarii „reorg de mare viteză”.

8) SLI/SLO și obiective

• p95 RPC latență pe clase de metode;
• Rata de succes; Coadă-lag p95;
• Timp până la finalitate p95 (pentru șine/poduri);
• Timp de bootstrap instantaneu;
• Creșterea de stat/zi; Saturație CPU/IO.

• P0 RPC p95 ≤ 400 ms; Disponibilitate ≥ 99. 95%;
• Releu de finalitate p95 ≤ 3 min;
• Coadă-lag P0 p95 ≤ 2 с;
• Bootstrap cititor nou ≤ 30 мин (fast-sync + instantaneu);
• Bugetul de eroare arde pe fereastra de 2 ore ≤ 2 ×.

9) Observabilitate și alertare

Valori: latență (histogramă), RPS, erori (după clasă), coadă-lag, GC/heap, disc-io, p2p peers, bârfă-rata.
Urme: end-to-end 'trace _ id' prin edge→RPC→indeksator→khraneniye→most.
Busteni: structurați, corelați prin 'request _ id'.
Alerte: burn-rate P0, coadă-lag, peer-count sub prag, reorg-spikes, instantaneu-drift.

10) Modele de autoscalare

HPA/VPA (K8s): по CPU/latență/RPS/coadă-lag; KEDA după lungimea topiarelor.
Scalarea treptată: profile de vârf de zi; Predictiv prin ML/sezonalitate.
Piese de schimb: replici de încălzire fără trafic (promovare grațioasă).
Safe rollout: canar + outlier-ejection + SLO- гейты.

11) Siguranță și izolare

mTLS/fixare cheie; RBAC/ABAC pe metode; Limitele QoS pe org/chiriaș.
Rate-limit și DoS-scut: token-uri, captchas pentru RPC-uri publice, anomalie-detectare.
Managementul secret: jetoane cu durată scurtă de viață, rotație.
Cutii de nisip: Poule separate pentru arhivă/clienți publici.

12) Configurații de referință

12. 1 K8s: RPC Gateway (Scale Out)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: rpc-gateway }
spec:
replicas: 6 strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 2, maxUnavailable: 0 } }
selector: { matchLabels: { app: rpc-gateway } }
template:
metadata: { labels: { app: rpc-gateway, qos: P0 } }
spec:
containers:
- name: gateway image: org/rpc-gateway:2. 4. 1 ports: [{ containerPort: 443 }]
resources:
requests: { cpu: "1", memory: "2Gi" }
limits:  { cpu: "4", memory: "6Gi" }
env:
- { name: MAX_CONCURRENCY, value: "400" }
- { name: CACHE_TTL_MS, value: "200" }
readinessProbe: { httpGet: { path: /healthz, port: 443 }, initialDelaySeconds: 5, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez, port: 443 }, initialDelaySeconds: 10, periodSeconds: 10 }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: rpc-gateway-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: rpc-gateway }
minReplicas: 6 maxReplicas: 36 metrics:
- type: Pods pods:
metric:
name: request_latency_p95_ms target:
type: AverageValue averageValue: 350m  # 350 мс

12. 2 Envoy: Prioritizarea și ejectarea exterioară

yaml clusters:
- name: readers type: EDS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 2s base_ejection_time: 30s circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 20000 max_pending_requests: 5000 max_requests: 20000 health_checks:
- timeout: 1s interval: 3s http_health_check: { path: /healthz }
route_config:
request_headers_to_add:
- header: { key: x-trace-id, value: "%REQ(X-TRACE-ID)%" }
weighted_clusters:
clusters:
- name: readers weight: 100

12. 3 Kafka: partiționarea pe domenii

yaml topic: "rpc. events"
partitions: 48 replicationFactor: 3 config:
retention. ms:  604800000 # 7 days max. message. bytes: 1048576 min. insync. replicas: 2 cleanup. policy: delete

12. Politica 4 QoS și limite

yaml qos:
P0:
rps_limit_per_org: 1500 queue_lag_p95_ms: 2000 retry: { attempts: 3, backoff_ms: [100,400,800] }
P1:
rps_limit_per_org: 800
P2:
rps_limit_per_org: 200 admissions:
denylist_methods: ["eth_getLogs(>10k blocks)"]
heavy_query_guard: { max_range_blocks: 5000, require_token: true }

13) Scheme de date și interogări de probă

13. 1 Node metrics (director)

sql
CREATE TABLE node_metrics (
ts TIMESTAMPTZ,
node_id TEXT, role TEXT, region TEXT,
rps INT, latency_p95_ms INT, errors_5xx INT,
queue_lag_ms INT, cpu NUMERIC, mem NUMERIC, io_wait NUMERIC
);

13. 2 SLO de control și arde rata

sql
SELECT date_trunc('hour', ts) AS h, role,
AVG(latency_p95_ms) AS p95,
100. 0 SUM(CASE WHEN latency_p95_ms <= 400 THEN 1 ELSE 0 END)/COUNT() AS slo_hit_pct
FROM node_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY 1,2;

13. 3 Planificarea sarcinii

sql
SELECT region, role,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY rps) AS rps_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY queue_lag_ms) AS lag_p95
FROM node_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY region, role;

14) Reglementări de funcționare

Zilnic: raport SLO, delta capacy, status instantanee, peer-health.
Săptămânal: revizuirea limitelor/QoS, testul DR (bootstrap din instantaneu), verificarea tăierii și compresoarelor.
Înainte de lansare: rollout canar, porți SLO și măsurători observate, plan rollback.
Contabilitatea costurilor: CTS la 1k cereri, TPS_per_$ (eficiență pe dolar).

15) Incidente Playbook

A. RPC p95 explozie de latență

1. Activați P2-throttle și eșantionarea mai mică; 2) creșterea gateway/cititor replici;

2. Transferați un anumit trafic numai în memoria cache. 4) deschideți analiza metodelor fierbinți, dacă este necesar - negarea regulilor.

B. Coadă-lag pe autobuz> SLO

1. Consumatorii autoscale (KEDA), 2) redistribuie părți, 3) opri temporar locuri de muncă în vrac.

C. Peer-count drop la validator/releu

1. Reporniți modulele p2p, 2) schimbați scaunele, 3) verificați protecția comutatorului de rețea ACL/NAT, 4).

D. lung bootstrap replica nouă

1. Comutați la instantaneu proaspăt, 2) ridicați lățimea de bandă IO, 3) eliminați temporar indexurile de arhivă.

E. Spike reorg/podul întârzieri

1. Mărire K-recunoașteri/fereastră, 2) permite „finalizat-numai” mod, 3) informa consumatorii.

16) Lista de verificare a implementării

1. Definiți rolurile site-ului și bugetele lor SLO/eroare.
2. Pentru a transporta funcții: consens/RPC/indexer/arhivă/bridge/edge.
3. Activați echilibrarea, QoS, backpressure și coada cu DLQ.
4. Configurați instantanee/sincronizare rapidă, tăiere și niveluri.
5. Conectați metrici/trasee/busteni, tablouri de bord și alerte burn-rate.
6. Configurați autoscalarea (HPA/KEDA) și versiunile canare.
7. Efectuați teste de haos și exerciții DR regulate.
8. Introduceți reglementările de funcționare și controlul costurilor.

17) Glosar

Backpressure - mecanisme de control al fluxului de intrare în timpul supraîncărcării.
DLQ - „coadă moartă” pentru mesajele cu probleme.
Tăierea - ștergeți starea istorică în afara ferestrei curente.
Fast-sync/Snapshot este o modalitate accelerată de a sincroniza o nouă replică.
Outlier-ejection - excluderea instanțelor degradate din rezervă.
Burn-rate - rata de consum a bugetului de eroare în raport cu SLO.

Linia de fund: scalarea nodurilor de rețea nu este doar „adăugați replici”, ci și disciplina de sistem a arhitecturii, QoS, managementul de stat și rigoarea operațională. Urmând acest cadru (separarea rolurilor, cozi, cache-uri, autoscale, observabilitate și SLO-uri clare), ecosistemul câștigă performanțe previzibile, rezistență maximă și costuri controlabile pe unitate de trafic.