Blog MCT - Go Reactive

[Jaca777]

.
 
 
 
 
 
 
 
 
 
 
 
 
  
  
  
   Około 30 lat temu Ericsson zdał sobie sprawę z tego, że żaden istniejący język programowania nie pozwala im na stworzenie bezawaryjnej i współbieżnej aplikacji obsługującej sieci telefoniczne.
Postanowili więc stworzyć własny. Tak powstał Erlang.
 

 

   Wyszło im całkiem nieźle - switch zawierający milion linii kodu w tymże języku miał średnio 0,0315s przestoju rocznie, a zatem jego niezawodność wynosiła 99,9999999%. Dlaczego? Bo był to pierwszy
język stworzony do programowania reaktywnego.
   Weźmy na przykład asynchroniczny serwer napisany w JS. Do sterowania przepływem (tj. stworzenia logiki, tego jak serwer reaguje na odebrane pakiety) używa callback’ów. Jeśli ktoś nie wie – callback
to funkcja, która została przekazana jako argument, gdzieś zapisana, i zostanie wywołana gdy np. zostanie naciśnięty przycisk czy odebrany pakiet danych. Te callback’i są w różny sposób łączone
tworząc coś w rodzaju drzew czy sieci, w których jeden callback wywołuje kilka innych w zależności od jakiegoś warunku.
 

 

   Niestety używanie jednej takiej „sieci” równolegle przez wiele wątków prowadzi do problemów. Często zdarza się, że callback wykonuje operacje zmieniające i korzystające z różnych globalnych wartości,
do których każdy z wątków ma dostęp. Wymaga to synchronizacji, a zatem przy większej ilości kodu łatwo o błąd.
   Łączenie dużej ilości callbacków często prowadzi do tzw. „callback hell”, czyli sytuacji, w której wspomniana „sieć” staje się ogromna, bardzo nieczytelna i trudna do debugowania. Trudno stworzyć w
czytelny sposób wyższą abstrakcję korzystając z prostych callbacków.
 

 

Programowanie reaktywne z założenia ma unikać tych wszystkich problemów. Każdy reaktywny program spełnia cztery warunki:

• Reaguje na zdarzenia – jest nimi sterowany. (event-driven)
• Reaguje na zmianę obciążenia – nie działa gorzej, gdy jest używany w większej skali (scalable)
• Reaguje na błędy – potrafi w miarę możliwości je naprawiać, a błędy lokalne nie mogą wpłynąć na działanie całej aplikacji. (resilient)
• Reaguje na użytkownika – dostosowuje się do niego. (responsive)

   Aby to osiągnąć do tworzenia reaktywnych aplikacji używa się aktorów. Aktora można wyobrazić sobie jako niezależnego człowieka zdolnego do komunikacji z innymi ludźmi. Wykonuje on pewne
zadanie, gdy zostanie o to ‘poproszony’ przez innego aktora przy pomocy wiadomości. Ta wiadomość, gdy dotrze do aktora, jest wrzucana do kolejki otrzymanych wiadomości i zostanie odczytana po
wszystkich innych otrzymanych przez aktora przed nią. Nie są one czytane równolegle. W połączeniu ze stosowaniem niemodyfikowalnych obiektów w wiadomościach eliminuje to problem synchronizacji.
Eliminują także inne problemy oraz pozwalają na bardzo wygodne i czytelne reakcje na błędy, lecz wyjaśnienie tego wymagało by wejścia zdecydowanie głębiej w to zagadnienie. Są także bardzo dobrym
i często stosowanym rozwiązaniem przy tworzeniu systemów rozproszonych.
 

 

   Oczywiście przy programowaniu reaktywnym używa się wielu narzędzi. Aktorzy, których opisałem w sposób bardzo pobieżny, są tylko jednym z nich. Całość okazuje się na tyle skuteczna, że coraz
więcej firm czyni swój kod reaktywnym. Mowa tu o LinkedIn, gdzie prawie cały backend jest napisany w Scali, a także o Twitterze, Sony, Siemensie, The Guardian i wielu innych. Jeśli ktoś czuje się
zainteresowany, to zachęcam do nauki z archiwów kursów:

• https://www.coursera.org/course/progfun - Kurs autora Scali na temat programowania funkcyjnego w tymże języku. Niezbędny do:
• https://www.coursera.org/course/reactive - Kurs tego samego autora koncentrujący się już całkowicie na temacie programowania reaktywnego w Scali.

 

