23 kwietnia 2009

Erlang, OTP, współbieżność, funkcyjność i rozproszenie aplikacji

O języku Erlang słyszymy przeróżne żarty, czytamy posty i co ciekawe znajdujemy nawet nieliczne w kraju oferty pracy. A tak na prawdę to słowa Erlang się boimy :-) Bo byćmoże posiada germańską naleciałość fonetyczną. Całkiem możliwe, że zapis kodu jest magiczny i przyzwyczajeni jesteśmy od szkoły średniej do zapisów typu:
"function ...() ... if {...} elseif {...} else {...} ... return ..."

Dodatkowo jeśli coś jest skomplikowane na pierwszy rzut oka i wyszukiwarka nie pisze słodkich ciekawostek o tym, że warto też to czasami zlewamy. Cóż, wiem to po sobie i znajomych, którzy brną coraz dalej w różne takie powszechne (czytaj komercyjne) trendy. Pochwalam zarazem wszystkich wytrwałych łowców historycznych i zagadkowych języków programowania tudzież udziwnionych rozwiązań t.j. LISP, Prolog oraz święty Erlang :-)





Na dzień dzisiejszy wydajność aplikacji (wykluczając rozwiązania google, ibm, oracle, amazon, częściowo facebook i pewnie kilka innych posiadających chmury obliczeniowe + gridy) jest uzyskiwana dzięki serwerom www, które dzięki interpretowaniu skryptów w profilowanych wątkach Fastcgi generują kod XML, HTML lub inny strumień informacji przy pomocy pipeline (lecz nie tylko) do przeglądarki klienta. Dość powszechny, uniwersalny i wydajny sposób, który posiada bardzo namacalne granice skalowalności.
Oczywiście ilość dostępnych maszyn (coraz częściej wirtualnych) oraz procesorów w tym wszelkich pamięci RAM zawsze będzie znacząca. Dodatkowo serwery cachujące typu memcache, moduły typu apc, etc zawsze się przydają. No tak baza danych master i slavy, których synchronizacji lub jeszcze lepiej replikacji pilnować, bo najlepsze jajca będą, jak kopie rekordów będą miały inne identyfikatory lub jak nagle slavy się oburzą i całe obciążenie spadnie na mastera. Może się też okazać, że lubimy NFS, sieciowe systemy plików lub nietypowe systemy plików w naszej aplikacji, które obciążają nasz serwerek i load w granicach 66.6 nas nieco dziwi. Praca administratora przy skalowaniu, profilowaniu też jest kosztowna i należy ją wrzucić do całkowitego rachunku ... to takie typowe założenia.

A co będzie jeśli to wszystko olejemy i użyjemy języka Erlang ?!


Wiadomo musimy nabyć odpowiednią wprawę, zrezygnować z typowych rozwiązań, nauczyć się kilku poleceń Eshell i posiadać marzenia :-) bo tylko One nas uratują, hahahahaaaa :-)
Weźmy pod uwagę, że w Erlangu każdy funkcjonalny kawałek kodu działa jako specjalny atomowy proces Erlanga, do tego dodam, że takich procesów można stworzyć nawet na bardzo słabym procesorze setki tysięcy. Ponadto dodam, że każdy proces z każdym może wymieniać komunikaty, co daje rozproszone podejmowanie decyzji i prawdziwie wielowątkową obsługę zdarzeń. Nie skłamię, jeśli napiszę, że język został ochrzczony w zastosowaniach dość wymagających i krytycznych czasowo tzn. w telekomunikacji. Służy(ł) do obsługi central oraz przełączników telekomunikacyjnych, gdzie raz uruchomiona aplikacja nie była wyłączana przez wiele lat i procesy w niej działające stale wykonywały swoje zadania. Mało tego, to może napiszę coś zabawniejszego, bo języku Erlang nie przejmujesz się błędami. Nie jest to bynajmniej parodia znanych nam powszechnie języków programowania, lecz ucieczka w stronę pisania bardzo wymagających aplikacji. Zarówno skupienie się na tym co się dzieje w procesach aplikacji, jak i odciążenie programisty stałym poprawianiem błędów swoich i cuchych. Jasne, że nie da się tego uniknąć, ale co powiecie na to, że jeśli kawałek kodu pada z powodu błędu to w tym czasie powołuje do życia instancje (swój klon), który zajmuje się dalej zadaniem. Dopieprzyć warto czymś, o czym wiele rozwiązań może tylko pomarzyć, czyli podmiana kodu w locie :-) Oczywiście administratorzy nie odniosą kolejnej klęski podczas klastrowania aplikacji, bo procesy Erlanga widzą się na maszynch, które posiadają połączenie sieciowe (rozpoznają się po nazwach). Dodajemy kolejny serwer uruchamiamy środowisko Erlanga i aplikacje, które widzą działające procesy na pozostałych połączonych maszynach.

Dodam, że firma Ericsson stosuje rozwiązania bazujące na tym języku od ponad 20-tu lat. Firma Google natomiast oparła swój meta komunikator GoogleTalk w oparciu o ejabberd, jabber (XMPP)serwer oraz klient do budowy dowolnych komunikatorów internetowych napisany i działający całkowicie w Erlangu. Tyle tytułem wstępu, resztę pozostawiam sprawnym obserwatorom i odkrywcom, którzy zechcą przejrzeć kilka prezentacji na temat języka Erlang i wyciągnąć pożyteczne wnioski.

By nie nawijać tylko o teorii pewnego dnia usiadłem sobie do kilku przykładów i zechciałem się nimi z Wami podzielić. Oto one:


Dodatkowe linki:
Referat - Erlang

Jabber we własnej domenie - uruchamiamy serwer

ejabberd we FreeBSD

All you wanted to know about the Erlang HiPE compile (but might have been afraid to ask)

Porównanie Erlang HiPE do Java 6 server

Erlang in Practice Episode 1: Sending and Receiving Chat Messages

Erlang in Practice Episode 3: Distributing Clients In A Multi-node Environment

Erlang in Practice Episode 5: Unit Testing with EUnit


Erlang community site Planet Erlang

Wtyczka do Eclipse dla programistów Erlanga

Introduction to the Open Telecom Platform

Erlang: Open Telecom Platform (Parts)

Erlang-Open-Telecom-Platform.ppt

http://www.slideshare.net/dennisbyrne/the-erlang-programming-language-presentation

http://www.slideshare.net/btedev/erlang-concurrency-presentation

Prezentacja oraz projekt łamania haseł na podstawie MD5 wykonany w Erlangu

http://www.slideshare.net/btedev/erlang-concurrency-presentation

http://github.com/btedev/erlang_md5crack/tree/master

http://github.com/btedev
Autor: o
Etykiety: , ,

1 komentarz:

Anonimowy pisze...

Dorzucę też coś od siebie Erlang is good ... MapReduce w Erlangu to po prostu codzienność :->

19 czerwca 2009 18:27

Prześlij komentarz

Subskrybuj: Komentarze do posta (Atom)