Gdzie Koncentruje się Ruch

Fan-In = Koncentracja

Stopień wejściowy węzła = liczba krawędzi wskazujących na niego. W grafie żądania, stopień wejściowy = liczba źródeł wysyłających żądania.

Model fan-in: wiele klientów -> jedna CDN; wiele krawędzi CDN -> kilka proxy początkowych; wiele proxy -> mniej backendów replików; wiele back-endów -> pojedyncza baza danych.

**Zapotrzebowanie jest istotne, ponieważ najwyższy węzeł stopień wejściowy widzi najwięcej łącznej ładunku. Baza danych na końcu łańcucha może zobaczyć zapytania od każdego aktywnego żądania w całym systemie, nawet jeśli żaden pojedynczy użytkownik nie generuje wiele.

Fan-Out = Zależność

Stopień wyjściowy węzła = liczba krawędzi wychodzących z niego. Wysoki stopień wyjściowy oznacza wiele zależności w dół strumieniu.

Backend, który wywołuje bazę danych, dwa magazyny, trzy zewnętrzne API oraz kolejkę, ma stopień wyjściowy 7. Jego prawdopodobieństwo powodzenia jest mniej więcej iloczynem każdego związku powodzenia (jeśli wszystkie są wymagane dla powodzenia).

0,999 ^ 7 ≈ 0,993: backend o 7 związanych usługach, każda z 99,9% niezawodności, może osiągnąć tylko około 99,3% niezawodności własnych, nawet w przypadku braku własnych błędów.

Zmniejszenie stopnia wyjściowego przez: cacheowanie wyników w dół strumieniu, robienie niektórych związków opcjonalnych (łagodna degradacja), równoległe wykonywanie tego, co można równolegle.

Asymetria

Fan-in koncentruje ładunek; fan-out mnoży ryzyko. Dobrze kształtowany graf minimalizuje oba na najważniejszych węzłach.

Baza danych (najwyższy fan-in): cachować agresywnie, aby zmniejszyć ładunek. Kopie odczytu do zredukowania fan-in na kilka węzłów.

Orchestrator usługi (najwyższy stopień wyjściowy): zamek wyjściowy dla każdej zależności, łagodna degradacja, bąbelki.

Wstawiony węzeł kupuje elastyczność

Indirection = Dodanie Węzła Pośredniego

Bez proxy'ia, graf wygląda: client -> backend. Klient musi wiedzieć o adresie backend'u. Przeniesienie backend'u wymaga aktualizacji klienta (przez DNS lub konfigurację). To jestściżyna związanie.

Z proxy'iem, graf staje się: client -> proxy -> backend. Klient wie tylko o proxy'u. Przeniesienie backend'u wymaga aktualizacji konfiguracji proxy'ia w górę, a nie klienta.

Operacja grafu: wprowadź węzeł pośredni długą istniejącą krawędź. Nowa krawędź client -> proxy jest stabilna; nowa krawędź proxy -> backend jest teraz w zespół do zarządzania.

Czytanie geometryczne: indirektywa dodaje warstwę, która oddala zmianę w górę od zmiany w dół. Każda warstwa może się niezależnie od siebie przekształcać.

Koszty Indirekcyjności

Każda warstwa dodaje:

- Jedną przeszkodę opóźnienia (krawędź od klienta do proxy)

- Jedno miejsce, gdzie może się zdarzyć błąd konfiguracji (proxy się)

- Jedną więcej krawędź, która może się zepsuć

Zalety (rewiring, skalowanie, ochrona, zakończenie TLS, rozdział obciążenia) zwykle przeważają koszty dla jakiegokolwiek niezbyt banalnego systemu. Ale jest limit: każda warstwa indirektywności dodaje kolejną przeszkodę i kolejnego kandydata na SPOF.

Prawdziwa reguła: każde zadanie można rozwiązać przez dodanie warstwy indirektywności (z wyjątkiem problemu zbyt wielu warstw indirektywności).

Przeczytaj Architekturę jako Graf

Synteza

Teraz możesz czytać architekturę systemu jako graf: liczyć przeszkody, identyfikować węzły przecięcia, mierzyć koncentrację fan-inu, obliczać pułap dostępności z fan-out, a także ocenić korzyści i koszty indirektywności.

Zastosuj wszystko cztery.

Nowa usługa ma tę architekturę: klienci -> CDN -> odwrotne proxy (2 replik) -> poziom tylnej serwera (8 replik) -> { podstawowa baza danych, klastra cache (3 węzłów), zewnętrzny API }.

Notatki towarzyszące

Notatki towarzyszące

Ta geometria-lekcja przekształca główną lekcję Proxies & Origins w analizę wykresu kierunkowego.

Następna towarzyszka w tym kursie, geometry_of_stateless_horizontal_scaling, wykorzystuje matematykę replik z głównej lekcji skalowania, aby wyodrębnić krzywą kolejki, prawo Little'a i kąt geometryczny o 80% wykorzystania.

Świetnie zrobione.