Post: http://jaca77.blogspot.com/2015/08/go-reactive.html?view=classic

[Wampir7858]

W końcu coś ciekawego o Scali

 

Będę mógł się douczyć.

Daje wielkiego plusa

[MXVOL]

Świetny artykuł  . Doceniam wkład pracy więc łapej dużego taka

[The Shifter]

@MXVOL hej mx

 

 

@temat:

 

 

Fajna inicjatywa, taka wiedza się przyda wielu osobom.

[Argin™]

Bardzo ciekawy artykuł i dowiedziałem się czegoś nowego . Świetne wykonanie!

[Gość]

Oby więcej takich artykułów od MPC Coders Team­

[Latreso]

Pierwsze słyszę o tym wszystkim. Bardzo zaskakujące jest to, że jest taki "bezawaryjny", a to trudna sztuka.

 

PS. Kiedy możemy spodziewać się pierwszych odcinków o programowaniu? Czekamy już kilka mies. i nic

[Phoenix_PL]

@Latreso Nie jesteśmy pewni czy to będą nagrane odcinki w jakiś sposób, czy lekcje live, np. na TS'ie (które potem i tak będą udostepnione). Zobaczymy.­

[Latreso]

@Latreso Nie jesteśmy pewni czy to będą nagrane odcinki w jakiś sposób, czy lekcje live, np. na TS'ie (które potem i tak będą udostepnione). Zobaczymy.­

Odcinki, mając na myśli lekcje w dowolnej formie . Ale na chwilę obecną (od wybrania języka, pod kątem którego  będzie prowadzony kurs - 20+ marca) minęło już kilka miesięcy, a my dalej czekamy, na jakąkolwiek informację

[Hans Kloss PL]

Mogłeś jeszcze wspomnie o hot-swappingu (aktualizacja programu bez jego zatrzymywania), który jest ważną składową tej niezawodności. Artykuł bardzo fajny

[SlimaKCode]

Mniej więcej staram się pojąc o co chodzi w programowaniu reaktywnym. Może moje pytanie jest głupie, ale istnieje jakiś sposób implementacji tego na dużą skalę w PHP i JS? Na przykład gdybym uznał każdego użytkownika za "aktora" i przy pomocy JS każdy z nich wykonywałby jakieś zadania, a potem przesyłał wyniki do serwerów z PHP, a te serwery komunikowały by się miedzy sobą?

[Jaca777]

Może moje pytanie jest głupie, ale istnieje jakiś sposób implementacji tego na dużą skalę w PHP i JS?

JS jak najbardziej.

https://github.com/Reactive-Extensions/RxJS

A biblioteki z aktorami też łatwo znaleźć:

https://github.com/stagas/drama

https://github.com/Gozala/actor

https://github.com/mental/webactors

 

W PHP niestety nie ma to za bardzo sensu. Podstawą reaktywnego programowania jest niesynchroniczna współbieżność, no a php się raczej do tego nie nadaje. Sensowne biblioteki też trudno znaleźć. Jasne - można samemu je zrobić, ale,

póki zbyt dobrze nie rozumie się tej idei, lepiej tego unikać. Poza tym jeśli ma się dostęp do tak rozbudowanych narzędzi, to dlaczego z nich nie korzystać?

 

Na przykład gdybym uznał każdego użytkownika za "aktora" i przy pomocy JS każdy z nich wykonywałby jakieś zadania, a potem przesyłał wyniki do serwerów z PHP, a te serwery komunikowały by się miedzy sobą?

Jeśli chciałbyś tak przerzucić część funkcjonalności aplikacji na stronę klienta, to mogłoby to mieć sens. Tyle, że musiałbyś zadbać o to, aby serwer i klient miały identyczny sposób komunikowania się z nielokalnymi aktorami. Czyli np. napisać całość w js. Bardzo fajne w aktorach jest to, że bez problemu możesz wprowadzić do nich 'przejrzystość lokalizacji' (location transparency). To jest komunikowanie się z lokalnymi aktorami w ten sam sposób co będącymi na zupełnie innej maszynie. Możesz nawet nie wiedzieć, gdzie ten aktor się fizycznie znajduje.

[derasuito]

Miło się czyta takie artyuły . (y)