W naszej bran\u017cy, specjali\u015bci chc\u0105 wykorzystywa\u0107 na co dzie\u0144 najnowsze technologie, oferowa\u0107 swoim klientom nowoczesne rozwi\u0105zania, a klienci zamawia\u0107 systemy, kt\u00f3re pod\u0105\u017caj\u0105 z duchem czasu – to zrozumia\u0142e. Na nasze wsp\u00f3lne nieszcz\u0119\u015bcie, nie zawsze pami\u0119tamy, \u017ce wyb\u00f3r architektury niesie za sob\u0105 konsekwencje<\/strong>, a tworzenie system\u00f3w rozproszonych<\/strong>, nawet w 2019 roku, wci\u0105\u017c jest trudne<\/strong>. Dlatego, na tegorocznej konferencji Pozitive technologies<\/a> postanowi\u0142em opowiedzie\u0107 o tej drugiej, nieco przemilczanej stronie takich architektur. Zapominaj\u0105c na chwil\u0119 o ich popularno\u015bci i niew\u0105tpliwych zaletach, wy\u0142ania si\u0119 bowiem rzeczywisto\u015b\u0107 bardziej przypominaj\u0105ca pe\u0142n\u0105 zagro\u017ce\u0144 d\u017cungl\u0119, ni\u017c rajski ogr\u00f3d. Ten wpis b\u0119dzie nie tyle kompletnym kursem przetrwania, co ostrze\u017ceniem o tym, co czyha na nas w rozproszonym \u015bwiecie – zanim na YouTube pojawi si\u0119 nagranie z mojego wyst\u0105pienia.<\/p>\n\n\n\n Z praktycznego punktu widzenia, definicja systemu rozproszonego jest prosta<\/strong> – to zbi\u00f3r niezale\u017cnych komponent\u00f3w<\/strong> (us\u0142ug, modu\u0142\u00f3w, funkcji, itd.), kt\u00f3re mog\u0105 znajdowa\u0107 si\u0119 na zupe\u0142nie innych maszynach, komunikuj\u0105cych si\u0119 ze sob\u0105 poprzez sie\u0107<\/strong>. W teorii, awaria jednego z nich nie wp\u0142ywa dzi\u0119ki temu na pozosta\u0142e, a ka\u017cdy z komponent\u00f3w mo\u017ce by\u0107 skalowany niezale\u017cnie (poprzez zwi\u0119kszanie liczby jego instancji). Po drugiej stronie, mamy „klasyczne” podej\u015bcie monolityczne<\/strong> – aplikacj\u0119, kt\u00f3ra stanowi jedn\u0105 ca\u0142o\u015b\u0107<\/strong>, kt\u00f3ra w przypadku awarii jest ca\u0142kowicie niedost\u0119pna i uruchamiana<\/strong> jest na pojedynczej maszynie<\/strong>. A skaluje si\u0119, delikatnie m\u00f3wi\u0105c, do\u015b\u0107 niekorzystnie. W takim zestawieniu, mo\u017ce si\u0119 wydawa\u0107, \u017ce monolity nie maj\u0105 \u017cadnych szans w starciu z nowoczesno\u015bci\u0105…<\/p>\n\n\n\n Problemy rozproszonego \u015bwiata to jednak cz\u0119sto kwestie, kt\u00f3re przy pracy nad monolitami nie przysz\u0142yby nam nawet do g\u0142owy. Przyk\u0142adowo, je\u015bli jedna cz\u0119\u015b\u0107 monolitycznej aplikacji musi skorzysta\u0107 z funkcji oferowanej przez drug\u0105, to takie wywo\u0142anie mo\u017ce si\u0119 zero-jedynkowo uda\u0107 w ca\u0142o\u015bci lub nie, a czas potrzebny na sam\u0105 komunikacj\u0119 jest w\u0142a\u015bciwie nieistotny z wydajno\u015bciowego punktu widzenia. W \u015bwiecie rozproszonym, gdy us\u0142uga\/funkcja (zale\u017cnie od implementacji) wywo\u0142uje inn\u0105, sytuacja drastycznie si\u0119 komplikuje, a czas wywo\u0142ania odgrywa istotn\u0105 rol\u0119. Wszystko to przez jeden, bagatelizowany szczeg\u00f3\u0142 – komunikacja odbywa si\u0119 poprzez sie\u0107, a ta jest zaskakuj\u0105co zawodna<\/strong>. W przypadku wywo\u0142a\u0144 sieciowych w\u0142a\u015bciwie mo\u017cemy zapomnie\u0107 o zero-jedynkowo\u015bci, a prawo Murphy’ego staje si\u0119 nasz\u0105 codzienno\u015bci\u0105.<\/p>\n\n\n\n Rozwa\u017cmy nast\u0119puj\u0105cy przyk\u0142ad komunikacji synchronicznej:<\/p>\n\n\n\n Nawet w tak prostej sytuacji:<\/p>\n\n\n\n Skoro tego rodzaju problemy wyst\u0119puj\u0105 tak cz\u0119sto, pojawia si\u0119 pytanie: czy w takim razie wszystkie systemy tego typu nie powinny by\u0107 na to przygotowane? Odpowied\u017a jest prosta – tak, powinny. Niestety do\u015bwiadczenie pokazuje, \u017ce zawodno\u015b\u0107 sieci jest najcz\u0119\u015bciej ignorowanym problemem w tego typu rozwi\u0105zaniach<\/strong>. Przynajmniej do czasu, gdy takie systemy zostaj\u0105 wreszcie uruchomione produkcyjnie i udost\u0119pnione prawdziwym u\u017cytkownikom…<\/p>\n\n\n\n A co w sytuacji, gdy wywo\u0142anie B<\/em> zmienia stan systemu – np. poprzez aktualizacj\u0119 jakiej\u015b bazy danych?<\/p>\n\n\n\n Lata pracy z aplikacjami monolitycznymi, w kt\u00f3rych korzystamy na dodatek g\u0142\u00f3wnie tylko z jednego \u017ar\u00f3d\u0142a (bazy) danych, przyzwyczai\u0142y nas do tego, \u017ce semantyk\u0119 transakcyjno\u015bci – rozumian\u0105 jako wykonanie „wszystko albo nic” – dostajemy niemal za darmo. Je\u015bli wi\u0119c nasz proces biznesowy sk\u0142ada si\u0119 z wielu krok\u00f3w zmieniaj\u0105cych stan (np. zaksi\u0119gowanie p\u0142atno\u015bci, stworzenie zam\u00f3wienia, wystawienie faktury, itp.) to w przypadku b\u0142\u0119du na kt\u00f3rymkolwiek etapie oczekujemy, \u017ce anulowane zostan\u0105 wszystkie z nich. W ten spos\u00f3b osi\u0105gamy sp\u00f3jno\u015b\u0107 danych rozumian\u0105 z perspektywy biznesowej poprawno\u015bci.<\/p>\n\n\n\n W\u0142asno\u015bci te, z jakiego\u015b powodu, mylnie przyj\u0119\u0142o si\u0119 \u0142\u0105czy\u0107 jedynie z relacyjnymi bazami danych (ACID<\/a>), a wiele os\u00f3b do dzi\u015b zawzi\u0119cie wierzy, \u017ce ich transakcyjno\u015b\u0107 jest swego rodzaju „panaceum na b\u0142\u0119dy”, bez kt\u00f3rego nie mo\u017ce si\u0119 oby\u0107 \u017caden „powa\u017cny” system klasy enterprise. Niestety, nawet ona sta\u0142a si\u0119, moim zdaniem, ofiar\u0105 swojego sukcesu i marketingu – notorycznie jest nadu\u017cywana i stosowana do\u015b\u0107 lekkomy\u015blnie. Zainteresowanych tematem (lub linczem na mojej osobie, za tak nonszalanckie zdeptanie bazodanowych \u015bwi\u0119to\u015bci ?) odsy\u0142am do \u015bwietnej prezentacji Martina Kleppmanna<\/a>.<\/p>\n\n\n\nPrzepraszam, co\u015b mnie rozproszy\u0142o…<\/h2>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2019\/10\/network_call_synchronous.png\")
<\/a><\/figure>\n\n\n\n\n
Sp\u00f3jno\u015b\u0107 danych<\/h2>\n\n\n\n