{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dichotomia danych: przewarto\u015bciowanie podej\u015bcia do danych i us\u0142ug","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107 wszystkim! Mamy \u015bwietne wie\u015bci, w czerwcu OTUS ponownie uruchamia kurs \u201eArchitekt Oprogramowania\u201d<\/a><\/noindex>, z tej okazji tradycyjnie dzielimy si\u0119 z wami przydatnym materia\u0142em.<\/b><\/i><\/p>\n

\"Dichotomia
\n
\n Je\u015bli natkn\u0105\u0142e\u015b si\u0119 na ca\u0142\u0105 t\u0119 histori\u0119 o mikroserwisach bez \u017cadnego kontekstu, mo\u017cna zrozumie\u0107, \u017ce wydaje si\u0119 ona nieco dziwna. Podzia\u0142 aplikacji na fragmenty, po\u0142\u0105czone ze sob\u0105 sieci\u0105, z pewno\u015bci\u0105 oznacza dodanie skomplikowanych tryb\u00f3w odporno\u015bci na awarie do powsta\u0142ego rozproszonego systemu. <\/p>\n

Mimo \u017ce takie podej\u015bcie polega na podziale na wiele niezale\u017cnych serwis\u00f3w, ostateczny cel jest znacznie wi\u0119kszy ni\u017c tylko dzia\u0142anie tych serwis\u00f3w na r\u00f3\u017cnych maszynach. Chodzi tutaj o interakcj\u0119 z otaczaj\u0105cym \u015bwiatem, kt\u00f3ry z natury r\u00f3wnie\u017c jest rozproszony. Nie w sensie technicznym, a raczej w sensie ekosystemu, kt\u00f3ry sk\u0142ada si\u0119 z wielu ludzi, zespo\u0142\u00f3w, program\u00f3w, gdzie ka\u017cda z tych cz\u0119\u015bci w taki czy inny spos\u00f3b musi wykonywa\u0107 swoj\u0105 prac\u0119.<\/a><\/noindex><\/p>\n

Firmy na przyk\u0142ad s\u0105 zbiorem rozproszonych system\u00f3w, kt\u00f3re wsp\u00f3lnie przyczyniaj\u0105 si\u0119 do osi\u0105gni\u0119cia jakiego\u015b celu. Ignorowali\u015bmy ten fakt przez dekady, pr\u00f3buj\u0105c osi\u0105gn\u0105\u0107 integracj\u0119, przesy\u0142aj\u0105c pliki przez FTP lub korzystaj\u0105c z narz\u0119dzi integracji korporacyjnej, koncentruj\u0105c si\u0119 przy tym na swoich osobistych, odosobnionych celach. Jednak z nadej\u015bciem serwis\u00f3w wszystko si\u0119 zmieni\u0142o. Serwisy pomog\u0142y nam spojrze\u0107 za horyzont i zobaczy\u0107 \u015bwiat wzajemnie zale\u017cnych program\u00f3w, kt\u00f3re wsp\u00f3\u0142pracuj\u0105. Jednak aby dzia\u0142a\u0107 z sukcesem, trzeba zrozumie\u0107 i zaprojektowa\u0107 dwa zasadniczo r\u00f3\u017cne \u015bwiaty: \u015bwiat zewn\u0119trzny, w kt\u00f3rym \u017cyjemy w ekosystemie wielu innych serwis\u00f3w, oraz nasz osobisty, wewn\u0119trzny \u015bwiat, w kt\u00f3rym rz\u0105dzimy sami.<\/p>\n

\"Dichotomia
\n
\n Taki rozproszony \u015bwiat r\u00f3\u017cni si\u0119 od tego, w kt\u00f3rym dorastali\u015bmy i do kt\u00f3rego przywykli\u015bmy. Zasady budowy tradycyjnej architektury monolitycznej nie znosz\u0105 krytyki. Dlatego prawid\u0142owe zrozumienie takich system\u00f3w to co\u015b wi\u0119cej ni\u017c stworzenie fajnego schematu na bia\u0142ej tablicy lub \u015bwietnego dowodu koncepcji. Chodzi o to, aby taki system skutecznie funkcjonowa\u0142 przez d\u0142ugi czas. Na szcz\u0119\u015bcie serwisy istniej\u0105 ju\u017c od dawna, chocia\u017c wygl\u0105daj\u0105 r\u00f3\u017cnie. Lekcje SOA<\/a><\/noindex> s\u0105 nadal aktualne, nawet je\u015bli przyprawione Dockerem, Kubernetesem i nieco zniszczone hipsterskimi brodami. <\/p>\n

Dzi\u015b przyjrzymy si\u0119, jak zmieni\u0142y si\u0119 zasady, dlaczego musimy przeanalizowa\u0107 nasze podej\u015bcie do us\u0142ug i danych, kt\u00f3re mi\u0119dzy sob\u0105 przesy\u0142aj\u0105, oraz dlaczego b\u0119dziemy potrzebowa\u0107 zupe\u0142nie innego zestawu narz\u0119dzi.<\/p>\n

Enkapsulacja nie zawsze b\u0119dzie dla Ciebie przyjacielem.<\/h3>\n

\n Mikroserwisy mog\u0105 dzia\u0142a\u0107 niezale\u017cnie od siebie. To w\u0142a\u015bnie ta cecha nadaje im najwi\u0119ksz\u0105 warto\u015b\u0107. Ta sama cecha pozwala us\u0142ugom na skalowanie i rozw\u00f3j. Nie tyle w sensie skalowania do kwadrylion\u00f3w u\u017cytkownik\u00f3w czy petabajt\u00f3w danych (chocia\u017c w tym r\u00f3wnie\u017c mog\u0105 pom\u00f3c), ale w sensie skalowania pod wzgl\u0119dem ludzi, poniewa\u017c zespo\u0142y i organizacje ci\u0105gle rosn\u0105.<\/p>\n

\"Dichotomia
\n
\nJednak niezale\u017cno\u015b\u0107 to miecz obosieczny. Us\u0142uga sama w sobie mo\u017ce dzia\u0142a\u0107 p\u0142ynnie i beztrosko. Ale je\u015bli w obr\u0119bie us\u0142ugi realizowana jest funkcja, kt\u00f3ra wymaga zaanga\u017cowania innej us\u0142ugi, to w ko\u0144cu musimy wprowadzi\u0107 zmiany w obu us\u0142ugach niemal r\u00f3wnocze\u015bnie. W monolicie jest to \u0142atwe \u2014 po prostu wprowadzasz zmian\u0119 i wysy\u0142asz j\u0105 do wersji, ale w przypadku synchronizacji niezale\u017cnych us\u0142ug, problem\u00f3w b\u0119dzie znacznie wi\u0119cej. Koordynacja pomi\u0119dzy zespo\u0142ami i cyklami wydania narusza elastyczno\u015b\u0107.<\/p>\n

\"Dichotomia
\n
\nW ramach standardowego podej\u015bcia niechciane zmiany mi\u0119dzy us\u0142ugami s\u0105 po prostu starannie unikane, jasno oddzielaj\u0105c funkcjonalno\u015b\u0107 mi\u0119dzy us\u0142ugami. Us\u0142uga jednego punktu wej\u015bcia do systemu mo\u017ce by\u0107 dobrym przyk\u0142adem. Ma ona jasno okre\u015blon\u0105 rol\u0119, kt\u00f3ra odr\u00f3\u017cnia j\u0105 od innych us\u0142ug. Takie wyra\u017ane oddzielenie oznacza, \u017ce w \u015bwiecie szybko zmieniaj\u0105cych si\u0119 wymaga\u0144 wobec otaczaj\u0105cych j\u0105 us\u0142ug, us\u0142uga jednego punktu wej\u015bcia do systemu prawdopodobnie nie b\u0119dzie ulega\u0107 zmianom. Istnieje w \u015bci\u015ble ograniczonym kontek\u015bcie.<\/p>\n

\"Dichotomia
\n
\n Problem polega na tym, \u017ce w rzeczywistym \u015bwiecie us\u0142ugi biznesowe nie mog\u0105 stale utrzymywa\u0107 czystego podzia\u0142u r\u00f3l. Na przyk\u0142ad, te same us\u0142ugi biznesowe w wi\u0119kszym stopniu operuj\u0105 na danych pochodz\u0105cych od innych podobnych us\u0142ug. Je\u015bli zajmujesz si\u0119 handlem internetowym, przetwarzanie strumienia zam\u00f3wie\u0144, katalogu produkt\u00f3w czy informacji o u\u017cytkownikach b\u0119dzie wymaga\u0107 od wielu Twoich us\u0142ug dost\u0119pu do tych danych. <\/p>\n

\"Dichotomia
\nWi\u0119kszo\u015b\u0107 us\u0142ug biznesowych korzysta z tego samego strumienia danych, dlatego ich praca niezmiennie si\u0119 przeplata.<\/i><\/p>\n

W ten spos\u00f3b dotarli\u015bmy do wa\u017cnego momentu, o kt\u00f3rym warto porozmawia\u0107. Podczas gdy us\u0142ugi dobrze dzia\u0142aj\u0105 w przypadku komponent\u00f3w infrastruktury, kt\u00f3re funkcjonuj\u0105 w znacznym stopniu oddzielnie, wi\u0119kszo\u015b\u0107 us\u0142ug biznesowych okazuje si\u0119 by\u0107 ze sob\u0105 znacznie \u015bci\u015blej powi\u0105zana.<\/p>\n

Dychotomia danych<\/h3>\n

\n Podej\u015bcia oparte na us\u0142ugach mog\u0105 ju\u017c istnie\u0107, jednak wci\u0105\u017c brakuje informacji na temat wymiany du\u017cych ilo\u015bci danych mi\u0119dzy us\u0142ugami.<\/p>\n

G\u0142\u00f3wny problem polega na tym, \u017ce dane i us\u0142ugi s\u0105 nieroz\u0142\u0105czne. Z jednej strony, enkapsulacja wzywa nas do ukrywania danych, aby us\u0142ugi mo\u017cna by\u0142o oddzieli\u0107 od siebie i u\u0142atwi\u0107 ich rozw\u00f3j oraz dalsze zmiany. Z drugiej strony, musimy mie\u0107 mo\u017cliwo\u015b\u0107 swobodnego dzielenia si\u0119 i zarz\u0105dzania wsp\u00f3lnymi danymi, jak i innymi. Chodzi o to, aby mie\u0107 mo\u017cliwo\u015b\u0107 natychmiastowego rozpocz\u0119cia pracy, tak swobodnie, jak w ka\u017cdym innym systemie informacyjnym.<\/p>\n

Jednak systemy informacyjne maj\u0105 ma\u0142o wsp\u00f3lnego z enkapsulacj\u0105. W rzeczywisto\u015bci jest wr\u0119cz przeciwnie. Bazy danych robi\u0105 wszystko, co w ich mocy, aby zapewni\u0107 dost\u0119p do przechowywanych w nich danych. Oferuj\u0105 pot\u0119\u017cny deklaratywny interfejs, kt\u00f3ry pozwala na modyfikacj\u0119 danych wed\u0142ug Twoich potrzeb. Taka funkcjonalno\u015b\u0107 jest wa\u017cna na etapie wst\u0119pnych bada\u0144, ale nie w zarz\u0105dzaniu rosn\u0105c\u0105 z\u0142o\u017cono\u015bci\u0105 stale rozwijaj\u0105cych si\u0119 us\u0142ug.<\/p>\n

\"Dichotomia
\n
\n I tu pojawia si\u0119 dylemat. Sprzeczno\u015b\u0107. Dychotomia. Bowiem systemy informacyjne to kwestia udost\u0119pniania danych, a us\u0142ugi to kwestia ich ukrywania.<\/p>\n

Te dwie si\u0142y s\u0105 fundamentalne. Le\u017c\u0105 u podstaw wi\u0119kszo\u015bci naszej pracy, nieustannie rywalizuj\u0105c o dominacj\u0119 w systemach, kt\u00f3re tworzymy.<\/p>\n

W miar\u0119 jak systemy us\u0142ugowe rosn\u0105 i ewoluuj\u0105, dostrzegamy r\u00f3\u017cne manifestacje konsekwencji dylematu danych. Albo interfejs us\u0142ugi b\u0119dzie si\u0119 rozwija\u0142, oferuj\u0105c coraz szerszy zestaw funkcji i zacznie wygl\u0105da\u0107 jak dziwaczna, domowej roboty baza danych, albo napotkamy rozczarowanie i wdro\u017cymy spos\u00f3b na masowe wydobywanie lub przenoszenie kompletnych zestaw\u00f3w danych z us\u0142ugi do us\u0142ugi.<\/p>\n

\"Dichotomia
\n
\n Stworzenie czego\u015b, co wygl\u0105da jak dziwaczna, domowej roboty baza danych, prowadzi do szeregu problem\u00f3w. Nie zag\u0142\u0119biaj\u0105c si\u0119 w szczeg\u00f3\u0142y, czym powinna by\u0107 shared database<\/i>, po prostu powiedzmy, \u017ce wi\u0105\u017ce si\u0119 to z znacznymi kosztownymi wyzwaniami in\u017cynieryjnymi i operacyjnymi trudno\u015bciami<\/a><\/noindex> dla firmy pr\u00f3buj\u0105cej j\u0105 wykorzysta\u0107.<\/p>\n

Gorsze jest to, \u017ce ilo\u015b\u0107 danych zaostrza problemy z granicami us\u0142ug. Im wi\u0119cej wsp\u00f3lnych danych znajduje si\u0119 wewn\u0105trz us\u0142ugi, tym trudniejszy staje si\u0119 interfejs i tym trudniej \u0142\u0105czy\u0107 zestawy danych pochodz\u0105ce z r\u00f3\u017cnych us\u0142ug.<\/p>\n

Alternatywne podej\u015bcie do wydobywania i przenoszenia ca\u0142ych zestaw\u00f3w danych tak\u017ce ma swoje problemy. Powszechny spos\u00f3b podej\u015bcia do tej kwestii polega na prostym wydobyciu i przechowywaniu ca\u0142ego zestawu danych, a nast\u0119pnie przechowywaniu go lokalnie w ka\u017cdej us\u0142udze konsumuj\u0105cej.<\/p>\n

\"Dichotomia
\n
\n Problem polega na tym, \u017ce r\u00f3\u017cne us\u0142ugi r\u00f3\u017cnie interpretuj\u0105 dane, kt\u00f3re konsumuj\u0105. Te dane s\u0105 zawsze pod r\u0119k\u0105. Modyfikowane i przetwarzane lokalnie, szybko przestaj\u0105 mie\u0107 cokolwiek wsp\u00f3lnego z danymi w \u017ar\u00f3dle.<\/p>\n

\"Dichotomia
\n Im bardziej mutowalne s\u0105 kopie, tym bardziej dane b\u0119d\u0105 si\u0119 r\u00f3\u017cni\u0107 z up\u0142ywem czasu.<\/i><\/p>\n

Co gorsza, takie dane trudno poprawi\u0107 wstecz (MDM<\/a><\/noindex> tutaj naprawd\u0119 mo\u017ce si\u0119 przyda\u0107). W rzeczywisto\u015bci niekt\u00f3re z trudnych do rozwi\u0105zania problem\u00f3w technologicznych, z kt\u00f3rymi boryka si\u0119 biznes, wynikaj\u0105 z zr\u00f3\u017cnicowanych danych mno\u017c\u0105cych si\u0119 od aplikacji do aplikacji.<\/p>\n

Aby znale\u017a\u0107 rozwi\u0105zanie tego problemu z wsp\u00f3lnymi danymi, trzeba my\u015ble\u0107 inaczej. Powinny sta\u0107 si\u0119 pierwszorz\u0119dnymi obiektami w architekturach, kt\u00f3re budujemy. Pat Helland<\/a><\/noindex> nazywa te dane \u201ezewn\u0119trznymi\u201d, a jest to bardzo wa\u017cna cecha. Potrzebujemy inkapsulacji, aby nie ujawnia\u0107 wewn\u0119trznej struktury us\u0142ugi, ale musimy u\u0142atwi\u0107 us\u0142ugom dost\u0119p do danych wsp\u00f3\u0142dzielonych, aby mog\u0142y prawid\u0142owo wykonywa\u0107 swoj\u0105 prac\u0119.<\/p>\n

\"Dichotomia
\n
\n Problem polega na tym, \u017ce \u017caden z obecnych podej\u015b\u0107 nie jest ju\u017c aktualny, poniewa\u017c ani interfejsy us\u0142ug, ani wymiana wiadomo\u015bci, ani baza danych wsp\u00f3\u0142dzielonych nie oferuj\u0105 dobrego rozwi\u0105zania do pracy z danymi zewn\u0119trznymi. Interfejsy us\u0142ug s\u0142abo nadaj\u0105 si\u0119 do wymiany danych w jakiejkolwiek skali. Wymiana wiadomo\u015bci przenosi dane, ale nie przechowuje ich historii, co prowadzi do uszkodzenia danych w miar\u0119 up\u0142ywu czasu. Bazy danych wsp\u00f3\u0142dzielonych s\u0105 zbyt mocno skoncentrowane w jednym punkcie, co ogranicza rozw\u00f3j post\u0119pu. Nieuchronnie utkn\u0119li\u015bmy w cyklu niew\u0142a\u015bciwych danych.<\/p>\n

\"Dichotomia
\n Cykl niew\u0142a\u015bciwych danych<\/i><\/p>\n

Potoki: zdecentralizowane podej\u015bcie do danych i us\u0142ug<\/h3>\n

\n W idealnym przypadku musimy zmieni\u0107 podej\u015bcie do tego, jak us\u0142ugi pracuj\u0105 z danymi wsp\u00f3lnymi. W tej chwili ka\u017cde podej\u015bcie napotyka wspomnian\u0105 wcze\u015bniej dychotomi\u0119, poniewa\u017c nie ma \u017cadnego magicznego proszku, kt\u00f3rym mo\u017cna by obficie posypa\u0107 i sprawi\u0107, by znikn\u0119\u0142a. Jednak mo\u017cemy przemy\u015ble\u0107 problem i doj\u015b\u0107 do kompromisu.<\/p>\n

Ten kompromis zak\u0142ada pewien stopie\u0144 centralizacji. Mo\u017cemy skorzysta\u0107 z mechanizmu rozproszonych log\u00f3w, poniewa\u017c zapewnia on niezawodne, skalowalne potoki. Teraz potrzebujemy, aby us\u0142ugi mog\u0142y do\u0142\u0105cza\u0107 i wykorzystywa\u0107 te wsp\u00f3lne potoki, jednak chcemy unikn\u0105\u0107 skomplikowanych centralnych us\u0142ug typu God Service, kt\u00f3re wykonuj\u0105 takie przetwarzanie. Dlatego najlepszym rozwi\u0105zaniem jest wbudowanie przetwarzania strumieniowego w ka\u017cd\u0105 us\u0142ug\u0119-konsumenta. W ten spos\u00f3b us\u0142ugi b\u0119d\u0105 mog\u0142y \u0142\u0105czy\u0107 zbiory danych z r\u00f3\u017cnych \u017ar\u00f3de\u0142 i pracowa\u0107 z nimi tak, jak potrzebuj\u0105.<\/p>\n

Jednym ze sposob\u00f3w osi\u0105gni\u0119cia takiego podej\u015bcia jest u\u017cycie platformy strumieniowej. Istnieje wiele opcji, ale dzisiaj przyjrzymy si\u0119 szczeg\u00f3lnie Kafka, poniewa\u017c wykorzystanie jej Stateful Stream Processing umo\u017cliwia skuteczne rozwi\u0105zanie przedstawionego problemu.<\/p>\n

\"Dichotomia
\n
\n Wykorzystanie mechanizmu rozproszonego logowania pozwala nam pod\u0105\u017ca\u0107 utart\u0105 \u015bcie\u017ck\u0105 i u\u017cywa\u0107 wymiany wiadomo\u015bci, aby pracowa\u0107 z architektur\u0105 opart\u0105 na zdarzeniach<\/a><\/noindex>. Uwa\u017ca si\u0119, \u017ce takie podej\u015bcie zapewnia lepsz\u0105 skalowalno\u015b\u0107 i podzia\u0142 ni\u017c mechanizm \u201e\u017c\u0105danie-odpowied\u017a\u201d, poniewa\u017c kontrol\u0119 nad przep\u0142ywem oddaje odbiorcy, a nie nadawcy. Jednak za wszystko w \u017cyciu trzeba p\u0142aci\u0107, a w tym przypadku potrzebny b\u0119dzie broker. Ale dla du\u017cych system\u00f3w ten kompromis jest tego wart (czego nie mo\u017cna powiedzie\u0107 o przeci\u0119tnych aplikacjach internetowych).<\/p>\n

Je\u015bli za rozproszone logowanie odpowiada broker, a nie tradycyjny system wymiany wiadomo\u015bci, mo\u017cna skorzysta\u0107 z dodatkowych funkcji. Transport mo\u017cna liniowo skalowa\u0107 prawie tak dobrze, jak rozproszony system plik\u00f3w. Dane mog\u0105 by\u0107 przechowywane w logach wystarczaj\u0105co d\u0142ugo, dzi\u0119ki czemu otrzymujemy nie tylko wymian\u0119 wiadomo\u015bci, ale i magazyn danych. Skalowalny magazyn bez obaw o uzyskanie zmiennego wsp\u00f3lnego stanu.<\/p>\n

Nast\u0119pnie mo\u017cna u\u017cy\u0107 mechanizmu stateful stream processing (przetwarzanie strumieniowe ze stanem) do dodawania deklaratywnych narz\u0119dzi baz danych do us\u0142ug odbiorc\u00f3w. To bardzo wa\u017cna my\u015bl. Dop\u00f3ki dane s\u0105 przechowywane w wsp\u00f3lnych strumieniach, do kt\u00f3rych mog\u0105 mie\u0107 dost\u0119p wszystkie us\u0142ugi, integracja i przetwarzanie, kt\u00f3re wykonuje us\u0142uga, s\u0105 prywatne. S\u0105 izolowane wewn\u0105trz \u015bci\u015ble okre\u015blonego kontekstu.<\/p>\n

\"Dichotomia
\n Pozb\u0105d\u017a si\u0119 dychotomii danych, dziel\u0105c niezmienny strumie\u0144 stan\u00f3w. Nast\u0119pnie dodaj t\u0119 funkcj\u0119 do ka\u017cdej us\u0142ugi za pomoc\u0105 Stateful Stream Processing.<\/i><\/p>\n

W ten spos\u00f3b, je\u015bli twoja us\u0142uga musi obs\u0142ugiwa\u0107 zam\u00f3wienia, katalog produkt\u00f3w, magazyn, b\u0119dzie mia\u0142a pe\u0142ny dost\u0119p: tylko ty zdecydujesz, kt\u00f3re dane \u0142\u0105czy\u0107, gdzie je przetwarza\u0107 i jak powinny si\u0119 zmienia\u0107 w czasie. Mimo \u017ce dane s\u0105 wsp\u00f3lne, ich przetwarzanie jest ca\u0142kowicie zdecentralizowane. Odbywa si\u0119 wewn\u0105trz ka\u017cdej us\u0142ugi, w \u015bwiecie, w kt\u00f3rym wszystko odbywa si\u0119 wed\u0142ug twoich zasad.<\/p>\n

\"Dichotomia
\nDziel si\u0119 danymi w spos\u00f3b, kt\u00f3ry nie narusza ich integralno\u015bci. Inkap\u0441\u0443\u0142uj funkcj\u0119, a nie \u017ar\u00f3d\u0142o, w ka\u017cdej us\u0142udze, kt\u00f3ra jej potrzebuje.<\/i><\/p>\n

Czasami zachodzi potrzeba masowego przenoszenia danych. Czasami us\u0142uga wymaga lokalnego zestawu historycznych danych w wybranym silniku bazy danych. Kluczowe jest to, \u017ce mo\u017cna zagwarantowa\u0107, i\u017c w razie potrzeby kopia mo\u017ce by\u0107 przywr\u00f3cona z \u017ar\u00f3d\u0142a za pomoc\u0105 dost\u0119pu do mechanizmu rozproszonego logowania. Konektory w Kafka doskonale radz\u0105 sobie z tym zadaniem.<\/p>\n

Zatem omawiana dzisiaj metoda ma kilka zalet:<\/p>\n