Cześć!

Zabieram się za napisanie serwera sieci rozproszonej. Nigdy nie pisałem tak zaawansowanego projektu, w związku z tym chciałem prosić o zweryfikowanie mojego pomysłu przez osoby bardziej doświadczone. Serwer nie będzie pisany w PHP, więc dlatego zamieściłem go w tej kategorii ('Miejsca na dyskusje nie pasujące do innych for.").

Sieć ma być dostępna przez zwykłe połączenia socketowe oraz WebSocketowe (z przeglądarek). Każdy klient łączy się z jednym z losowo wybranym serwerem. Serwerów jest kilka. Wszystkie serwery mają nawiązane połączenie między sobą, do wymiany wiadomości.

Dodatkowo każdy serwer jest połączony z bazą danych w chmurze, która z perspektywy systemu jest jednym bytem wspólnym dla wszystkich serwerów.

Chciałem, aby serwery odbierały wiadomości od klientów i innych serwerów w postaci wiadomości podobnych do protokołu HTTP. W każdej wiadomości byłby nazwa zadania do wykonania (np. "dodaj produkt do koszyka") oraz dane, z którymi zostaje wywołane zapytanie (np. identyfikator produktu).

Myślałem jak rozplanować zarządzanie takim przepływam wiadomości. Chciałbym, aby serwer (ze względów wydajnościowych) był oparty o zdarzenia. I tak: istniałaby jedna główna kolejka, w której znajdowałyby się odebrane wiadomości do wykonania. Dodatkowo byłyby inne kolejki, służące do wysyłania zapytań do bazy danych, serwera plików lub jeszcze innych źródeł, jeśli przyjdzie taka potrzeba. Każda kolejka będzie osobnym wątkiem, którego zadaniem byłoby branie najstarszej wiadomości (lub operacji do wykonania) z listy oczekujących i wykonanie jej. Miałoby to działać jak hardware komputera: główna kolejka do procesora i pozostałe do urządzeń wej/wyj.

Gdyby jakieś zadanie wymagałoby wykonania zapytania do bazy danych lub zewnętrznego serwera, to nastąpiłoby jego "spauzowanie". Odpowiednia żądanie trafiałoby do kolejki bazy danych lub kolejki komunikacji z zewnętrznym serwerem. Dopiero gdyby takie żądanie zostałoby wykonane i zostały zwrócone jakieś dane, to zadanie trafiałoby z powrotem do głównej kolejki wiadomości, i gdy nadeszłaby jego kolej zostałoby ono "odpauzowane" od stosownego miejsca.
Po spauzowaniu zadania wątek głównej kolejki wziąłby kolejne zadanie z listy i zacząłby je wykonywać.

Co myślicie o tym rozwiązaniu. Jest ono poprawne? A jeśli nie to co należałoby zmienić? Gdzie widzicie słabe punkty?

Z góry dziękuję za odpowiedzi!

Najsłabszym punktem jest zdecydowanie brak jakichkolwiek ustaleń i celów. Napisałeś, że chcesz stworzyć sieć rozproszoną, która będzie utrzymywać połączenia socketowe i tworzyć kolejki do różnych zadań, które będą rosnąć w razie potrzeby. Jednym zdaniem jest to masło maślane.

Ale, aby rzucić na ten temat jakieś światło, to powiem tyle - sieci rozproszone nie powstają sobie od tak na życzenie. Każdy system rozproszony jest dobrze przemyślany. Często zaczyna się od jednego, monolitycznego systemu, który później po "urośnięciu" rozbija się na mniejsze systemy. Jest to temat rzeka, jedyne co Ci mogę zaproponować, to poczytanie o WebSerwisach i MicroSerwisach.

Ty musisz zrozumieć jedno - dopóki nie będziesz miał konkretnej wizji systemu, to będziesz się zastanawiał jak stworzyć samolot pasażerski, który będzie jeździł po torach kolejowych i rozwoził kanapki pracownikom stacji PKP. Stworzysz wtedy monstrum, które nie będzie miało żadnego sensu ani odniesienia do rzeczywistości.

Nie ma sensu wymyślać koła na nowo, wystarczy poczytać. Pierwsze z brzegu wyniki wyszukiwania dla haseł
"architektura serwerów rozproszonych" oraz "rozproszone systemy informatyczne":

http://icis.pcz.czest.pl/~roman/mat_dyd/pr...roc/roz1_3.html
http://wazniak.mimuw.edu.pl/index.php?titl...emy_rozproszone

Jak poprzednicy ujęli - trzeba to dobrze rozplanować. Sama idea jest za bardzo uniwersalna, z doświadczenia z websocketami mogę ci powiedzieć że całkiem dobrze kombinujesz, tylko ta baza danych w "chmurze" to trochę frazes. Ale zgadza się, pomiędzy takimi serwerami websocketów potrzebujesz jakiegoś pomostu, który by umożliwiał komunikacje wszystkich pozostałych serwerów. Taki pomost również musi być niezawodny i wydajny, bo nawet na najlepszej maszynie w końcu wysycisz całe łącze. Tak samo tworzenie zadań do wykonania musi być rozproszone, każdy worker który wykonuje jakieś zadanie, musi być rozproszony. Generalnie wszystko czego chcesz użyć musi zarówno umożliwiać rozproszenie, jak i być rozproszone, w przeciwnym wypadku trafisz na SPOF i błąd jednej maszyny wywali całą infrastrukturę.

Nie jesteś w sumie pierwszy który się pyta o websockety, jest kilka wątków na forum w których poruszałem jakich bibliotek można do tego użyć.

Ja proponowałbym rozpatrzenie niezależnych serwisów, które komunikują się ze sobą przez API - i każdy z tych serwisów musi być niezależny, tj. każdy serwis może być stworzony w innej technologii (jeden w Ruby, drugi w Javie, trzeci w .NET, czwarty w PHP) i mieć swoją osobną bazę danych. I cała komunikacja przebiega przez API.

Tylko musiałbyś zidentyfikować "niezależne moduły/części" systemu.

Prosty przykład: Masz system, który obsługuje księgowość. Są w nim różne moduły, z czego jeden do zarządzania dokumentami. Jest to całkowicie niezależny system, który jedyne co robi to zapisuje dokumenty w swojej bazie (zwracając wtedy ID takiego dokumentu), a także wyświetla dokumenty (gdy przekaże się ich ID).

I teraz sobie wyobraź, że ten serwis do zarządzania dokumentami jest wykorzystywany przez inne moduły. Przypuśćmy, że powstał moduł do fakturowania - ten moduł chce zapisać jakąś fakturę klienta XYZ. W tym wypadku generuje sobie dokument, następnie wysyła go do modułu zarządzania dokumentów, a moduł zarządzania dokumentami zapisuje go w swojej bazie i zwraca modułowi fakturowania ID dokumentu.

I później za każdym razem, gdy moduł fakturowania będzie chciał wyświetlić komuś fakturę klienta XYZ (w końcu ma jego ID, dostał je gdy wysyłał dokument), wtedy będzie wysyłał zapytanie do modułu zarządzania dokumentów (który jest na innym serwerze) i który zwróci dany dokument. A połączenia między serwerami to już Twoja sprawa, czasem wystarczy zwykłe żądanie HTTP, innym razem można nawiązać połączenie socketowe.

Poza tym, przypuśćmy, że każdy klient ma swój profil i zdjęcia profilowe - do tego także można wykorzystać moduł do zarządzania plikami. Z serwera/modułu zarządzającym profilami można "rozmawiać" z serwisem do zarządzania dokumentami i zapisywać/pobierać grafikę. W końcu dla serwera od zarządzania dokumentami nie ma żadnego znaczenia, czy pobierasz plik PDF, JPG, czy pliku ZIP, który ma 1 GB.

To bardzo prosty przykład - jak widzisz, potrzebna jest koncepcja, potrzebny jest plan. Systemy rozproszone muszą być dobrze przemyślane. Mnie na przykład zastanawia dlaczego chcesz aby wszystkie serwery ze sobą były na stałe połączone websocketami. Po co? Na co? Jaki ma to sens? Jaki sens ma też jedna wspólna baza danych dla wszystkich serwerów?
Wydaje mi się, że chcesz zrobić system rozproszony, jednak nawyki z tworzenia monolitycznych systemów biorą górę.