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 İstek Bir Grafik Üzerinde Gezinme

Her bileşen bir istekle temaslı olan her şey bir node'dır: müşteri, DNS çözümleyici, CDN kenarı, ters proxy, arka uç kopyası, veri tabanı, önbellek.

İki düğüm arasındaki her bağlantı bir yönlendirilmiş kenardır: istekler ileri doğru, yanıtlar geri doğru akar. İlerleyen kenar, üzerinde bulunan protokolün yanı sıra açık TCP bağlantısı temsil eder.

Bir tek istek bu grafik üzerinden bir yoldur. Sistem, isteği yanıtlaması için yaptığı toplam işleve, her düğümdeki işlemin toplamı ve her kenardaki gecikmeyle eşittir.

Nasıl önemli? Grafik resmi çizen andıran, kodda görünmeyen özellikler ortaya çıkar:

- Hop sayımı: yoldaki kenar sayısı. Her hop, gecikme süresi ekler (ağ turu + düğüm işleme). Az sayıda hop = daha düşük gecike sahip bir zemin.

- Giriş açıklığı: bir düğme üzerine ne kadar çok kenar yöneldiğini gösterir. Yüksek giriş açıklığı, düğminin kendisini büyütmeye ya da kendini korumaya zorlar.

- Çıkış açıklığı: bir düğme üzerinden ne kadar çok dışa doğru kenar yöneldiğini gösterir. Yüksek çıkış açıklığı, düğme, birçok alt yapıya bağlı ve birçok yolda başarısız olma eğiliminde olacaktır.

- Kesik düğüm: bir düğüm, grafiği kestiğinde tek başına çıkar. Bir ters proxy'nin komşisiz olduğu bir durumda, kesik düğüm; kaldırılması durumunda, köklere erişimini ortadan kaldıracak şekilde çıkar.

İstek bir yönlendirilmiş grafik yol olarak kabul edilir: müşteri, proxy, arka uç, veri tabanı

İnternet tarayıcı -> CDN kenarı -> ters proxy -> arka uç kopyası -> veri tabanı. Hops sayısını sayın. Kesik kenarlarını belirleyin. Birçok kesik kenarın olduğu bir durumda, bu durumun bir işlemsel sonucunu tahmin edin.

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

Fan-In = Yoğunluk

Giriş düğümünün in-degrees = ona yön veren kenarlara ait sayı. Bir talep grafiğinde, in-degree = aktif bir talep olan her biri için sistemden gelen istek sayısı.

Fan-in düzeni: birçok müşteri -> bir CDN; birçok CDN kenarı -> az sayıda köklü proxy; birçok proxy -> daha az sayıda arka uyduları; birçok arka uydusu -> tek bir veritabanı.

Konsantrasyon önemli çünkü en yüksek in-degree düğüm, sistemin tüm bölümlerinden daha fazla toplam yük görür. Sistemdeki her etkin talep tarafından oluşturulan soruları gören son DB'ye (veritabanı) ulaşabilir.

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

Çıkış düğümünün out-degrees = ondan çıkacak kenarlara ait sayı. Yüksek out-degree, birçok alt bağımlılığa işaret eder.

Bir arka uç, bir veritabanına, iki önbelleğe, üç dış API'ye ve bir kuyruk'a çağrı yaptığında, out-degree 7'tir. Başarılı bir yanıt için her biri için başarı olasılığı yaklaşık olarak her birinin başarı olasılığı ürününün karesi olur.

0,999 ^ 7 ≈ 0,993: 7 downstream her biri %99,9 güvenilirlik ile 7 downstream her biri %99,9 güvenilirlik ile bir arka uç, kendi başarısızlığı olmadan sadece ~%99,3 başarısızlık elde edebilir.

Out-degree'yi azaltmak: downstream sonuçlarını önbelleğe almak, önemli olmayan downstream'ları opcional hale getirmek (esnek gerileme), paralel olanı paraleleştirmek.

Asimetri

Fan-in yükü yoğunlaştırır; fan-out riski çarpar. En etkili düğümlerde her ikisini de en aza indirgemeye çalışın.

En yüksek fan-in: veritabanı (yük yoğunluğu): Önbellekleme yaparak yükü azaltın. Okuyucu kopyalarını (read replicas) yüksek fan-in'i birden fazla düğüm arasında paylaşmak için kullanın.

En yüksek fan-out: düzenleyici hizmet: her bağımlılık için devre açıkları (circuit breakers), esnek gerileme, bulkheads.

A backend replica çağrısı, her biri bağımsız olarak 4 downstream hizmetten her biri %99,95 kullanılabilirlik ile. (1) Başarılı bir yanıt için tüm 4 çağrı gerekiyorsa, backend'in en üst düzey kullanılabilirliği nedir? (2) İki downstream'ın 4'ten 2'si %99,95 kullanılabilirlik ile opcional olarak yapılandırıldıysa, sınır ne olur?

Ekleme 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.

Bu mimariye yeni bir hizmet mevcuttur: clients -> CDN -> geri yansıtıcı (2 kopya) -> arka uç seviyesi (8 kopya) -> { ana veri tabanı, 3 düğüm cache kümesi, 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?

Komşu Notlar

Komşu Notlar

Bu geometri-ders, Proxies & Origins ana dersini yönlü-şema analizi olarak yeniden şekillendirir.

Bu kursun sonraki komşusu, geometry_of_stateless_horizontal_scaling, ana ölçeklendirme dersinden kopya-matematikleri alır ve kuyruk eğrisi, Little's Law ve 80% kullanılabilirlik eşiği geometrik olarak çıkarır.

İyi iş çıkardınız.