Węzły sieci skalowania

(Sekcja: Ekosystem i sieć)

1) Role węzłów i pętle drogowe

Walidacja/produkcja (konsensus/block/rollup-sequencer): krytyczna ścieżka finalizacji.
Czytnik/indekser (tylko do odczytu/API/archiwum): obsługuje żądania aplikacji i analityki.
Przekaźnik/most (cross-domain): przekazywanie wiadomości/aktywów między domenami.
Brama/krawędź (ingress/gRPC/WebSocket/QUIC): otrzymywanie żądań klienta, limit szybkości, pamięć podręczną.
Tele metric/observability: zbiór metryk/kłód/śladów, próbki syntetyczne.

Każda rola ma swój własny SLO, budżet błędów i polityki skalowania.

2) Modele skalowania

2. 1 Skala

Zwiększenie procesora/pamięci RAM/SSD/NIC. Szybki na szczyty, ale ograniczony przez żelazo i może zwiększyć koszt na jednostkę ruchu.

2. 2 Skala-out

Dodawanie replik za balancerami/kolejkami. Wymaga idempotencji, lepkiej polityki, kworum i konsekwentnych buforów (lub ich niepełnosprawności).

2. 3 Różnorodność funkcjonalna

Rozdzielenie obowiązków: odizolowane są węzły konsensusowe; RPC/API - oddzielnie; indekser/archiwum - oddzielnie; mostek/relayer - oddzielnie.

2. 4 Skala geograficzna

Klastry regionalne (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; Replikacja z finalizacją/opóźnieniem i lokalnymi buforami

2. 5 Shading/partycjonowanie

Rozdzielenie za pomocą klawiszy (np. Id, shard, topic) dla kolejek/indekserów i magazynów kolumn.

3) Ścieżka żądania: balancing, buforowanie, QoS

Balancing L4/L7: kontrola zdrowia, lepki za pomocą tokena/śladu-id, wyłącznik-wyłącznik, wyrzut obwodu.

• na krawędzi (krótki TTL dla często odczytywanych RPC);
• wewnątrz procesora (czytanie, zapisywanie indeksów);
• bufory ujemne (nie znaleziono).
• Klasy QoS: P0 (finalizacja/most/płatności), P1 (produkt), P2 (luzem/archiwum).
• Backpressure: żetony/kredyty, ograniczenie zamówień concur, kolejki z DLQ.
• Wstęp: wstępny filtr (auth, limity, geo/sankcje), wczesne odrzucenie „drogich” wniosków.

4) Zarządzanie statusem: migawki, przycinanie, archiwum

Pełne/przycinane: węzły suszone dla RPC; Archiwum - do zapytań retrospektywnych w oddzielnej puli.
Migawki/szybka synchronizacja: regularne migawki, szybki bootstrap nowych replik.
Hot/Warm/Cold storage: gorący stan na NVMe, historyczne bloki - S3/object z indeksami.
Garbadge-collect/compaction: zaplanowane okna, nie podczas szczytów.
DA/Partia buforów (dla L2/mostów): gwarancje dostawy i okres czyszczenia z potwierdzeniem odbioru.

5) Kolejki i strumieniowe

Ingress: Kafka/Pulsar/NATS „partition-key” = „” Id' shard 'topic „”.
Grupy konsumentów: skalowanie przez strony, idempotent handler (skrzynka odbiorcza/skrzynka odbiorcza).
DLQ i retrai: wykładniczy backoff, trucizna-wiadomość kwarantanna.
Uzgodnione zamówienie: w ramach strony na determinizm.

6) Optymalizacja transportu i sieci

QUIC/HTTP/2: multipleksowanie, korekta głowicy linii.
Dostrajanie TCP: BBR/CUBIC, zwiększone bufory, „SO _ REUSEPORT”.
Jądro/eBPF: przyspieszony stos sieciowy, spójne hash do równoważenia.
NIC offload clinning IRQ мРАНА.
gRPC: parametry utrzymujące się/ping, maksymalne ograniczenia natężenia światła.
WebSocket: puli połączeń, ping/pong, subskrypcje limitowane na klienta.

7) Niezawodność: Kworum, degradacja, testy chaosu

Czytaj/pisz kworum (jeśli dotyczy), ogrodzenie lidera.
Tryby degradacji: czytelnie, „tylko sfinalizowane”, wyłączając ciężkie metody.
Inżynieria chaosu: opóźnienia/straty, ponowne uruchomienie, awaria dysku/sieci, scenariusze „szybkiego reorg”.

8) SLI/SLO i cele

• p95 opóźnienie RPC według klasy metody;
• Wskaźnik sukcesu; Kolejka-lag p95;
• Czas do końca p95 (dla szyn/mostów);
• Czas snapshot bootstrap;
• wzrost stanu/dzień; Nasycenie procesora/IO.

• P0 RPC p95 ≤ 400 ms; Dostępność ≥ 99. 95%;
• przekaźnik końcowy p95 ≤ 3 min;
• Kolejka-lag P0 p95 ≤ 2 μ;
• Nowy czytnik Bootstrap ≤ 30 мий (fast-sync + snapshot);
• Budżet błędu spala się w 2-godzinnym oknie ≤ 2 ×.

