Dlaczego Tyle Żyje na Krawędzi

Warstwa Krawędziowa Zarabia na Łyku

Reverse proxy wykonuje trzy prace jednocześnie. Każda z nich usprawiedliwia warstwę; wykonywanie wszystkich trzech na tej samej adresie wyjaśnia, dlaczego niemal każda produkcyjna architektura weba ma tę samą formę na froncie.

Praca 1: Ukrywaj początek. Proxy odpowiada na publiczny IP. Tyle serwery tylne znajdują się na prywatnych IP, których internet nie może dotrzeć. Atakujący, który chce uderzyć w początek, musi najpierw zakłócić proxy.

Praca 2: Zakończ TLS. Proxy posiada certyfikat dla example.com i odkodowuje przychodzące żądania HTTPS. Serwery tylne komunikują się z proxy w prostym HTTP (lub prostszym TLS wewnętrznym) przez zaufane segmenty sieci. Polityka aktualizacji, odnawiania certyfikatów oraz szyfrowania znajduje się w jednym miejscu.

Praca 3: Rozdziel ładunek. Proxy wybiera, która z serwerów tylnych obsłuży każde żądanie. Serwery tylne za jednym proxy tworzą pulę; proxy wybiera jedną na żądanie, stosując strategię (w rondzie, najmniej połączeń, hasz na nagłówku). Dodanie zdolności oznacza dodanie serwera do puli, a nie mówienie każdemu klientowi nowego adresu.

Każda praca to mała programista. Wspólnie wyjaśniają, dlaczego warstwa tak prosta jak 'Caddy przed aplikacją Pythona' ma większy wpływ na projekt niż sama aplikacja Python.

Projektowanie dla Wszystkich Trzech

Twoja ekipa prowadzi mały API na pojedynczym procesie Pythona, który słucha na porcie 8000 na pojedynczej VM. Ruch wzrósł tak, że jedna VM nie może utrzymywać, a przegląd bezpieczeństwa wykazał, że VM ma publiczny IP i swoje certyfikaty TLS.

Zdecydowałeś, że wstawię reverse proxy przed. Narysujmy układ: gdzie wskazuje DNS, gdzie certyfikat żyje, jak ładunek dociera do tylnej bazy, a co się zmienia w oryginalnej VM?

Zamiana składnika bez, żeby ktokolwiek nie zauważył

Odpowiednik Swobodny

Stara adwokat-filozofia z zakresu nauki o komputerach mówi: każde zadanie można rozwiązać przez dodanie kolejnej warstwy odwołania (oprócz zadania z zbyt dużą liczbą warstw odwołania). Wirtualny serwer proxy to jedno z najbardziej użytecznych odwołań w systemach rozproszonych.

Co kupuje Cię:

- Zamienne tylne elementy. Przenieś aplikację z Python na Go? Przeniesiesz się z jednego centrum danych na inne? Wdropisz nową wersję z zerowym czasem przestoju? Każde z tych zdarzeń dzieje się za stabilną publiczną adresą. Nic się nie zmienia dla użytkowników.

- Odrębne skalowanie. Kolej proxy skaluje się na podstawie pasma i CPU na poziomie TLS. Tylne elementy skalują się na podstawie pracy aplikacji. Każde rozwija się na własnej osi, ponieważ żyją na różnych maszynach.

- Zamknięcie awarii. Złe wdrozenie na tylnej maszynie nie wyłączy publicznego adresu. Proxy nadal działa; wprowadzasz poprawkę lub cofasz zmiany; świat ponownie nawiązuje połączenie, gdy tylne urządzenie odzyskuje się.

- Zagadnienia przecinające w jednym miejscu. Ograniczanie szybkości, blokowanie przez region, rejestrowanie żądań, modyfikowanie nagłówków, kopiowanie, kompresja odpowiedzi: to wszystko występuje na proxy. Kody backendu pozostaje skupiony na aplikacji.

Bez proxy każde z tych problemów musi istnieć w procesie aplikacji. Z proxy istnieją na jednej warstwie, którą jeden zespół zarządza.

Koszt: kolejna warstwa do zarządzania. Doświadczający zespoły akceptują koszty, ponieważ warstwa proxy sama jest stanowa i skaluje się w poziomie; zastąpienie jednego proxy dwoma nie wymaga żadnej koordynacji.

Przełączanie się między niebieskim a zielonym za pośrednictwem proxy

Twoja ekipa realizuje wersję 1 API na trzech maszynach tylnej (błękitnej puli) za pomocą proxy wirtualnego serwera. Chcesz wdrożyć wersję 2 z możliwością szybkiego cofnięcia się, gdy coś się stanie, w mniej niż trzydzieści sekund.

Wyruszysz z trzema nowymi maszynami tylnej (zielona pulka) działającą wersję 2, obok puli niebieskiej, ale jeszcze nie kierujesz do nich żadnego ruchu.

Od Przeglądarki do Tylnej Siaty i Z powrotem

Przeprowadź Jedne Pytanie od początku do końca

