English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

konuk
1 / ?
derslere geri dön

Nodelar, Kenarlar, Yönler

Bir Talebi Bir Grafik Üzerinde Gezinme

Her bileşen, talep dokunduğu her yerde node: istemci, DNS çözümleyici, CDN kenarı, geri yansıtab, arka uç kopyası, veri tabanı, önbellek.

İki düğüm arasındaki her bağlantıyı yönlendirilmiş kenar olarak okuyun: talepler ileriye, yanıtlar geri akar. İleri kenar, üstteki protokolün yanı sıra açık TCP bağlantısını temsil eder.

Bir talep, bu grafik üzerinde bir yoldur. Sistem, talebi yanıtlamak için yaptığı toplam işlemin, her düğümde yapılan işlemin toplamı ve her kenarda geçen süreyi içerdiği kadarı ile eşit.

Neden önemli? Grafiği çizdikten sonra, kodda görünmeyen özellikler ortaya çıkar:

- Hop sayısı: yoldaki kenarların sayısı. Her hop, ağ tur atışı (network round trip) + düğüm işleme) ek latency ekler. Daha az hop = daha düşük latency tabanı.

- Giriş düğüm sayısı: Bir düğme üzerine ne kadar kenar noktası. Yüksek giriş düğüm sayısı, düğminin birçok kaynaktan talepler aldığını ve kendisini ölçeklendirmesi veya koruması gerektiğini gösterir.

- Çıkış düğüm sayısı: Bir düğme üzerinden ne kadar kenar çıkıyor. Yüksek çıkış düğüm sayısı, düğminin birçok altta yatanına bağlı olduğunu ve birçok şekilde başarısız olabileceğini gösterir.

- Kesik düğüm: Bir düğüm, grafiğin kopardığı bir tek nokta. Bir geri yansıtabın ortağı olmaması, kesik düğüm; kaldırılması, orijinlarına erişimini kaldırır.

Talebi yönlendirilmiş grafik üzerinden bir yol olarak okuyun: istemci, proxy, arka uç, veri tabanı

Aşağıdaki talep grafiğini çiziniz (veya metinle açıklayın): istemci tarayıcı -> CDN kenarı -> geri yansıtab -> arka uç kopyası -> veri tabanı. Hop sayılarını sayın. Kesik düğüm noktalarını belirleyin. Birçok kesik düğümün ardışık olması durumunda işleme sonucunu tahmin edin.

Nerede Trafiğin Yoğunlaştığı

Fan-In = Yoğunluk

Giriş düğümü = ona yönelik kenar sayısı. Bir talep grafiğinde, giriş düğümü = isteği gönderenden kaç upstream kaynağına sahip olduğunu gösterir.

Fan-in düzeni: çok istemci -> bir CDN; çok CDN kenarı -> az sayıda köklü proxy; çok proxy -> daha az arka uç kopyaları; çok arka uç -> tek bir veri tabanı.

Yoğunluk önemli çünkü en yüksek giriş düğümündeki toplam yükü görür. Veritabanı zincirinin sonunda, sistemin tümünde aktif olan her talep için sorgular görebilir, hatta tek bir kullanıcı da çok az şey oluşturabilir.

Fan-Out = Bağımlılık

Çıkış düğümü = ondan çıkan kenar sayısı. Yüksek çıkış düğümü, çok sayıda downstream bağımlılığı anlamına gelir.

Bir arka uç, bir veritabanına, iki önbelleğe, üç dış API'ye ve bir kuyruğa çağırırsa çıkış düğümü 7'dir. Başarı olasılığı, başarılı bir yanıt için tümünün gerektiği durumda, her downstream'un başarı olasılığı'nın çarpıntısıdır.

0.999 ^ 7 ≈ 0.993: 7 downstream'a sahip bir arka uç, her biri %99,9 güvenilirlik ile, kendi başına ~99,3 güvenilirlik elde edebilir, kendi hataları olmadan.

Çıkış düğümünü azaltın: downstream sonuçları önbelleğe alın, önemli olmayan downstream'lar zorunlu olmaktan çıkarın (esnek gerileme), paralelize yapabileceği şeyleri.

Asimetri

Fan-in yükü yoğunlaştırır; fan-out riski katlar. En etkili noktadaki her iki şeyi de en aza indirgemeye çalışın.

En yüksek fan-in olan veri tabanı: downstream sonuçları önbelleğe alın, okuma kopyaları ile fan-in'i birden fazla düğüm arasında yayınl.

Orkestra hizmetindeki en yüksek fan-out: her bağımlılık için devre kesiciler, esnek gerileme, bölümler.

Arka uç bir kopyası, 4 downstream hizmeti bağımsız olarak çağırır, her biri %99,95 kullanılabilirlik ile. (1) Tüm 4 çağrıların başarılı bir yanıt için gerektiği durumda arka uç'un üst sınırı ne kadardır? (2) Eğer 2'si de 4 downstream'ın zorunlu olmaktan çıkarılıp esnek gerileme (kaynağından bulut depolama yapılıp kullanılamadığında) ile değiştirilirse, sınır ne olur?

Ekleme Yapılan Bir Düğüm Esneklik Alır

Indirection = Adding an Intermediate Node

Without a proxy, the graph is: client -> backend. The client must know about the backend's address. Moving the backend requires updating the client (via DNS or configuration). This is a tight binding.

With a proxy, the graph becomes: client -> proxy -> backend. The client knows only about the proxy. Moving the backend requires updating the proxy's upstream configuration, not the client.

The graph operation: insert a node along an existing edge. The new edge client -> proxy is stable; the new edge proxy -> backend is now the team's to manage.

Geometric reading: indirection adds a layer that decouples upstream change from downstream change. Each layer's edges can rewire independently.

Cost of Indirection

Each layer adds:

- One hop of latency (the edge from client to proxy)

- One more cut vertex on the path (the proxy itself)

- One more place where misconfiguration can happen

The benefits (rewire, scale, shield, terminate TLS, distribute load) usually outweigh the costs for any non-trivial system. But there is a limit: every indirection layer adds another hop & another SPOF candidate.

The folklore rule: any problem can be solved by adding a layer of indirection (except the problem of too many layers of indirection).

A team adds a CDN in front of an existing reverse proxy. The path goes from `client -> proxy -> backend` (2 hops) to `client -> CDN -> proxy -> backend` (3 hops). Name two benefits of the indirection (graph-theoretic terms welcome) & two costs.

Read an Architecture as a Graph

Synthesis

You can now read a system architecture as a graph: count hops, identify cut vertices, measure fan-in concentration, compute availability ceilings from fan-out, & evaluate indirection trade-offs.

Apply all four.

Yeni bir hizmete bu mimari sahip: clients -> CDN -> geri yansıtan proxy (2 kopya) -> arka uç katmanı (8 kopya) -> { DB ana, cache kümesi (3 düğüm), dış API }.

Analyze: (1) what is the maximum hop count on a single request path, (2) which tier has the highest fan-in (& what does it imply for scaling), (3) what is the backend availability ceiling if DB is 99.95%, cache is 99.95%, & external API is 99.9%, all required, & (4) which single node, if removed, would disconnect the most users?

Arkadaş Notları

Arkadaş Notları

Bu geometri-öğretisi, Proxies & Origins ana dersini yönlendirme analizi olarak yeniden şekillendirir.

Bu kursun sonraki arkadaşı, geometry_of_stateless_horizontal_scaling, ana ölçeklendirme dersinden kopya-matematikleri ve kuyruklama eğrisini, Little'in Yasası'nı ve %80 kullanım eşiği geometrik şekliyle çıkarır.

İyi iş çıkardın.