Tarmoq tugunlarini kattalashtirish

(Bo’lim: Ekotizim va Tarmoq)

1) Uzellar rollari va trafikning konturlari

Validlovchi/ishlab chiqaruvchi (consensus/block/rollub-sequencer): yakunlashning tanqidiy yo’li.
Rider/indeksator (read-only/API/arxiv): ilovalar va tahlillarning so’rovlariga xizmat qiladi.
Releer/moslama (cross-domain): domenlar orasidagi xabarlarni/aktivlarni koʻchirish.
Shlyuz/edge (ingress/gRPC/WebSocket/QUIC): mijoz soʻrovlarini qabul qilish, rate-limit, kesh.
Tele metriya/kuzatuvchanlik: metrik/loglar/treyslarni yig’ish, sintetik namunalar.

Har bir rol uchun - o’z SLOlari, xatolar byudjeti va kengaytirish siyosati.

2) Ko’paytirish modellari

2. 1 Vertikal (scale-up)

CPU/RAM/SSD/NIC. Cho’qqilar uchun tez, ammo temir bilan cheklangan va trafik birligi narxini oshirishi mumkin.

2. 2 Gorizontal (scale-out)

Muvozanatlashtiruvchilar/navbatlar uchun nusxalar qoʻshish. Idempotentlik, sticky-siyosatchi, kvorum va kelishilgan kesshlarni (yoki ularni nogironlashtirishni) talab qiladi.

2. 3 Funksional tarqalish

Vazifalar bo’linishi: consensus uzellari izolyatsiya qilinadi; RPC/API - alohida; indeksator/arxiv - alohida; bridge/relayer - alohida.

2. 4 Geo-skeyl

Mintaqaviy klastyerlar (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; yakuniy/kechikishlar va mahalliy keshlar bilan replikatsiya qilish.

2. 5 Sharding/partiyalashtirish

Navbatlar/indeksatorlar va ustunli saqlovchilar uchun kalitlar (chainId, shard, topic) boʻyicha boʻlish.

3) So’rov yo’li: balanslash, keshlash, QoS

L4/L7 balanslash: health-checks, sticky by token/trace-id, circuit-breaker, outlier-ejection.

• edge (tez-tez o’qiladigan RPC uchun short-TTL);
• protsessor ichida (indekslar uchun read-through, write-around);
• salbiy keshlar topilmadi.
• QoS-klasslar: P0 (yakunlash/ko’prik/to’lovlar), P1 (oziq-ovqat), P2 (bulk/arxiv).
• Backpressure: tokenlar/kreditlar, concur-so’rovlarni cheklash, DLQ bilan navbatlar.
• Admissions: pre-filtr (auth, limitlar, geo/sanksiyalar), «qimmat» so’rovlarni erta rad etish.

4) Ahvolni boshqarish: snapshotlar, pruning, arxiv

Full/Pruned: RPC uchun pruned-tugunlar; Archive - alohida hovuzdagi retrospektiv so’rovlar uchun.
Snapshotlar/fast-sync: muntazam snapshotlar, tezkor bootstrap yangi nusxalar.
Hot/Warm/Cold saqlash: NVMe issiq holati, tarixiy bloklar - S3/obyekt indekslari.
Garbadge-collect/compaction: rejali oynalar.
DA/Batch-buferlar (L2/ko’priklar uchun): yetkazib berish kafolatlari va pruf-kvitansiyalar bilan tozalash davri.

5) Navbatlar va oqim bilan ishlov berish

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Konsumer guruhlari: partiyalar bo’yicha kattalashtirish, idempotent ishlov beruvchisi (outbox/inbox).
DLQ va retrajlar: eksponensial backoff, poison-message karantini.
Kelishilgan tartib: determinizm uchun partiya doirasida.

6) Transport va tarmoqni optimallashtirish

QUIC/HTTP/2: multiplekslash, head-of-line tuzatish.
TCP-tyuning: BBR/CUBIC, kattalashtirilgan buferlar,’SO _ REUSEPORT’.
Kernel/eBPF: tezlashtirilgan tarmoq steki, muvozanatlash uchun konsistent xesh.
NIC offload и pinning IRQ к NUMA.
gRPC: keepalive/ping parametrlari, max-inflight cheklovlari.
WebSocket: ulanish pullari, ping/pong, mijozga obuna boʻlishni cheklash.

7) Ishonchlilik: kvorumlar, degradatsiya, xaos-testlar

O’qish/yozish kvorumi (agar qo’llash mumkin bo’lsa), etakchining fensingi.
Degradatsion rejimlar: readonly, «faqat yakunlangan», og’ir usullarni o’chirish.
Chaos-muhandislik: kechikishlar/yo’qotishlar, qayta ishga tushirishlar, disk/tarmoq nosozligi, «tezkor reorg» stsenariylari.

8) SLI/SLO va maqsadli ko’rsatkichlar

• usullar sinflari bo’yicha p95 RPC latency;
• Success-rate; Queue-lag p95;
• Time-to-finality p95 (reley/ko’priklar uchun);
• 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 2 soatlik deraza bo’yicha ≤ 2 ×.

