Budowanie odpornej na uszkodzenia, miękkiej aplikacji internetowej w czasie rzeczywistym z Erlang/OTP

Question

Chciałbym zbudować odporną na uszkodzenia, miękką aplikację internetową do przechowywania pizzy w czasie rzeczywistym. Powinno to ułatwić sklepowi pizzerię akceptowanie połączeń telefonicznych od klientów, składanie ich jako zamówień do systemu (za pośrednictwem klienta internetowego CRM) i pomoc dyspozytorom w przydzielaniu kierowców do dostarczania zamówień.

Cele te nie są niczym niezwykłym, ale chciałbym, aby usługa była dostępna 24 godziny na dobę, 7 dni w tygodniu, aby była odporna na uszkodzenia. Ponadto chciałbym, aby działało bardzo szybko i było bardzo elastyczne.

Poniżej znajduje się bardzo prosty widok architektury dla takiej aplikacji.

Problem polega na tym, że nie wiem, jak korzystać ze wszystkich dobroci Erlang/OTP, aby aplikacja bardzo czuły i odporne na uszkodzenia.

Oto moje pytania:

1. Które elementy systemu powinny być replikowane w celu zapewnienia odporności na uszkodzenia i jak należy to zrobić? Wiem, że mogę przechowywać status każdego pojazdu (współrzędne, przypisane zamówienia itp.) W zreplikowanej bazie danych Mnesia. Czy to właściwa droga?
2. Które usługi przechowywania danych powinny być konwencjonalne oparte na języku SQL (np. Na podstawie boss_db), a które należy wykonać w systemie Mnesia, aby zapewnić bardzo szybką reakcję? Czy można używać konwencjonalnej bazy danych SQL do przechowywania rekordów klientów i historii w tak odpornej na błędy i wysoce responsywnej aplikacji?
3. Czy muszę próbować przechowywać wszystkie dane dotyczące wszystkich usług (klientów, stanu pojazdów itp.) W pamięci RAM, aby aplikacja była szybko reagująca?
4. Czy powinienem przechowywać trwałe dane pojazdu (identyfikator, pojemność itp.) W konwencjonalnej bazie danych SQL i przechowywać dane w czasie rzeczywistym (współrzędne, przypisane zamówienia, zamówienia w bagażniku itd.) W bazie danych Mnesia, aby aplikacja bardziej responsywna w czasie rzeczywistym?

Answer 1

Po pierwsze, jest to duże pytanie, ale spróbuję to zepsuć. Przyjrzyjmy się faktom. Jest to serwis internetowy. Co oznacza, że ​​mamy następujące warstwy: Web Server, Middle ware application, a następnie Data Storage. W większości aplikacji o wysokiej dostępności warstwa magazynu danych musi mieć nadmiarowość przez replication, a ładowanie jest zarządzane przez Distribution. W większości aplikacji rzeczywistych nie ma potrzeby przechowywania czegokolwiek w pamięci RAM, chyba że aplikacja jest rzeczywiście w czasie rzeczywistym, na przykład Multi-player Game Server lub A telecom Switch. Tak więc, twój rodzaj aplikacji, w tym przypadku tak naprawdę, nie trzeba przechowywania pamięci RAM (może jakiś rodzaj caching tu i tam, jak zobaczymy.)
Teraz tego rodzaju aplikacji, wymaga różnego rodzaju danych, informacje, które nie mogą mieć tej samej postaci w tym samym czasie, dlatego użycie RDMS zmusi cię do uporządkowania wszystkiego w ten sam sposób. Moja sugestia jest taka, że ​​uczysz się używać każdego z nich, ponieważ są one dobrze modelowane pod względem złożoności w świecie rzeczywistym. Więcej informacji o każdym rodzaju pamięci można znaleźć w tej wersji: pdf. Sugeruję, abyś użył Couch base server, dzięki czemu twoje dane będą po prostu JSON documents, schemaless i mogą być ewoluowane wraz z rozwojem aplikacji. Zapewnia dystrybucję i replikację, tak jak każda aplikacja kiedykolwiek tego potrzebowała. Możesz dodawać serwery lub usuwać serwery w czasie wykonywania, a cały system po prostu ponownie się równoważą. Jest on również wyposażony w buforowanie dla wersji memcached, więc dla części pamięci, o której mówisz, buforowanie zrobi wszystko za Ciebie.

Po przechowywaniu porozmawiajmy o środkowym naczyniu. Chcę mówić o serwerze sieciowym jako o części middleware. Będziesz potrzebował bardzo stabilnego serwera sieci Web, w zależności od obciążenia i bycia, który chcesz użyć Erlang, sugeruję yaws web server i nauczyć się robić z nim RESTFUL services używając appmods. Używanie serwerów proxy w infroncie klastra serwerów sieciowych może pomóc w zarządzaniu obciążeniem. Co najmniej istnieje kilka sposobów na równoważenie obciążenia infront serwerów internetowych. Następnie będziesz potrzebował aplikacji OTP. Aplikacja OTP nie musi mieć numeru gen_servers. Ale jak się dowiesz, odkryjesz, gdzie naprawdę potrzebujesz równoległości lub gdzie potrzebujesz kodu sekwencyjnego. Jest jednak niepokojące, że chcesz użyć czegoś, czego jeszcze nie opanowałeś. proszę postępować zgodnie z this web book i tym Orielly book, aby pomóc opanować wszystko na temat Erlang. Przydatne może okazać się wypróbowanie bibliotek serwera httpm Chicago Boss i Mochiweb lub .

Inną rzeczą, o której powinienem wspomnieć o robieniu tego w Erlang, jest to, że musisz opanować struktury danych i efektywny sposób pracy z nimi. Zły wybór struktur danych może powodować problemy. Testuj i testuj wszystko na każdym etapie. Użyj wszędzie, gdzie to możliwe, i sprawdzaj zużycie pamięci na każdym etapie. Jest tylko wiele do powiedzenia na temat tego pytania, ale miejmy nadzieję, że inni również zamieszą swoje zdanie.

Answer 2

włamać się do tej gry: https://github.com/synrc/games wszystko w czasie rzeczywistym, niskie opóźnienie, pub/sub, bazy danych, pytania architektoniczne są tam, napisane jako state-of-the-art oprogramowania. Sugeruję użycie gen_fsm do kontrolowania stanów w twojej aplikacji, tak jak robią to "w porządku" przełożeni. riak jest zintegrowany z biblioteką kvs, która ma również dobre wsparcie dla aktualizacji społecznościowych. N2o wybrał serwer kowbojski, moim zdaniem najlepszy serwer wokół. http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/