Escalar nós de rede

(Secção: Ecossistema e Rede)

1) Rolos de nós e contornos de tráfego

Validadores/produtores (consensus/block/rollup-sequencer): caminho crítico de finalização.
Reder/indexador (read-only/API/arquivo): atende a solicitações de aplicativos e analistas.
Relier/ponte (cross-domain): transferência de mensagens/ativos entre os domínios.
Gateway/edge (ingress/gRPC/WebSocket/QUIC): recepção de solicitações de clientes, rate-limit, dinheiro.
Metria/observabilidade corporal: coleta de métricas/logs/trailers, amostras sintéticas.

Cada papel tem seu próprio SLO, orçamento de erro e política de zoom.

2) Modelos de zoom

2. 1 Vertical (scale-up)

Aumento do CPU/RAM/SSD/NIC. Rápido para picos, mas restrito ao ferro e pode aumentar o custo da unidade de tráfego.

2. 2 Horizontal (scale-out)

Adicione réplicas atrás de balanceadores/filas. Requer idempotidade, política de sticky, quórum e capas conveniadas (ou sua deficiência).

2. 3 Disseminação Funcional

Separação de responsabilidades: consensus nódulos são isolados; RPC/API - separadamente; indexador/arquivo - separadamente; bridge/relayer - separadamente.

2. 4 Geo-scale

Clusters regionais (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; replicação com finalização/atrasos e caixas locais.

2. 5 Charding/particionização

Divisão por chave (chainId, shard, topic) para filas/indexadores e armazéns invertebrados.

3) Caminho de consulta: balanceamento, cachê, QoS

L4/L7 balanço: health-checks, sticky por token/trace-id, circuito-breaker, outlier-ejation.

• em edge (short-TTL para RPC frequentemente lido);
• dentro do processador (read-through, write-around para índices);
• cachês negativos (não encontrado).
• Classe QoS: P0 (finalização/ponte/pagamentos), P1 (alimentos), P2 (bulk/arquivo).
• Backpressure: tokens/créditos, limitação de solicitações de concur, filas com DLQ.
• Admissions: filtro pré (auth, limites, geo/sanções), rejeição precoce de solicitações «caras».

4) Gerenciamento de estado: snapshots, lining, arquivo

Full/Pruned: nós pruned para RPC; Archive - para consultas retrospectivas em uma bala separada.
Snapshots/fast-sync: snapshots regulares, bootstrap rápido novas réplicas.
Hot/Warm/Cold armazenamento: estado quente em NVMe, blocos históricos - S3/objeto com índices.
Garbadge-collect/competition: janelas programadas, não durante picos.
D/Batch-tampões (para L2/pontes): garantia de entrega e período de limpeza com recibos de lago.

5) Filas e streaming

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Grupos de Consumer: zoom em partituras, processador idumpotente (outbox/inbox).
DLQ e retrai: backoff exponencial, quarentena poison-mensagem.
Ordem alinhada, como parte de uma partitura para o determinismo.

6) Transporte e otimização de rede

QUIC/HTTP/2: multiplexe, head-of-line correção.
Sintonização TCP: BBR/CUBIC, tampões aumentados, 'SO _ REUSEPORT'.
Kernel/eBPF: pilha de rede acelerada, hash consistente para balanceamento.
NIC offload и pinning IRQ к NUMA.
gRPC: opções keepalive/ping, limitações max-inflight.
WebSocket: pool de conexões, ping/pong, limite de assinaturas por cliente.

7) Confiabilidade: quórum, degradação, testes de caos

Quórum de leitura/escrita (se aplicável), fensing do líder.
Modos de degradação: readonly, «apenas finalizados», desativação de métodos pesados.
Engenharia Chaos: atrasos/perdas, reinício, falha de disco/rede, «reorg rápido» do cenário.

8) SLI/SLO e metas

• p95 RPC latency em classes de métodos;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (para reles/pontes);
• Snapshot bootstrap time;
• State growth/day; CPU/IO saturation.

• P0 RPC p95 ≤ 400 ms; Availability ≥ 99. 95%;
• Finality relay p95 ≤ 3 min;
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• Error budget burn por janela de 2 horas ≤ 2 x.

