GH GambleHub

Şəbəkə düyünlərini ölçmək

(Bölmə: Ekosistem və Şəbəkə)

1) Düyün rolları və trafik konturları

Doğrulayıcı/prodüser (consensus/block/rollub-sequencer): kritik sonlandırma yolu.
Reader/indeksator (read-only/API/arxiv): proqram və analitik sorğulara xidmət edir.
Releaser/Bridge (cross-domain): domenlər arasında mesajların/aktivlərin köçürülməsi.
Şluz/edge (ingress/gRPC/WebSocket/QUIC): müştəri sorğularının qəbulu, rate-limit, cache.
Tele metriya/müşahidə: metrik/yuva/treys toplamaq, sintetik nümunələr.

Hər bir rol üçün - öz SLO, səhv büdcəsi və miqyas siyasəti.

2) Ölçmə modelləri

2. 1 Şaquli (scale-up)

CPU/RAM/SSD/NIC artırın. Zirvələr üçün sürətli, lakin dəmir ilə məhdudlaşır və trafik vahidinin dəyərini artıra bilər.

2. 2 Üfüqi (scale-out)

Balanslayıcılar/növbələr üçün replikaların əlavə edilməsi. İdempotentlik, sticky-siyasətçi, kvorum və razılaşdırılmış caches (və ya onların əlilliyi) tələb edir.

2. 3 Funksional yayılma

Vəzifə ayrılması: consensus düyünlər təcrid olunur; RPC/API - ayrıca; indeksator/arxiv - ayrıca; bridge/relayer - ayrıca.

2. 4 Geo Skale

Regional klasterlər (EU/US/AP) + anycast/GeoDNS/Latency Aware LB; finalizasiya/gecikmələr və yerli caches ilə replikasiya.

2. 5 Şarding/Partizan

Növbələr/indeksatorlar və sütunlu anbarlar üçün açarlar (chainId, shard, topic).

3) Sorğu yolu: balans, caching, QoS

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

Keşlər:
  • edge (tez-tez oxunan RPC üçün short-TTL);
  • prosessor daxilində (indekslər üçün read-through, write-around);
  • mənfi caches (tapılmadı).
  • QoS sinifləri: P0 (sonlandırma/körpü/ödənişlər), P1 (ərzaq), P2 (bulk/arxiv).
  • Backpressure: tokenlər/kreditlər, concur-sorğuların məhdudlaşdırılması, DLQ ilə növbələr.
  • Admissions: pre-filter (auth, limitlər, geo/sanksiyalar), «bahalı» sorğuların erkən rədd edilməsi.

4) Vəziyyətin idarə edilməsi: snapshots, pruninq, arxiv

Full/Pruned: RPC üçün pruned-düyünlər; Arxiv - ayrı bir hovuzda retrospektiv sorğular üçün.
Snapshot/fast-sync: müntəzəm snapshot, sürətli bootstrap yeni replikalar.
Hot/Warm/Cold saxlama: NVMe isti vəziyyət, tarixi bloklar - S3/indeks ilə obyekt.
Garbadge-collect/compaction: planlı pəncərələr, zirvə zamanı deyil.
DA/Batch tamponları (L2/körpülər üçün): çatdırılma zəmanəti və pruf qəbzləri ilə təmizləmə müddəti.

5) Növbələr və axın emalı

Ingress: Kafka/Pulsar/NATS с partition-key = `chainId|shard|topic`.
Konsumer qrupları: partiyalar üzrə miqyaslandırma, idempotent prosessor (outbox/inbox).
DLQ və retrajlar: eksponensial backoff, poison-message karantin.
Razılaşdırılmış prosedur: determinizm üçün partiya çərçivəsində.

6) Nəqliyyat və şəbəkə optimallaşdırma

QUIC/HTTP/2: multiplex, head-of-line korreksiyası.
TCP sazlama: BBR/CUBIC, böyüdülmüş tamponlar, 'SO _ REUSEPORT'.
Kernel/eBPF: tezləşdirilmiş şəbəkə yığın, balans üçün konsistent hash.
NIC offload и pinning IRQ к NUMA.
gRPC: keepalive/ping parametrləri, max-inflight məhdudiyyətləri.
WebSocket: bağlantı hovuzları, ping/pong, müştəriyə abunə məhdudiyyətləri.

7) Etibarlılıq: kvorumlar, deqradasiya, xaos testləri

Oxu/yazma kvorumu (mümkünsə), liderin fensinqi.
Deqradasiya rejimləri: readonly, «yalnız yekunlaşdırılmış», ağır üsulları söndürmək.
Chaos mühəndisliyi: gecikmələr/itkilər, yenidən başlamalar, disk/şəbəkənin nasazlığı, «sürətli reorq» ssenariləri.

8) SLI/SLO və hədəf göstəriciləri

SLI (nümunə):
  • p95 RPC latency metodları siniflərinə görə;
  • Success-rate; Queue-lag p95;
  • Time-to-finality p95 (relay/körpülər üçün);
  • Snapshot bootstrap time;
  • State growth/day; CPU/IO saturation.
SLO (göstəricilər):
  • P0 RPC p95 ≤ 400 ms; Availability ≥ 99. 95%;
  • Finality relay p95 ≤ 3 dəq;
  • Queue-lag P0 p95 ≤ 2 с;
  • Bootstrap new reader ≤ 30 мин (fast-sync+snapshot);
  • Error budget burn 2 saatlıq pəncərə ≤ 2 ×.

