Cześć wszystkim! Mamy świetne wieści, w czerwcu OTUS ponownie uruchamia kurs , z tej okazji tradycyjnie dzielimy się z wami przydatnym materiałem.
Jeśli natknąłeś się na całą tę historię o mikroserwisach bez żadnego kontekstu, można zrozumieć, że wydaje się ona nieco dziwna. Podział aplikacji na fragmenty, połączone ze sobą siecią, z pewnością oznacza dodanie skomplikowanych trybów odporności na awarie do powstałego rozproszonego systemu.
Mimo że takie podejście polega na podziale na wiele niezależnych serwisów, ostateczny cel jest znacznie większy niż tylko działanie tych serwisów na różnych maszynach. Chodzi tutaj o interakcję z otaczającym światem, który z natury również jest rozproszony. Nie w sensie technicznym, a raczej w sensie ekosystemu, który składa się z wielu ludzi, zespołów, programów, gdzie każda z tych części w taki czy inny sposób musi wykonywać swoją pracę.
Firmy na przykład są zbiorem rozproszonych systemów, które wspólnie przyczyniają się do osiągnięcia jakiegoś celu. Ignorowaliśmy ten fakt przez dekady, próbując osiągnąć integrację, przesyłając pliki przez FTP lub korzystając z narzędzi integracji korporacyjnej, koncentrując się przy tym na swoich osobistych, odosobnionych celach. Jednak z nadejściem serwisów wszystko się zmieniło. Serwisy pomogły nam spojrzeć za horyzont i zobaczyć świat wzajemnie zależnych programów, które współpracują. Jednak aby działać z sukcesem, trzeba zrozumieć i zaprojektować dwa zasadniczo różne światy: świat zewnętrzny, w którym żyjemy w ekosystemie wielu innych serwisów, oraz nasz osobisty, wewnętrzny świat, w którym rządzimy sami.
Taki rozproszony świat różni się od tego, w którym dorastaliśmy i do którego przywykliśmy. Zasady budowy tradycyjnej architektury monolitycznej nie znoszą krytyki. Dlatego prawidłowe zrozumienie takich systemów to coś więcej niż stworzenie fajnego schematu na białej tablicy lub świetnego dowodu koncepcji. Chodzi o to, aby taki system skutecznie funkcjonował przez długi czas. Na szczęście serwisy istnieją już od dawna, chociaż wyglądają różnie. są nadal aktualne, nawet jeśli przyprawione Dockerem, Kubernetesem i nieco zniszczone hipsterskimi brodami.
Dziś przyjrzymy się, jak zmieniły się zasady, dlaczego musimy przeanalizować nasze podejście do usług i danych, które między sobą przesyłają, oraz dlaczego będziemy potrzebować zupełnie innego zestawu narzędzi.
Enkapsulacja nie zawsze będzie dla Ciebie przyjacielem.
Mikroserwisy mogą działać niezależnie od siebie. To właśnie ta cecha nadaje im największą wartość. Ta sama cecha pozwala usługom na skalowanie i rozwój. Nie tyle w sensie skalowania do kwadrylionów użytkowników czy petabajtów danych (chociaż w tym również mogą pomóc), ale w sensie skalowania pod względem ludzi, ponieważ zespoły i organizacje ciągle rosną.
Jednak niezależność to miecz obosieczny. Usługa sama w sobie może działać płynnie i beztrosko. Ale jeśli w obrębie usługi realizowana jest funkcja, która wymaga zaangażowania innej usługi, to w końcu musimy wprowadzić zmiany w obu usługach niemal równocześnie. W monolicie jest to łatwe — po prostu wprowadzasz zmianę i wysyłasz ją do wersji, ale w przypadku synchronizacji niezależnych usług, problemów będzie znacznie więcej. Koordynacja pomiędzy zespołami i cyklami wydania narusza elastyczność.
W ramach standardowego podejścia niechciane zmiany między usługami są po prostu starannie unikane, jasno oddzielając funkcjonalność między usługami. Usługa jednego punktu wejścia do systemu może być dobrym przykładem. Ma ona jasno określoną rolę, która odróżnia ją od innych usług. Takie wyraźne oddzielenie oznacza, że w świecie szybko zmieniających się wymagań wobec otaczających ją usług, usługa jednego punktu wejścia do systemu prawdopodobnie nie będzie ulegać zmianom. Istnieje w ściśle ograniczonym kontekście.
Problem polega na tym, że w rzeczywistym świecie usługi biznesowe nie mogą stale utrzymywać czystego podziału ról. Na przykład, te same usługi biznesowe w większym stopniu operują na danych pochodzących od innych podobnych usług. Jeśli zajmujesz się handlem internetowym, przetwarzanie strumienia zamówień, katalogu produktów czy informacji o użytkownikach będzie wymagać od wielu Twoich usług dostępu do tych danych.
Większość usług biznesowych korzysta z tego samego strumienia danych, dlatego ich praca niezmiennie się przeplata.
W ten sposób dotarliśmy do ważnego momentu, o którym warto porozmawiać. Podczas gdy usługi dobrze działają w przypadku komponentów infrastruktury, które funkcjonują w znacznym stopniu oddzielnie, większość usług biznesowych okazuje się być ze sobą znacznie ściślej powiązana.
Dychotomia danych
Podejścia oparte na usługach mogą już istnieć, jednak wciąż brakuje informacji na temat wymiany dużych ilości danych między usługami.
Główny problem polega na tym, że dane i usługi są nierozłączne. Z jednej strony, enkapsulacja wzywa nas do ukrywania danych, aby usługi można było oddzielić od siebie i ułatwić ich rozwój oraz dalsze zmiany. Z drugiej strony, musimy mieć możliwość swobodnego dzielenia się i zarządzania wspólnymi danymi, jak i innymi. Chodzi o to, aby mieć możliwość natychmiastowego rozpoczęcia pracy, tak swobodnie, jak w każdym innym systemie informacyjnym.
Jednak systemy informacyjne mają mało wspólnego z enkapsulacją. W rzeczywistości jest wręcz przeciwnie. Bazy danych robią wszystko, co w ich mocy, aby zapewnić dostęp do przechowywanych w nich danych. Oferują potężny deklaratywny interfejs, który pozwala na modyfikację danych według Twoich potrzeb. Taka funkcjonalność jest ważna na etapie wstępnych badań, ale nie w zarządzaniu rosnącą złożonością stale rozwijających się usług.
I tu pojawia się dylemat. Sprzeczność. Dychotomia. Bowiem systemy informacyjne to kwestia udostępniania danych, a usługi to kwestia ich ukrywania.
Te dwie siły są fundamentalne. Leżą u podstaw większości naszej pracy, nieustannie rywalizując o dominację w systemach, które tworzymy.
W miarę jak systemy usługowe rosną i ewoluują, dostrzegamy różne manifestacje konsekwencji dylematu danych. Albo interfejs usługi będzie się rozwijał, oferując coraz szerszy zestaw funkcji i zacznie wyglądać jak dziwaczna, domowej roboty baza danych, albo napotkamy rozczarowanie i wdrożymy sposób na masowe wydobywanie lub przenoszenie kompletnych zestawów danych z usługi do usługi.
Stworzenie czegoś, co wygląda jak dziwaczna, domowej roboty baza danych, prowadzi do szeregu problemów. Nie zagłębiając się w szczegóły, czym powinna być shared database, po prostu powiedzmy, że wiąże się to z znacznymi kosztownymi wyzwaniami inżynieryjnymi i operacyjnymi dla firmy próbującej ją wykorzystać.
Gorsze jest to, że ilość danych zaostrza problemy z granicami usług. Im więcej wspólnych danych znajduje się wewnątrz usługi, tym trudniejszy staje się interfejs i tym trudniej łączyć zestawy danych pochodzące z różnych usług.
Alternatywne podejście do wydobywania i przenoszenia całych zestawów danych także ma swoje problemy. Powszechny sposób podejścia do tej kwestii polega na prostym wydobyciu i przechowywaniu całego zestawu danych, a następnie przechowywaniu go lokalnie w każdej usłudze konsumującej.
Problem polega na tym, że różne usługi różnie interpretują dane, które konsumują. Te dane są zawsze pod ręką. Modyfikowane i przetwarzane lokalnie, szybko przestają mieć cokolwiek wspólnego z danymi w źródle.
Im bardziej mutowalne są kopie, tym bardziej dane będą się różnić z upływem czasu.
Co gorsza, takie dane trudno poprawić wstecz ( tutaj naprawdę może się przydać). W rzeczywistości niektóre z trudnych do rozwiązania problemów technologicznych, z którymi boryka się biznes, wynikają z zróżnicowanych danych mnożących się od aplikacji do aplikacji.
Aby znaleźć rozwiązanie tego problemu z wspólnymi danymi, trzeba myśleć inaczej. Powinny stać się pierwszorzędnymi obiektami w architekturach, które budujemy. nazywa te dane „zewnętrznymi”, a jest to bardzo ważna cecha. Potrzebujemy inkapsulacji, aby nie ujawniać wewnętrznej struktury usługi, ale musimy ułatwić usługom dostęp do danych współdzielonych, aby mogły prawidłowo wykonywać swoją pracę.
Problem polega na tym, że żaden z obecnych podejść nie jest już aktualny, ponieważ ani interfejsy usług, ani wymiana wiadomości, ani baza danych współdzielonych nie oferują dobrego rozwiązania do pracy z danymi zewnętrznymi. Interfejsy usług słabo nadają się do wymiany danych w jakiejkolwiek skali. Wymiana wiadomości przenosi dane, ale nie przechowuje ich historii, co prowadzi do uszkodzenia danych w miarę upływu czasu. Bazy danych współdzielonych są zbyt mocno skoncentrowane w jednym punkcie, co ogranicza rozwój postępu. Nieuchronnie utknęliśmy w cyklu niewłaściwych danych.
Cykl niewłaściwych danych
Potoki: zdecentralizowane podejście do danych i usług
W idealnym przypadku musimy zmienić podejście do tego, jak usługi pracują z danymi wspólnymi. W tej chwili każde podejście napotyka wspomnianą wcześniej dychotomię, ponieważ nie ma żadnego magicznego proszku, którym można by obficie posypać i sprawić, by zniknęła. Jednak możemy przemyśleć problem i dojść do kompromisu.
Ten kompromis zakłada pewien stopień centralizacji. Możemy skorzystać z mechanizmu rozproszonych logów, ponieważ zapewnia on niezawodne, skalowalne potoki. Teraz potrzebujemy, aby usługi mogły dołączać i wykorzystywać te wspólne potoki, jednak chcemy uniknąć skomplikowanych centralnych usług typu God Service, które wykonują takie przetwarzanie. Dlatego najlepszym rozwiązaniem jest wbudowanie przetwarzania strumieniowego w każdą usługę-konsumenta. W ten sposób usługi będą mogły łączyć zbiory danych z różnych źródeł i pracować z nimi tak, jak potrzebują.
Jednym ze sposobów osiągnięcia takiego podejścia jest użycie platformy strumieniowej. Istnieje wiele opcji, ale dzisiaj przyjrzymy się szczególnie Kafka, ponieważ wykorzystanie jej Stateful Stream Processing umożliwia skuteczne rozwiązanie przedstawionego problemu.
Wykorzystanie mechanizmu rozproszonego logowania pozwala nam podążać utartą ścieżką i używać wymiany wiadomości, aby pracować z . Uważa się, że takie podejście zapewnia lepszą skalowalność i podział niż mechanizm „żądanie-odpowiedź”, ponieważ kontrolę nad przepływem oddaje odbiorcy, a nie nadawcy. Jednak za wszystko w życiu trzeba płacić, a w tym przypadku potrzebny będzie broker. Ale dla dużych systemów ten kompromis jest tego wart (czego nie można powiedzieć o przeciętnych aplikacjach internetowych).
Jeśli za rozproszone logowanie odpowiada broker, a nie tradycyjny system wymiany wiadomości, można skorzystać z dodatkowych funkcji. Transport można liniowo skalować prawie tak dobrze, jak rozproszony system plików. Dane mogą być przechowywane w logach wystarczająco długo, dzięki czemu otrzymujemy nie tylko wymianę wiadomości, ale i magazyn danych. Skalowalny magazyn bez obaw o uzyskanie zmiennego wspólnego stanu.
Następnie można użyć mechanizmu stateful stream processing (przetwarzanie strumieniowe ze stanem) do dodawania deklaratywnych narzędzi baz danych do usług odbiorców. To bardzo ważna myśl. Dopóki dane są przechowywane w wspólnych strumieniach, do których mogą mieć dostęp wszystkie usługi, integracja i przetwarzanie, które wykonuje usługa, są prywatne. Są izolowane wewnątrz ściśle określonego kontekstu.
Pozbądź się dychotomii danych, dzieląc niezmienny strumień stanów. Następnie dodaj tę funkcję do każdej usługi za pomocą Stateful Stream Processing.
W ten sposób, jeśli twoja usługa musi obsługiwać zamówienia, katalog produktów, magazyn, będzie miała pełny dostęp: tylko ty zdecydujesz, które dane łączyć, gdzie je przetwarzać i jak powinny się zmieniać w czasie. Mimo że dane są wspólne, ich przetwarzanie jest całkowicie zdecentralizowane. Odbywa się wewnątrz każdej usługi, w świecie, w którym wszystko odbywa się według twoich zasad.
Dziel się danymi w sposób, który nie narusza ich integralności. Inkapсуłuj funkcję, a nie źródło, w każdej usłudze, która jej potrzebuje.
Czasami zachodzi potrzeba masowego przenoszenia danych. Czasami usługa wymaga lokalnego zestawu historycznych danych w wybranym silniku bazy danych. Kluczowe jest to, że można zagwarantować, iż w razie potrzeby kopia może być przywrócona z źródła za pomocą dostępu do mechanizmu rozproszonego logowania. Konektory w Kafka doskonale radzą sobie z tym zadaniem.
Zatem omawiana dzisiaj metoda ma kilka zalet:
- Dane są wykorzystywane w postaci ogólnych strumieni, które mogą być długo przechowywane w logach, a sam mechanizm pracy z danymi ogólnymi jest zaszyty w każdym kontekście, co pozwala usługom pracować łatwo i szybko. W ten sposób można zrównoważyć dwoistość danych.
- Dane pochodzące z różnych usług mogą być łatwo łączone w zestawy. Uproszczone w ten sposób oddziaływanie z danymi ogólnymi eliminuje konieczność utrzymywania lokalnych zestawów danych w bazie danych.
- Stateful Stream Processing jedynie buforuje dane, a źródłem prawdy pozostają ogólne logi, dlatego problem uszkodzenia danych z czasem nie jest tak palący.
- Z natury rzeczy, usługi są zarządzane danymi, co oznacza, że pomimo ciągłego wzrostu wolumenów danych, usługi mogą szybko reagować na wydarzenia biznesowe.
- Problemy ze skalowalnością spoczywają na brokerze, a nie na usługach. W ten sposób znacznie zmniejsza się złożoność pisania usług, ponieważ nie ma potrzeby myślenia o skalowalności.
- Dodawanie nowych usług nie wymaga zmian w starych, dlatego podłączenie nowych usług staje się łatwiejsze.
Jak widać, to więcej niż tylko REST. Otrzymaliśmy zestaw narzędzi, który umożliwia pracę z danymi ogólnymi w sposób zdecentralizowany.
W dzisiejszym artykule nie omówiliśmy wszystkich aspektów. Nadal musimy zdecydować, jak zrównoważyć paradygmat "żądanie-odpowiedź" z paradygmatem opartym na zdarzeniach. Ale tym zajmiemy się następnym razem. Są tematy, które warto lepiej poznać, na przykład, dlaczego Stateful Stream Processing jest tak dobry. O tym porozmawiamy w trzecim artykule. Istnieją również inne potężne konstrukcje, z których możemy skorzystać, jeśli zdecydujemy się na nie, na przykład, . Dzięki niej zmieniają się zasady gry dla rozproszonych systemów biznesowych, ponieważ ta konstrukcja zapewnia gwarancje transakcyjne dla w skalowalnej formie. O tym będzie mowa w czwartym artykule. A na koniec musimy przejrzeć szczegóły realizacji tych zasad.
Ale na razie zapamiętajcie następujące: dychotomia danych to ta siła, z którą się stykamy przy tworzeniu usług biznesowych. Musimy o tym pamiętać. Kluczem jest przewrócenie wszystkiego do góry nogami i zaczęcie traktowania wspólnych danych jako obiektów pierwszej klasy. Stateful Stream Processing zapewnia w tym zakresie unikalny kompromis. Unika scentralizowanych „God Components”, które hamują postęp. Co więcej, zapewnia sprawność, skalowalność i odporność na awarie pipeline'ów strumieniowych danych, dodając je do każdej usługi. Dzięki temu możemy skupić się na ogólnym strumieniu świadomości, do którego może podłączyć się każda usługa i pracować z danymi. Tak usługi stają się bardziej skalowalne, wymienne i autonomiczne. Dlatego będą nie tylko dobrze wyglądać na tablicach i podczas weryfikacji hipotez, ale także będą działać i rozwijać się przez dziesięciolecia.
Źródło: habr.com