Śledź pojedynczy HTTPS GET https://api.example.com/users/42 przez odwrotnej proxy przed pulą tylnej siatki.

Krok 1: Rozwiązywanie DNS. Przeglądarka zapytuje o rozwiązywanie DNS api.example.com. Rozwiązywanie DNS zwraca publiczny adres IP proxy (na przykład 203.0.113.10). Przeglądarka otwiera połączenie TCP z 203.0.113.10:443.

Krok 2: Rękojmia TLS. Proxy prezentuje swój certyfikat dla api.example.com. Przeglądarka weryfikuje certyfikat, dwa strony zgadzają się na klucz sesyjnej, & kanał szyfrowany otwiera się.

Krok 3: Zapytanie HTTP wewnętrznie TLS. Przeglądarka wysyła GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxy odszyfrowuje bajty żądania.

Krok 4: Wybór tylnej siatki. Proxy sprawdza swoją pulę tylnej siatki dla api.example.com i wybiera jeden backend (na przykład 10.0.0.21:8000) stosując swoją strategię równoważenia obciążenia.

Krok 5: Zapytanie w górę. Proxy otwiera (lub wykorzystuje ponownie) proste połączenie HTTP z 10.0.0.21:8000 i przekierowuje żądanie. Proxy może modyfikować nagłówki podczas przepływu: dodać X-Forwarded-For: <client-ip>, ustawić Host: poprawnie, usunąć nagłówki takie jak Connection.

Krok 6: Obliczenia tylnej siatki. Aplikacja tylnej siatki czyta żądanie, wyszukuje w bazie danych, buduje odpowiedź JSON.

Krok 7: Odpowiedź w górę. Tylne siaty wysyła odpowiedź z powrotem do proxy jako proste HTTP.

Krok 8: Ostateczna odpowiedź brzegowa. Proxy może modyfikować lub kompresować odpowiedź, szyfrować ją z powrotem przez sesję TLS i wysłać ją do przeglądarki.

Krok 9: Życie cyklu połączenia. Sesja TLS pozostaje zwykle otwarta dla następnego żądania (HTTP/2 multiplexuje wiele żądań na jednym połączeniu). Połączenie proxy-tylnej siatki często puluje dla ponownego wykorzystania.

Każda publiczna usługa internetowa realizuje pewną wariację tego kształtu. Znamienie kroków pozwala na rozumowanie o tym, gdzie opóźnienia gromadzą się, gdzie logowanie należy umieścić, & gdzie błąd może ukryć się.

Gdzie Minęło Czas?

Użyownik skarży się, że API wydaje się wolne. Zmierzysz i znajdziesz, że żądanie zajmuje 850 ms od początku do końca. Rejestrator serwera na stronie backendu pokazuje, że aplikacja obsłużyła żądanie w 40 ms. Rejestrator proxy pokazuje, że proxy wydało 50 ms na swoją stronę pracy (rękojma TLS + routingu + pisanie odpowiedzi).

Projektowanie Minimalnej Krawędzi dla Nowego Usługi

Synteza

Nauczysz się różnicę między forward a reverse proxy, trzy zadania, które reverse proxy wykonuje jednocześnie, dlaczego ukrywanie źródła przynosi zysk każdorazowo, gdy trzeba coś zmienić, oraz jak żądanie przepływa krok po kroku przez krawędź.

Teraz zastosuj to.

Mała grupa planuje wprowadzenie nowej usługi o nazwie notes.example.com. Użytkownicy będą czytać i wprowadzać swoje notatki. Drużyna będzie prowadzić dwa wirtualne maszyny backendowe podczas startu i spodziewa się wzrostu do dziesięciu w przyszłości roku. Chcą HTTPS dla użytkowników, stopniowe wprowadzenie nowych wersji oraz brak udostępniania publicznych adresów IP backendów.

Krok Następny Kursu

Krok Następny Kursu

Ten lekcja ustaliła kształt warstwy krawędziowej. Cztery kolejne lekcje w tym kursie rozwijają ją:

- Skalowanie Poziome Niezależne: dlaczego strefa proxy (& tyle backendów za nią) mnoży się tanio, & matematyka dla rozmiaru liczb replik w okresie wzrostu.

- Rozdział Przepływu / Wyjściowego: dlaczego pojedyncza skrzynka proxy obsługująca obie strony - wpływające & wyjściowe - kończy się w nieoczekiwany sposób, & jak podzielić warstwy.

- Tryby Awarii & Promień Eksplozji: jak pojedyncze zmiany konfiguracyjne przenikają się w awarię, & jak pisać bezwinne zadania działające na zapobieżenie powtarzającym się problemom.

- Narzędzia do Obserwacji & Pojemność: co i jak pomiarów na krańcu przepływu, aby dowiedzieć się, że coś jest złamane przed użytkownikami.

Każde lekcja samodzielnie. Wspólnie dają Ci mentalny model floty skalującej się w sieci.

Dodatkowa lekcja: geometry_of_proxies_and_origins przekształca wszystko z tej lekcji w kierunkowy graf & bada, co teoria grafów mówi o ścieżce żądania.

Brawo. Dalej.