9) Müşahidə və alertinq

Metriklər: latency (histogram), RPS, errors (siniflər üzrə), queue-lag, GC/heap, disk-io, p2p peers, gossip-rate.
Traces: edge → RPC → indeksator → saxlama → körpü vasitəsilə 'trace _ id' vasitəsilə.
Qeydlər: strukturlaşdırılmış, 'request _ id' ilə korrelyasiya.
Alertlər: burn-rate P0, queue-lag, peer-count, reorg-spikes, snapshot-drift.

10) Avtoskeylinq nümunələri

HPA/VPA (K8s): по CPU/latency/RPS/queue-lag; Topiklərin uzunluğuna görə KEDA.
Step-scaling: gündüz zirvələrinin profilləri; Predictive ML/mövsümi.
Warm-spares: trafiksiz qızdırılmış replikalar (graceful promote).
Safe rollout: canary + outlier-ejection + SLO-гейты.

11) Təhlükəsizlik və izolyasiya

mTLS/pinning açarları; RBAC/ABAC metodları; QoS limitləri per org/tenant.
Rate-limit və DoS-shield: ictimai RPC üçün tokenlər, kapçalar, detektiv anomaliyalar.
Gizli idarəetmə: qısa ömürlü tokenlər, rotasiya.
Qum qutuları: arxiv/ictimai müştərilər üçün ayrı boşluqlar.

12) Referans konfiqurasiyası

12. 1 K8s: RPC qapısı (üfüqi miqyaslı)

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: prioritetləşdirmə və 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: domenlərə görə partizan

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 və Limitlər Siyasəti

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) Məlumat sxemləri və sorğu nümunələri

13. 1 Düyün ölçüləri (kataloq)

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-nəzarət və 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 Yük planlaşdırma

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) Əməliyyat qaydaları

Gündəlik: SLO, kapasiti-delta, snapshot vəziyyəti, peer-health.
Həftəlik: limitlərin təftişi/QoS, DR testi (snapshot bootstrap), pruninq və kompakşenlərin yoxlanılması.
Buraxılışdan əvvəl: kanarya rollout, SLO geytaları və müşahidə olunan metriklər, geri dönüş planı.
Dəyər uçotu: CTS per 1k sorğular, TPS_per_$ (dollar başına effektivlik).

15) Playbook hadisələr

A. RPC p95 gecikmə partlayışı

1. P2-throttle aktiv və aşağı sampling; 2) gateway/reader replikaları artırmaq;

2. trafikin bir hissəsini yalnız cache köçürmək; 4) isti metodların analizini açmaq, lazım olduqda - deny-rules.

B. şin Queue-lag> SLO

1. Avtoskeyl konsumerləri (KEDA), 2) partiyalar yenidən bölüşdürün, 3) bulk jobları müvəqqəti dayandırın.

C. validator/releydə peer-count düşməsi

1. p2p modullarının yenidən başlaması, 2) oturacaqların dəyişdirilməsi, 3) şəbəkə ACL/NAT yoxlaması, 4) ehtiyat keçid.

D. Uzun bootstrap yeni replika

1. Təzə snapshot keçid, 2) IO bant genişliyini artırmaq, 3) müvəqqəti arxiv indeksləri çıxarmaq.

E. reorg/körpü gecikmələri

1. K-təsdiq/pəncərə artırmaq, 2) «finalized-only» rejimi yandırmaq, 3) istehlakçıları məlumatlandırmaq.

16) Giriş çek siyahısı

1. Düyünlərin rollarını və onların SLO/səhv büdcələrini müəyyənləşdirin.
2. Funksiyalar: consensus/RPC/indeksator/arxiv/körpü/edge.
3. Balans, QoS, backpressure və DLQ ilə növbə daxil edin.
4. Snapshot/fast-sync, pruning və çox səviyyəli saxlama konfiqurasiya.
5. Metrik/treys/log, dashboard və burn-rate alert qoşun.
6. Avtoskeylinq (HPA/KEDA) və kanarya buraxılışlarını konfiqurasiya edin.
7. Xaos testləri və müntəzəm DR təlimləri keçirin.
8. Əməliyyat qaydaları və dəyər nəzarəti tətbiq edin.

17) Lüğət

Backpressure - həddindən artıq yükləmə zamanı giriş axını idarəetmə mexanizmləri.
DLQ - problemli mesajlar üçün «ölü növbə».
Pruning - mövcud pəncərədən kənarda tarixi vəziyyəti silmək.
Fast-sync/Snapshot - yeni replika sinxronizasiyasının sürətləndirilmiş yolu.
Outlier-ejection - deqradasiyaya uğramış instansiyaların hovuzdan çıxarılması.
Burn-rate - SLO ilə bağlı büdcə xərclərinin sürəti.

Nəticə: şəbəkə qovşaqlarının miqyası yalnız «replika əlavə etmək» deyil, memarlıq, QoS, vəziyyətin idarə edilməsi və əməliyyat sərtliyinin sistem intizamıdır. Bu çərçivəni (rolların bölünməsi, növbələr, keşlər, avtoskeyl, müşahidə və aydın SLO) izləyən ekosistem proqnozlaşdırıla bilən performans, pik müqavimət və vahid trafikə nəzarət olunan qiymət əldə edir.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.