9) Kuzatish va alerting

Metriklar: latency (histogram), RPS, errors (sinflar bo’yicha), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Treyslar:’trace _ id’orqali edge → RPC → indeksator → saqlash → ko’prik.
Loglar: strukturalangan,’request _ id’bilan bogʻlangan.
Alertlar: burn-rate P0, queue-lag, peer-count ostonada, reorg-spayki, snapshot-drift.

10) Avtoskeyling patternlari

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; KEDA topiklar uzunligi boʻyicha.
Step-scaling: kunduzgi choʻqqilar profillari; Predictive ML/mavsumiylik bo’yicha.
Warm-spares: trafiksiz isitilgan nusxalar (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Xavfsizlik va izolyatsiya

mTLS/pinning kalitlari; usullar uchun RBAC/ABAC; QoS-limitlar per org/tenant.
Rate-limit va DoS-shield: tokenlar, ommaviy RPC uchun kapchalar, anomaliya-detekt.
Sir-menejment: qisqa umr ko’rish tokenlari, rotatsiya.
Qum qutilari: arxiv/ommaviy mijozlar uchun alohida qutilar.

12) Referens konfiguratsiyalar

12. 1 K8s: RPC-shlyuz (gorizontal kattalashtirish)

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: ustuvorlik va 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: domenlar boʻyicha partiyalashtirish

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 va limitlar siyosati

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) Ma’lumotlar sxemalari va so’rovlar namunalari

13. 1 Uzellar metrikasi (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-nazorat va 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 Yuklama rejalashtirish

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) Foydalanish reglamentlari

Har kuni: SLO, kapasiti-delta, snapshotlarning holati, peer-health bo’yicha hisobot.
Har hafta: limitlar/QoS taftishi, DR (snapshotdan bootstrap) testi, pruning va kompakshenlarni tekshirish.
Relizdan oldin: kanar rollout, SLO-geytlar va kuzatiladigan metriklar, orqaga qaytish rejasi.
Qiymatni hisobga olish: CTS per 1k so’rovlar, TPS_per_$ (bir dollarga samaradorlik).

15) Hodisalar Playbook

A. Yashirlik portlashi RPC p95

1. Sampling P2-throttle yoqish va pasaytirish; 2) gateway/reader nusxalarini ko’paytirish;

2. trafikning bir qismini faqat keshga o’tkazish; 4) issiq usullar tahlilini ochish, zarur hollarda - deny-rules.

B. Shinadagi Queue-lag> SLO

1. Konsumerlarning avtoskeyli (KEDA), 2) partiyalarni qayta taqsimlash, 3) bulk-joblarni vaqtincha to’xtatish.

C. Validator/releyda peer-count qulashi

1. p2p modullarni qayta ishga tushirish, 2) sidlarni almashtirish, 3) tarmoq ACL/NATni tekshirish, 4) zaxiraga oʻtish.

D. Yangi nusxaning uzoq bootstrap

1. Yangi snapshotga o’tish; 2) IO o’tkazish qobiliyatini oshirish; 3) arxiv indekslarini vaqtincha olib tashlash.

E. reorg spayk/ko’prik kechikishlari

1. K-tasdiqlash/oynani ko’paytirish, 2) «finalized-only» rejimini yoqish, 3) iste’molchilarni xabardor qilish.

16) Joriy etish chek-varaqasi

1. Uzellar va ularning SLO/xato byudjetlarini aniqlash.
2. consensus/RPC/indeksator/arxiv/koʻprik/edge funksiyalarini tarqatish.
3. Balans, QoS, backpressure va DLQ bilan navbatni yoqish.
4. Snapshotlarni/fast-sync, pruning va koʻp darajali saqlashni moslash.
5. Metriklar/treyslar/loglar, dashbordlar va burn-rate alertalarini ulash.
6. Avtoskeyling (HPA/KEDA) va kanareya relizlarini moslash.
7. Xaos-testlar va muntazam DR-mashqlar o’tkazish.
8. Operatsion reglamentlar va qiymatni nazorat qilish joriy etilsin.

17) Glossariy

Backpressure - ortiqcha yuklashda kirish oqimini boshqarish mexanizmlari.
DLQ - muammoli xabarlar uchun «o’lik navbat».
Pruning - dolzarb oynadan tashqari tarixiy holatni olib tashlash.
Fast-sync/Snapshot - yangi nusxani sinxronlashtirishning tezlashtirilgan usuli.
Outlier-ejection - buzilgan instansiyalarni hovuzdan chiqarish.
Burn-rate - SLOga nisbatan xatolar byudjetini sarflash tezligi.

Xulosa: tarmoq uzellarini ko’paytirish nafaqat «replika qo’shish», balki arxitektura, QoS, holatni boshqarish va operatsion qattiqlikning tizimli fanidir. Ushbu freymvorkdan (rollar, navbatlar, keshlar, avtoskeyl, kuzatuv va aniq SLO) keyin ekotizim prognoz qilinadigan unumdorlik, cho’qqilarga chidamlilik va trafikning nazorat qilinadigan qiymatiga ega bo’ladi.