Josh Evans opowiada o chaotycznym i kolorowym świecie mikroserwisów Netflixa, zaczynając od podstaw – anatomii mikroserwisów, wyzwań związanych z systemami rozproszonymi i korzyściami z nich płynącymi. Opierając się na tym fundamencie, bada praktyki kulturowe, architektoniczne i operacyjne, które prowadzą do mistrzostwa w mikrousługach.
W przeciwieństwie do dryfu operacyjnego, wprowadzenie nowych języków na potrzeby internacjonalizacji usług i nowych technologii, takich jak kontenery, to świadome decyzje mające na celu dodanie nowej złożoności do środowiska. Mój zespół operacyjny ujednolicił najlepszy plan rozwoju technologii dla Netflix, który został uwzględniony w predefiniowanych najlepszych praktykach opartych na Javie i EC2, ale wraz z rozwojem firmy programiści zaczęli dodawać nowe komponenty, takie jak Python, Ruby, Node-JS i Docker.
Jestem bardzo dumny, że jako pierwsi opowiadaliśmy się za tym, aby nasz produkt działał świetnie, nie czekając na reklamacje klientów. Wszystko zaczęło się dość prosto — mieliśmy programy operacyjne w Pythonie i kilka aplikacji back-office w Ruby, ale sytuacja stała się o wiele bardziej interesująca, gdy nasi programiści ogłosili, że porzucą JVM i przeniosą sieć aplikacja na platformę programową Node.js. Po wprowadzeniu Dockera sytuacja stała się znacznie bardziej złożona. Kierowaliśmy się logiką i technologie, które wymyśliliśmy, stały się rzeczywistością, gdy wdrożyliśmy je dla klientów, ponieważ miały duży sens. Powiem Ci dlaczego tak jest.
API Gateway faktycznie ma możliwość integracji świetnych skryptów, które mogą działać jako punkty końcowe dla programistów interfejsu użytkownika. Każdy z tych skryptów przekonwertowali w taki sposób, aby po wprowadzeniu zmian móc je wdrożyć na urządzeniach produkcyjnych, a następnie na urządzeniach użytkowników, a wszystkie te zmiany zostały zsynchronizowane z punktami końcowymi, które działały w bramie API.
To jednak powtórzyło problem stworzenia nowego monolitu, w którym usługa API została przeciążona kodem w taki sposób, że wystąpiły różne scenariusze awarii. Na przykład usunięto niektóre punkty końcowe lub skrypty losowo wygenerowały tak wiele wersji czegoś, że wersje te zajmowały całą dostępną pamięć usługi API.
Logiczne było pobranie tych punktów końcowych i wycofanie ich z usługi API. W tym celu stworzyliśmy komponenty Node.js, które działały jako małe aplikacje w kontenerach Docker. Pozwoliło nam to wyizolować wszelkie problemy i awarie spowodowane przez te aplikacje węzłowe.
Koszt tych zmian jest dość duży i składa się z następujących czynników:
- Narzędzia zwiększające produktywność. Zarządzanie nowymi technologiami wymagało nowych narzędzi, ponieważ zespół UI, wykorzystując bardzo dobre skrypty do stworzenia wydajnego modelu, nie musiał poświęcać dużo czasu na zarządzanie infrastrukturą, a jedynie musiał napisać skrypty i sprawdzić ich funkcjonalność.
Wgląd w możliwości i sortowanie — kluczowym przykładem są nowe narzędzia potrzebne do odkrywania informacji o czynnikach wpływających na wydajność. Trzeba było wiedzieć, ile procesora jest zajęte, jak wykorzystywana jest pamięć, a zbieranie tych informacji wymagało różnych narzędzi. - Fragmentacja obrazów podstawowych - prosty podstawowy AMI stał się bardziej fragmentaryczny i wyspecjalizowany.
- Zarządzanie węzłami. Nie ma dostępnej gotowej architektury ani technologii umożliwiającej zarządzanie węzłami w chmurze, dlatego zbudowaliśmy Titus, platformę do zarządzania kontenerami, która zapewnia skalowalne i niezawodne wdrażanie kontenerów oraz integrację chmury z Amazon AWS.
- Powielanie biblioteki lub platformy. Zapewnienie nowym technologiom tej samej podstawowej funkcjonalności platformy wymagało powielenia jej do opartych na chmurze narzędzi programistycznych Node.js.
- Krzywa uczenia się i doświadczenie przemysłowe. Wprowadzenie nowych technologii nieuchronnie stwarza nowe wyzwania, którym należy sprostać i z których należy się uczyć.
Dlatego nie mogliśmy ograniczyć się do jednej „utwardzonej drogi” i musieliśmy stale budować nowe sposoby doskonalenia naszych technologii. Aby obniżyć koszty, ograniczyliśmy scentralizowane wsparcie i skupiliśmy się na JVM, nowych węzłach i Dockerze. Nadaliśmy priorytet skutecznemu wpływowi, informowaliśmy zespoły o kosztach ich decyzji i zachęcaliśmy je do szukania sposobów ponownego wykorzystania opracowanych już rozwiązań o dużym wpływie. Takie podejście zastosowaliśmy przy tłumaczeniu usługi na języki obce, aby dostarczyć produkt klientom międzynarodowym. Przykładami są stosunkowo proste biblioteki klienckie, które można wygenerować automatycznie, dzięki czemu dość łatwo jest utworzyć wersję w języku Python, wersję Ruby, wersję Java itp.
Stale szukaliśmy możliwości wykorzystania sprawdzonych technologii, które sprawdziły się w jednym miejscu i innych podobnych sytuacjach.
Porozmawiajmy o ostatnim elemencie - zmianach, czyli wariacjach. Zobacz jak spożycie naszego produktu zmienia się nierównomiernie w zależności od dnia tygodnia i godziny w ciągu dnia. Można powiedzieć, że 9:XNUMX to najcięższy czas dla Netfliksa, kiedy obciążenie systemu osiąga maksimum.
Jak osiągnąć dużą szybkość wdrażania innowacji oprogramowania, czyli ciągłego wprowadzania nowych zmian w systemie, nie powodując przerw w świadczeniu usług i nie powodując niedogodności dla naszych klientów? Netflix osiągnął to dzięki wykorzystaniu Spinnaker, nowej globalnej platformy do zarządzania i ciągłego dostarczania (CD) opartej na chmurze.
Co najważniejsze, Spinnaker został zaprojektowany tak, aby zintegrować nasze najlepsze praktyki, dzięki czemu wdrażając komponenty do produkcji, możemy zintegrować wyniki bezpośrednio z naszą technologią dostarczania multimediów.
Udało nam się włączyć do naszego rurociągu dostaw dwie technologie, które bardzo cenimy: zautomatyzowaną analizę Canary i wdrażanie etapowe. Analiza Canary oznacza, że kierujemy niewielką część ruchu do nowej wersji kodu, a resztę ruchu produkcyjnego przepuszczamy przez starą wersję. Następnie sprawdzamy, jak nowy kod radzi sobie z zadaniem – lepiej lub gorzej od dotychczasowego.
Wdrażanie rozłożone w czasie oznacza, że jeśli przy wdrożeniu w jednym regionie występują problemy, przechodzimy do wdrożenia w innym regionie. W takim przypadku powyższa lista kontrolna musi zostać uwzględniona w rurociągu produkcyjnym. Zaoszczędzę Ci trochę czasu i polecam zapoznanie się z moim poprzednim wystąpieniem, Inżynieria globalnych operacji Netflix w chmurze, jeśli chcesz głębiej zgłębić ten temat. Nagranie wideo przemówienia można obejrzeć, klikając link na dole slajdu.
Na koniec wykładu krótko opowiem o organizacji i architekturze Netflixa. Na samym początku mieliśmy schemat o nazwie Electronic Delivery, który był pierwszą wersją strumieniowego przesyłania multimediów NRDP 1.x. Można tu zastosować termin „backstream”, ponieważ początkowo użytkownik mógł jedynie pobierać treści w celu późniejszego odtworzenia na urządzeniu. Pierwsza platforma cyfrowa Netflix z 2009 roku wyglądała mniej więcej tak.
Na urządzeniu użytkownika znajdowała się aplikacja Netflix, na którą składał się interfejs UI, moduły bezpieczeństwa, aktywacja usługi i odtwarzanie, oparta na platformie NRDP – Netflix Ready Device Platform.
W tamtym czasie interfejs użytkownika był bardzo prosty. Zawierał tak zwany czytnik Queque, a użytkownik odwiedzał witrynę, aby dodać coś do Queque, a następnie przeglądał dodaną zawartość na swoim urządzeniu. Pozytywne było to, że zespół front-end i zespół back-end należały do tej samej organizacji Electronic Delivery i miały ze sobą bliską współpracę. Ładunek został stworzony w oparciu o XML. W tym samym czasie powstało API Netflix dla biznesu DVD, które zachęciło aplikacje firm trzecich do kierowania ruchu do naszego serwisu.
Jednak API Netflix zostało dobrze przygotowane, aby pomóc nam w innowacyjnym interfejsie użytkownika, zawierającym metadane wszystkich treści, informacje o tym, jakie filmy były dostępne, co stworzyło możliwość generowania list do obejrzenia. Posiadał ogólny interfejs API REST oparty na schemacie JSON, kod odpowiedzi HTTP, ten sam, który jest używany w nowoczesnej architekturze, oraz model bezpieczeństwa OAuth, który był wówczas wymagany w przypadku aplikacji front-end. Umożliwiło to przejście z publicznego modelu dostarczania treści strumieniowych na prywatny.
Problemem z przejściem była fragmentacja, gdyż teraz nasz system obsługiwał dwie usługi oparte na zupełnie innych zasadach działania – jedną na Rest, JSON i OAuth, drugą na RPC, XML i mechanizmie bezpieczeństwa użytkownika opartym na systemie tokenów NTBA. Była to pierwsza architektura hybrydowa.
Zasadniczo istniała zapora ogniowa pomiędzy naszymi dwoma zespołami, ponieważ początkowo interfejs API nie skalował się zbyt dobrze z NCCP, co doprowadziło do tarć między zespołami. Różnice dotyczyły usług, protokołów, obwodów, modułów bezpieczeństwa, a programiści często musieli przełączać się między zupełnie różnymi kontekstami.
W związku z tym rozmawiałem z jednym ze starszych inżynierów firmy, któremu zadałem pytanie: „Jaka powinna być właściwa architektura długoterminowa?”, a on zadał pytanie przeciwne: „Prawdopodobnie bardziej martwisz się o konsekwencjach organizacyjnych – co się stanie, jeśli zintegrujemy te rzeczy, a one zniweczą to, czego nauczyliśmy się robić dobrze? To podejście jest bardzo powiązane z prawem Conwaya: „Organizacje projektujące systemy są ograniczone przez projekt, który replikuje strukturę komunikacyjną tej organizacji”. Jest to bardzo abstrakcyjna definicja, dlatego wolę bardziej szczegółową: „Każdy fragment oprogramowania odzwierciedla strukturę organizacyjną, która go stworzyła”. Oto mój ulubiony cytat Erica Raymonda: „Jeśli cztery zespoły programistów pracują nad kompilatorem, otrzymasz kompilator czteroprzebiegowy”. Cóż, Netflix ma czteroprzebiegowy kompilator i tak właśnie pracujemy.
Można powiedzieć, że w tym przypadku ogon macha psem. Naszym najważniejszym priorytetem nie jest rozwiązanie, ale organizacja; to organizacja napędza architekturę, którą mamy. Stopniowo z mieszaniny usług przeszliśmy do architektury, którą nazwaliśmy Blade Runner, ponieważ mówimy tutaj o usługach brzegowych i możliwości oddzielenia NCCP i integracji bezpośrednio z proxy Zuul, bramą API i odpowiednią funkcjonalnością „Elementy” zostały przekształcone w nowe mikrousługi z bardziej zaawansowanymi funkcjami bezpieczeństwa, odtwarzania, sortowania danych itp.
Można zatem powiedzieć, że struktury działowe i dynamika firmy odgrywają ważną rolę w kształtowaniu projektowania systemów i są czynnikiem sprzyjającym lub utrudniającym zmiany. Architektura mikrousług jest złożona i organiczna, a jej zdrowie opiera się na dyscyplinie i wprowadzonym chaosie.
Niektóre reklamy
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com