擴展網絡節點

（部分： 生態系統和網絡）

1）節點角色和流量輪廓

驗證/生產（consensus/block/rollup-sequencer）：關鍵最終化路徑。
Reader/索引器 （read-only/API/存檔）：服務於應用程序請求和分析。
接線/橋（cross-domain）：在域之間移動消息/資產。
網關/邊緣（ingress/gRPC/WebSocket/QUIC）：接收客戶端請求、限額、緩存。
物體/可觀察性：收集指標/標誌/示蹤劑，合成樣品。

每個角色都有自己的SLO、錯誤預算和擴展策略。

2）縮放模型

2.1垂直尺度)

CPU/RAM/SSD/NIC的增加。快速達到峰值，但僅限於鐵，並且可以提高交通單位的成本。

2.2水平（scale-out）

在平衡器/隊列後面添加復制副本。它需要冪等性，粘性政策，法定人數和商定的緩存（或其殘疾）。

2.3功能分隔

職責分工：consensus節點是隔離的；RPC/API-分開；索引器/存檔-單獨；bridge/relayer-分開。

2.4地理滑道

區域集群（EU/US/AP）+anycast/GeoDNS/Latency Aware LB；使用最終化/延遲和本地緩存進行復制。

2.5 Sharding/派對

按鍵（chainId, shard, topic）分隔隊列/索引器和柱存儲。

3）查詢路徑： 平衡,緩存,QoS

L4/L7平衡：健康檢查，在令牌/trace-id上粘貼，電路斷路器，outlier ejection。

• 在邊緣（用於常讀RPC的短TTL）；
• 處理器內部（讀取，索引寫入）；
• 負緩存（未找到）。
• QoS類：P0（決賽/橋梁/付款），P1（雜貨），P2（散裝/存檔）。
• Backpressure：令牌/信用,concur查詢限制,隊列與DLQ。
• 錄取：預過濾器（auth，限制，地理/制裁），提前拒絕「昂貴」請求。

4）狀態管理： snapshots，惡作劇，檔案

Full/Pruned：用於RPC的未啟動節點；Archive-用於在單獨的池中進行回顧性查詢。
快照/快速同步：定期快照，快速啟動新副本。
Hot/Warm/Cold存儲：NVMe上的熱狀態,歷史塊為S3/具有索引的對象。
Garbadge-collect/compaction：計劃窗口,不在峰值期間。
DA/Batch緩沖區（用於L2/Bridges）：交付保證和帶收據的清潔期。

5）隊列和流處理

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.

用戶組：按批次擴展，等效處理程序（outbox/inbox）。
DLQ和retrai：指數反射，毒藥消息檢疫。
商定順序：在決定論的黨內。

6）運輸和網絡優化

QUIC/HTTP/2：多路復用，線頭校正。
TCP調音：BBR/CUBIC，擴展緩沖區，「SO_REUSEPORT」。
Kernel/eBPF：加速網絡堆棧，用於平衡的一致性哈希。

NIC offload и pinning IRQ к NUMA.

gRPC： keepalive/ping選項,max-inflight限制。
WebSocket：連接池、ping/pong、客戶端訂閱限制。

7）可靠性： 法定人數,退化,混沌測試

讀寫/寫入法定人數（如適用）,負責人fensing。
降級模式：readonly，「僅限最終化」，關閉重方法。
混沌工程：延遲/損失，重新啟動，驅動器/網絡故障，「速度重構」腳本。

8） SLI/SLO和目標

• p95 RPC按方法類別後退；
• Success-rate;Queue-lag p95;
• 時間到最終的p95（用於接線/橋梁）；
• Snapshot bootstrap time;
• State growth/day;CPU/IO saturation.

• P0 RPC p95 ≤ 400毫秒；Availability ≥ 99.95%;
• Finality relay p95 ≤ 3分鐘；
• Queue-lag P0 p95 ≤ 2 с;
• Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
• 2小時窗戶上的錯誤預算燒毀≤ 2 ×。

9）可觀察性和異位

度量標準：latency（histogram），RPS，errors（按類），queue-lag，GC/heap，disk-io，p2p peers，gossip-rate。
Traces：通過edge→RPC→indeksator→khraneniye→most直通式「trace_id」。
Logs：結構化的「request_id」相關性。
Alerts： burn-rate P0, queue-lag, peer-count低於閾值,reorg-spikes, snapshot-drift。

10）自動滑行模式

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag;KEDA按斧頭長度。
步長：白天高峰輪廓；根據ML/季節性進行預測。
Warm-spares：變暖的副本無流量（graceful promote）。

Safe rollout: canary + outlier-ejection + SLO-гейты.

11）安全與隔離

mTLS/按鍵；RBAC/ABAC方法；QoS限制per org/tenant。
Rate-limit和DoS-shield：令牌，公共RPC的帽子，異常特征。
秘密管理：短壽命令牌，輪換。
沙箱：存檔/公共客戶的分離池。

12）參考配置

12.1 K8s：RPC網關（水平縮放）

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：優先級和outlier-ejection

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：按領域分組

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 QoS政策和限制

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）數據模式和查詢示例

13.1節點度量（目錄）

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控制和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負載規劃

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）操作法規

每天：SLO報告，kapasiti三角洲，snapshots狀態，同行健康。
每周：限制/QoS修訂，DR測試（從狙擊手中引導），打孔和編譯檢查。
發布前：金絲雀滾動、SLO門和可觀察到的指標、回滾計劃。
成本核算：CTS per 1k查詢，TPS_per_$（每美元效率）。

15）事件劇本

A. RPC p95潛伏期爆炸

1.啟用P2-throttle並降級采樣；2）增加網關/讀者復制品；

2.將部分流量轉換為僅緩存；4）打開熱方法分析，如果需要-deny-rules。

B.總線上的Queue-lag> SLO

1.Consumers Autoscale （KEDA）, 2）重新分配派對,3）暫時停止bulk-joba。

C.驗證器/繼電器同比計數下降

1.重新啟動p2p模塊，2）更改座椅，3）檢查網絡ACL/NAT，4）切換到備份。

D.新復制品冗長的引導程序

1.切換到新鮮的snapshot，2）提高IO吞吐量，3）暫時刪除存檔索引。

E. Spike reorg/橋梁延誤

1.增加K確認/窗口，2）啟用「僅限最終」模式，3）通知消費者。

16）實施支票

1.定義節點角色及其SLO/錯誤預算。
2.分解功能：consensus/RPC/索引器/歸檔/bridge/Edge。
3.啟用平衡、QoS、backpressure和DLQ隊列。
4.自定義snapshot/fast sync、pruning和分層存儲。
5.連接度量/traces/logs、dashbords和burn-rate alerta。
6.設置自動滑行（HPA/KEDA）和金絲雀發行版。
7.進行混沌測試和定期的DR演習。
8.引入運營法規和成本控制。

17）詞匯表

Backpressure-過載時控制輸入流的機制。
DLQ是問題消息的「死隊列」。
Pruning-刪除當前窗口之外的歷史狀態。
快速同步/快照是一種快速同步新副本的方法。
Outlier-ejection-從池中排除退化實例。
Burn-rate-相對於SLO的錯誤預算支出率。

底線：擴展網絡節點不僅是「添加副本」,而且是體系結構、QoS、狀態管理和操作嚴謹性的系統學科。遵循此框架（角色劃分，隊列，緩存，自動軌道，可觀察性和清晰的SLO），生態系統獲得了可預測的性能，峰值抵抗力和每單位交通的可控成本。