9) Obserwowalność i ostrzeganie

Wskaźniki: opóźnienie (histogram), RPS, błędy (według klasy), kolejka-lag, GC/hałd, disk-io, p2p rówieśników, szybkość plotkowania.
Ślady: end-to-end 'trace _ id' przez krawędź → RPC → indeksator → khraneniye → większość.
Dzienniki: struktura, korelacja przez 'request _ id'.
Wpisy: szybkość spalania P0, kolejka-lag, peer-count poniżej progu, reorg-kolce, migawka-dryf.

10) Autoskalowanie wzorów

HPA/VPA (K8s): ма CPU/latency/RPS/queue-lag; KEDA według długości toparek.
Skalowanie krokowe: dzienne profile szczytowe; Predykcyjne według ML/sezonowości.
Warm-spares: rozgrzewka repliki bez ruchu (wdzięczna promocja).
Bezpieczny rollout: kanaryjski + outlier-ejection + SLO-бебта.

11) Bezpieczeństwo i izolacja

mTLS/szpilki klucza; RBAC/ABAC według metod; Limity QoS na org/najemcę.
Limit i tarcza DoS: żetony, captchas dla publicznych RPC, wykrywanie anomalii.
Tajne zarządzanie: krótkotrwałe żetony, rotacja.
Piaskownice: Oddzielne pule dla archiwum/klientów publicznych.

12) Konfiguracje referencyjne

12. 1 K8s: Brama RPC (skala)

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 Wysłannik: Priorytetowe traktowanie i wyrzucanie na zewnątrz

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: podział według domeny

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. 4 Polityka QoS i limitów

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) Schematy danych i zapytania dotyczące próbek

13. 1 Metryka węzła (katalog)

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 kontrola i szybkość spalania

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 Planowanie obciążenia

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) Przepisy eksploatacyjne

Codziennie: raport SLO, pojemność delta, status migawek, zdrowie rówieśników.
Co tydzień: przegląd limitów/QoS, test DR (bootstrap z migawki), sprawdzanie przycinania i sprężarek.
Przed zwolnieniem: kanaryjski rollout, bramki SLO i obserwowane metryki, plan rollback.
Rachunkowość kosztów: CTS na 1k żądania, TPS_per_$ (wydajność za dolar).

15) Incydenty Playbook

A. Eksplozja opóźnienia RPC p95

1. Umożliwia P2-throttle i niższe pobieranie próbek; 2) zwiększenie bramy/repliki czytnika;

2. Przenieś trochę ruchu tylko do pamięci podręcznej. 4) otworzyć analizę gorących metod, w razie potrzeby - zasady odmowy.

B. Kolejka-lag w autobusie> SLO

1. Konsumenci autoskalni (KEDA), 2) redystrybucja stron, 3) tymczasowo wstrzymać pracę masową.

C. Spadek liczby równej przy walidatorze/przekaźniku

1. Ponowne uruchomienie modułów p2p, 2) zmiana siedzeń, 3) sprawdzenie sieci ACL/NAT, 4) ochrona przełącznika.

D. Długi bootstrap nowa replika

1. Przełączyć na świeże migawki, 2) zwiększyć przepustowość IO, 3) tymczasowo usunąć indeksy archiwów.

E. Spike reorg/opóźnienia mostu

1. Powiększyć K-potwierdzenia/okno, 2) włączyć tryb „sfinalizowane tylko”, 3) poinformować konsumentów.

16) Lista kontrolna wdrażania

1. Zdefiniuj role witryny i ich budżety SLO/błędów.
2. Do przenoszenia funkcji: consensus/RPC/indexer/archive/bridge/edge.
3. Włącz równoważenie, QoS, backpressure i kolejkę z DLQ.
4. Skonfiguruj migawki/szybką synchronizację, przycinanie i wielopoziomowość.
5. Podłącz mierniki/ścieżki/dzienniki, deski rozdzielcze i alerty szybkości spalania.
6. Skonfiguruj autoskalowanie (HPA/KEDA) i wersje kanarkowe.
7. Przeprowadzić testy chaosu i regularne ćwiczenia DR.
8. Wprowadzenie przepisów eksploatacyjnych i kontroli kosztów.

17) Słownik

Ciśnienie wsteczne - mechanizmy kontroli przepływu wejściowego podczas przeciążenia.
DLQ - „martwa kolejka” dla wiadomości problemowych.
Przycinanie - usuń stan historyczny poza bieżącym oknem.
Szybka synchronizacja/migawka to przyspieszony sposób synchronizacji nowej repliki.
Wyrzut zewnętrzny - wyłączenie zdegradowanych instancji z basenu.
Wskaźnik spalania - wskaźnik zużycia w budżecie błędu w stosunku do SLO.

Bottom line: skalowanie węzłów sieciowych jest nie tylko „dodać repliki”, ale dyscyplina systemu architektury, QoS, zarządzanie państwem i rygor operacyjny. Stosując się do tych ram (rozdzielenie ról, kolejki, bufory, autoskale, obserwowalność i jasne SLO), ekosystem zyskuje przewidywalną wydajność, maksymalną odporność i kontrolowany koszt na jednostkę ruchu.