Cześć wszystkim! Mamy świetną wiadomość, OTUS ponownie uruchamia kurs w czerwcu , w związku z czym tradycyjnie udostępniamy Państwu przydatne materiały.
Jeśli natknąłeś się na tę całą sprawę z mikrousługami bez żadnego kontekstu, wybaczono by ci, że pomyślałeś, że to trochę dziwne. Podział aplikacji na fragmenty połączone siecią koniecznie oznacza dodanie złożonych trybów odporności na awarie do powstałego systemu rozproszonego.
Chociaż to podejście wymaga podziału na wiele niezależnych usług, ostatecznym celem jest znacznie więcej niż tylko uruchomienie tych usług na różnych komputerach. Mówimy tu o interakcji ze światem zewnętrznym, który także jest w swojej istocie rozproszony. Nie w sensie technicznym, ale raczej w sensie ekosystemu, który składa się z wielu ludzi, zespołów, programów, a każda z tych części w jakiś sposób musi spełniać swoje zadanie.
Na przykład firmy to zbiór rozproszonych systemów, które wspólnie przyczyniają się do osiągnięcia jakiegoś celu. Ignorowaliśmy ten fakt przez dziesięciolecia, próbując osiągnąć ujednolicenie poprzez przesyłanie plików FTP lub korzystanie z narzędzi integracji korporacyjnej, skupiając się jednocześnie na własnych, izolowanych celach. Ale wraz z pojawieniem się usług wszystko się zmieniło. Usługi pomogły nam spojrzeć poza horyzont i zobaczyć świat współzależnych programów, które współpracują. Aby jednak działać skutecznie, konieczne jest rozpoznanie i zaprojektowanie dwóch zasadniczo różnych światów: świata zewnętrznego, w którym żyjemy w ekosystemie wielu innych usług, oraz naszego osobistego, wewnętrznego świata, w którym rządzimy sami.
Ten rozproszony świat różni się od tego, w którym dorastaliśmy i do którego jesteśmy przyzwyczajeni. Zasady wznoszenia tradycyjnej architektury monolitycznej nie wytrzymują krytyki. Zatem odpowiednie przygotowanie tych systemów to coś więcej niż tylko stworzenie fajnego diagramu na tablicy lub fajnego dowodu słuszności koncepcji. Chodzi o to, aby taki system działał skutecznie przez długi okres czasu. Na szczęście usługi istnieją już od dłuższego czasu, choć wyglądają inaczej. są nadal aktualne, nawet doprawione Dockerem, Kubernetesem i nieco wytartymi hipsterskimi brodami.
Zatem dzisiaj przyjrzymy się, jak zmieniły się zasady, dlaczego musimy ponownie przemyśleć sposób, w jaki podchodzimy do usług i danych, jakie sobie przekazują, oraz dlaczego będziemy potrzebować do tego zupełnie innych narzędzi.
Hermetyzacja nie zawsze będzie Twoim przyjacielem
Mikrousługi mogą działać niezależnie od siebie. To właśnie ta właściwość nadaje im największą wartość. Ta sama właściwość umożliwia skalowanie i rozwój usług. Nie tyle w sensie skalowania do biliardów użytkowników czy petabajtów danych (chociaż i w tym mogą pomóc), ale w sensie skalowania pod kątem liczby ludzi w miarę ciągłego rozwoju zespołów i organizacji.
Niepodległość to jednak miecz obosieczny. Oznacza to, że sama usługa może działać łatwo i naturalnie. Jeśli jednak w ramach usługi zostanie zaimplementowana funkcja wymagająca użycia innej usługi, wówczas będziemy musieli wprowadzić zmiany w obu usługach niemal jednocześnie. W monolicie jest to łatwe, wystarczy dokonać zmiany i wysłać ją do wydania, ale w przypadku synchronizacji niezależnych usług będzie więcej problemów. Koordynacja między zespołami i cyklami wydawniczymi niszczy elastyczność.
W ramach standardowego podejścia starają się po prostu unikać irytujących zmian typu end-to-end, wyraźnie dzieląc funkcjonalność pomiędzy usługami. Dobrym przykładem może być tutaj usługa pojedynczego logowania. Ma jasno określoną rolę, która odróżnia ją od innych usług. To wyraźne oddzielenie oznacza, że w świecie szybko zmieniających się wymagań dotyczących otaczających go usług jest mało prawdopodobne, aby usługa pojedynczego logowania uległa zmianie. Istnieje w ściśle ograniczonym kontekście.
Problem w tym, że w realnym świecie usługi biznesowe nie mogą przez cały czas utrzymywać tego samego, czystego podziału ról. Na przykład te same usługi biznesowe w większym stopniu współpracują z danymi pochodzącymi z innych podobnych usług. Jeśli zajmujesz się sprzedażą detaliczną online, przetwarzanie przepływu zamówień, katalogu produktów lub informacji o użytkowniku stanie się wymogiem w przypadku wielu Twoich usług. Każda z usług będzie potrzebować dostępu do tych danych, aby działać.
Większość usług biznesowych korzysta z tego samego strumienia danych, więc ich praca jest niezmiennie ze sobą powiązana.
W ten sposób dochodzimy do ważnego punktu, o którym warto porozmawiać. Chociaż usługi sprawdzają się dobrze w przypadku elementów infrastruktury, które działają w dużej mierze oddzielnie, większość usług biznesowych jest ze sobą znacznie ściślej powiązana.
Dychotomia danych
Podejścia zorientowane na usługi mogą już istnieć, ale nadal brakuje im wiedzy na temat sposobu udostępniania dużych ilości danych między usługami.
Głównym problemem jest to, że dane i usługi są nierozłączne. Z jednej strony enkapsulacja zachęca do ukrywania danych, aby móc oddzielić usługi od siebie i ułatwić ich rozwój i dalsze zmiany. Z drugiej strony musimy umieć swobodnie dzielić i podbijać wspólne dane, tak jak każde inne dane. Chodzi o to, aby móc od razu przystąpić do pracy, tak swobodnie, jak w każdym innym systemie informatycznym.
Jednak systemy informacyjne mają niewiele wspólnego z hermetyzacją. W rzeczywistości jest zupełnie odwrotnie. Bazy danych robią wszystko, co w ich mocy, aby zapewnić dostęp do przechowywanych w nich danych. Są wyposażone w potężny interfejs deklaratywny, który pozwala modyfikować dane według potrzeb. Taka funkcjonalność jest istotna na etapie badań wstępnych, ale nie do zarządzania rosnącą złożonością stale rozwijającej się usługi.
I tu pojawia się dylemat. Sprzeczność. Dychotomia. W końcu systemy informacyjne służą do dostarczania danych, a usługi do ukrywania.
Te dwie siły są fundamentalne. Stanowią one podstawę dużej części naszej pracy, nieustannie walcząc o doskonałość w budowanych przez nas systemach.
W miarę rozwoju i ewolucji systemów usług widzimy wielorakie konsekwencje dychotomii danych. Albo interfejs usługi będzie się rozrastał, zapewniając coraz większy zakres funkcjonalności i zacznie wyglądać jak bardzo fantazyjna, własna baza danych, albo popadniemy w frustrację i wdrożymy jakiś sposób na pobieranie lub masowe przenoszenie całych zestawów danych z usługi do usługi.
Z kolei stworzenie czegoś, co wygląda jak fantazyjna, własna baza danych, doprowadzi do całej masy problemów. Nie będziemy wdawać się w szczegóły, dlaczego jest to niebezpieczne wspólna baza danych, powiedzmy, że oznacza to znaczne koszty inżynieryjne i operacyjne dla firmy, która próbuje z niego skorzystać.
Co gorsza, woluminy danych zwiększają problemy z granicami usług. Im więcej wspólnych danych znajduje się w ramach usługi, tym bardziej złożony stanie się interfejs i tym trudniej będzie połączyć zbiory danych pochodzących z różnych usług.
Alternatywne podejście polegające na wyodrębnianiu i przenoszeniu całych zbiorów danych również ma swoje problemy. Typowe podejście do tego pytania polega na prostym pobraniu i przechowywaniu całego zbioru danych, a następnie przechowywaniu go lokalnie w każdej korzystającej z niego usłudze.
Problem polega na tym, że różne usługi różnie interpretują dane, które wykorzystują. Te dane są zawsze pod ręką. Są one modyfikowane i przetwarzane lokalnie. Dość szybko przestają mieć one cokolwiek wspólnego z danymi źródłowymi.
Im bardziej zmienne są kopie, tym bardziej dane będą się zmieniać w czasie.
Co gorsza, z perspektywy czasu trudno jest skorygować takie dane ( Tutaj naprawdę może przyjść na ratunek). W rzeczywistości niektóre z nierozwiązywalnych problemów technologicznych, przed którymi stają firmy, wynikają z rozbieżnych danych, które mnożą się w kolejnych aplikacjach.
Aby znaleźć rozwiązanie tego problemu, musimy inaczej spojrzeć na udostępniane dane. Muszą stać się obiektami najwyższej klasy w budowanych przez nas architekturach. nazywa takie dane „zewnętrznymi”, a to bardzo istotna cecha. Potrzebujemy enkapsulacji, abyśmy nie ujawniali wewnętrznego działania usługi, ale musimy ułatwić usługom dostęp do współdzielonych danych, aby mogły poprawnie wykonywać swoje zadania.
Problem w tym, że żadne z podejść nie jest dziś aktualne, ponieważ ani interfejsy usług, ani przesyłanie wiadomości, ani wspólna baza danych nie oferują dobrego rozwiązania do pracy z danymi zewnętrznymi. Interfejsy usług słabo nadają się do wymiany danych w dowolnej skali. Aplikacja Messaging przenosi dane, ale nie przechowuje ich historii, więc z biegiem czasu dane ulegają uszkodzeniu. Wspólne bazy danych skupiają się zbytnio na jednym punkcie, co wstrzymuje postęp. Nieuchronnie utkniemy w cyklu awarii danych:
Cykl awarii danych
Strumienie: zdecentralizowane podejście do danych i usług
Idealnie byłoby, gdybyśmy zmienili sposób, w jaki usługi działają z udostępnionymi danymi. W tym momencie oba podejścia stoją w obliczu wspomnianej dychotomii, ponieważ nie ma magicznego pyłu, który można by posypać, aby zniknął. Możemy jednak ponownie przemyśleć problem i osiągnąć kompromis.
Kompromis ten zakłada pewien stopień centralizacji. Możemy zastosować mechanizm dziennika rozproszonego, ponieważ zapewnia niezawodne, skalowalne strumienie. Chcemy teraz, aby usługi mogły łączyć się z tymi współdzielonymi wątkami i działać na nich, ale chcemy uniknąć skomplikowanych, scentralizowanych Usług Bożych, które zajmują się tym przetwarzaniem. Dlatego najlepszą opcją jest wbudowanie przetwarzania strumieniowego w każdą usługę konsumencką. W ten sposób usługi będą mogły łączyć zbiory danych z różnych źródeł i pracować z nimi tak, jak tego potrzebują.
Jednym ze sposobów osiągnięcia tego podejścia jest wykorzystanie platformy do przesyłania strumieniowego. Opcji jest wiele, ale dziś przyjrzymy się Kafce, gdyż zastosowanie w niej Stateful Stream Processing pozwala nam skutecznie rozwiązać przedstawiony problem.
Korzystanie z mechanizmu rozproszonego rejestrowania pozwala nam podążać wydeptaną ścieżką i wykorzystywać komunikaty do pracy . Uważa się, że to podejście zapewnia lepsze skalowanie i partycjonowanie niż mechanizm żądanie-odpowiedź, ponieważ daje kontrolę nad przepływem do odbiorcy, a nie do nadawcy. Jednak za wszystko w tym życiu trzeba zapłacić, a tutaj potrzebny jest broker. Jednak w przypadku dużych systemów kompromis jest tego wart (co może nie mieć miejsca w przypadku przeciętnej aplikacji internetowej).
Jeśli za logowanie rozproszone odpowiada broker, a nie tradycyjny system przesyłania wiadomości, możesz skorzystać z dodatkowych funkcji. Transport może być skalowany liniowo niemal tak dobrze, jak rozproszony system plików. Dane mogą być przechowywane w logach dość długo, dzięki czemu uzyskujemy nie tylko wymianę wiadomości, ale także przechowywanie informacji. Skalowalna pamięć masowa bez obawy o zmienny stan współdzielony.
Następnie można użyć stanowego przetwarzania strumienia, aby dodać deklaratywne narzędzia bazy danych do usług korzystających z usług. To bardzo ważny pomysł. Chociaż dane są przechowywane we współdzielonych strumieniach, do których mają dostęp wszystkie usługi, agregacja i przetwarzanie wykonywane przez tę usługę mają charakter prywatny. Czują się izolowani w ściśle ograniczonym kontekście.
Wyeliminuj dychotomię danych, oddzielając niezmienny strumień stanu. Następnie dodaj tę funkcjonalność do każdej usługi przy użyciu Stateful Stream Processing.
Tym samym, jeśli Twój serwis będzie musiał pracować z zamówieniami, katalogiem produktów, magazynem, będzie miał pełny dostęp: tylko Ty będziesz decydować, jakie dane połączyć, gdzie je przetworzyć i jak powinny zmieniać się w czasie. Pomimo tego, że dane są współdzielone, praca z nimi jest całkowicie zdecentralizowana. Powstaje w ramach każdego serwisu, w świecie, w którym wszystko toczy się według Twoich zasad.
Udostępniaj dane bez naruszania ich integralności. Hermetyzuj funkcję, a nie źródło, w każdej usłudze, która tego potrzebuje.
Zdarza się, że dane trzeba przenieść masowo. Czasami usługa wymaga lokalnego zbioru danych historycznych w wybranym silniku bazy danych. Sztuka polega na tym, że możesz zagwarantować, że w razie potrzeby kopię będzie można przywrócić ze źródła, korzystając z mechanizmu rozproszonego rejestrowania. Złącza w Kafce radzą sobie z tym znakomicie.
Zatem omówione dzisiaj podejście ma kilka zalet:
- Dane wykorzystywane są w postaci wspólnych strumieni, które można przechowywać w logach przez długi czas, a mechanizm pracy ze wspólnymi danymi jest wbudowany w każdym indywidualnym kontekście, co pozwala na łatwe i szybkie działanie usług. W ten sposób można zrównoważyć dychotomię danych.
- Dane pochodzące z różnych serwisów można łatwo łączyć w zestawy. Upraszcza to interakcję ze udostępnianymi danymi i eliminuje potrzebę utrzymywania lokalnych zbiorów danych w bazie danych.
- Stateful Stream Processing jedynie buforuje dane, a źródłem prawdy pozostają ogólne logi, więc problem uszkodzenia danych w czasie nie jest aż tak dotkliwy.
- W swojej istocie usługi opierają się na danych, co oznacza, że pomimo stale rosnącej ilości danych, usługi nadal mogą szybko reagować na wydarzenia biznesowe.
- Problemy ze skalowalnością spadają na brokera, a nie na usługi. To znacznie zmniejsza złożoność pisania usług, ponieważ nie trzeba myśleć o skalowalności.
- Dodawanie nowych usług nie wymaga zmiany starych, dzięki czemu podłączanie nowych usług staje się łatwiejsze.
Jak widać to coś więcej niż tylko ODPOCZYNEK. Otrzymaliśmy zestaw narzędzi, który pozwala na pracę z udostępnionymi danymi w sposób zdecentralizowany.
Nie wszystkie aspekty zostały omówione w dzisiejszym artykule. Nadal musimy wymyślić, jak zachować równowagę między paradygmatem żądanie-odpowiedź a paradygmatem sterowanym zdarzeniami. Ale tym zajmiemy się następnym razem. Są tematy, które musisz poznać lepiej, na przykład dlaczego Stateful Stream Processing jest tak dobry. Porozmawiamy o tym w trzecim artykule. Istnieją również inne potężne konstrukcje, z których możemy skorzystać, jeśli się do nich odwołamy, na przykład: . Jest to przełomowe rozwiązanie dla rozproszonych systemów biznesowych, ponieważ zapewnia gwarancje transakcyjne w skalowalnej formie. Zostanie to omówione w czwartym artykule. Na koniec będziemy musieli omówić szczegóły wdrożenia tych zasad.
Ale na razie pamiętaj o tym: dychotomia danych to siła, przed którą stoimy, budując usługi biznesowe. I musimy o tym pamiętać. Sztuka polega na tym, aby wywrócić wszystko do góry nogami i zacząć traktować udostępniane dane jak obiekty najwyższej klasy. Stateful Stream Processing zapewnia w tym zakresie unikalny kompromis. Unika scentralizowanych „boskich komponentów”, które wstrzymują postęp. Co więcej, zapewnia elastyczność, skalowalność i odporność potoków strumieniowego przesyłania danych oraz dodaje je do każdej usługi. Dlatego możemy skupić się na ogólnym strumieniu świadomości, z którym może połączyć się dowolna usługa i pracować z jej danymi. Dzięki temu usługi są bardziej skalowalne, wymienne i autonomiczne. Dzięki temu nie tylko będą dobrze wyglądać na tablicach i testach hipotez, ale będą również działać i ewoluować przez dziesięciolecia.
Źródło: www.habr.com