9) Observabilidade e alerting

Métricas: latency (historograma), RPS, errors (em classes), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Trailers: «trace _ id» por meio de edge→RPC→indeksator→khraneniye→most.
Logs: estruturados, correlação por 'request _ id'.
Alert: burn-rate P0, queue-lag, peer-count abaixo do limiar, reorg-spacks, snapshot-drivt.

10) Pattern de skeiling automático

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA de comprimento de topics.
Step-escaling: perfis de picos diurnos; Preditiva por ML/sazonalidade.
Warm-spares: réplicas aquecidas sem tráfego (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Segurança e isolamento

mTLS/pinning chaves; RBAC/ABAC para métodos; QoS-limite per org/tenant.
Rate-limit e DoS-shield: tokens, capches para RPC público, anomalia-detecção.
Gestão secreta, tokens curtos, rotação.
Barras de areia: Poulas separadas para arquivos/clientes públicos.

12) Configurações de arbitragem

12. 1 K8s: passarela RPC (escala horizontal)

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: priorização e outler-ejation

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: partilhar domínios

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 Políticas de QoS e limites

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) Esquemas de dados e exemplos de consultas

13. 1 Métricas de nós (diretório)

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 controle SLO e burn-rate

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 Planejamento de carga

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) Regulamentos operacionais

Diariamente: Relatório de SLO, Capasiti Delta, Estado de Snapshot, peer-health.
Semanalmente: revisão de limites/QoS, teste de DR. (bootstrap de snapshot), verificação de prouning e compactos.
Antes do lançamento, rollout de canário, gates SLO e métricas observáveis, plano de reversão.
Contabilidade de custo: CTS por 1k consultas, TPS _ per _ $ (eficiência por dólar).

15) Playbook incidentes

A. Explosão de latência RPC p95

1. Ativar P2-throttle e rebaixar sampling; 2) aumentar as réplicas gateway/reader;

2. transferir parte do tráfego para o dinheiro apenas; 4) abrir a análise de métodos quentes, se necessário - deny-rulas.

B. Queue-lag em pneu> SLO

1. O scale automático dos consoadores (KEDA), 2) redistribuir as partições, 3) parar temporariamente os bulk-jobs.

C. Queda de peer-count em validador/relevo

1. Reiniciamento de p2p módulos, 2) mudança de banco, 3) verificação de LCA/NAT, 4) mudança para reserva.

D. Longo bootstrap nova réplica

1. Mudar para o snapshot fresco, 2) elevar a largura de banda IO, 3) remover temporariamente os índices de arquivo.

E. Spike reorg/atrasos de ponte

1. Aumentar as confirmações K/janela, 2) ativar modo «finalized-only», 3) informar os consumidores.

16) Folha de cheque de implementação

1. Definir papéis de nó e seus orçamentos de erro SLO.
2. Separar as funções consensus/RPC/indexador/arquivo/ponte/edge.
3. Incluir balanço, QoS, backpressure e fila com DLQ.
4. Personalizar snapshots/fast-sync, lining e armazenamento em vários níveis.
5. Ligar métricas/trailers/logs, dashboards e burn-rate alerts.
6. Personalizar scailing automático (HPA/KEDA) e lançamentos canários.
7. Fazer testes de caos e exercícios regulares de DR..
8. Introduzir regulamentos operacionais e controle de custo.

17) Glossário

Backpressure - Mecanismos de controle de fluxo de entrada para sobrecarga.
DLQ - «fila morta» para mensagens problemáticas.
Pruning - remover um estado histórico fora da janela atual.
Fast-sync/Snapshot é uma forma acelerada de sincronizar a nova réplica.
Outler-ejation é a exclusão de instâncias degradadas do pool.
Burn-rate - velocidade de vazão do orçamento de erros em relação ao SLO.

Resultado: a dimensão de nódulos de rede não é apenas «adicionar réplicas», mas sim a disciplina do sistema de arquitetura, QoS, gestão de estado e rigor operacional. Seguindo este quadro (separação de papéis, filas, cachês, scale automático, observabilidade e SLO nítido), o ecossistema tem desempenho previsível, resistência a picos e custo controlado por unidade de tráfego.