Architektura Micro vs Monolithic Server

Aktualnie pracujemy nad naszym nowym produktem / projektem, jest to aplikacja klient-serwer skierowana do określonych przedsiębiorstw przemysłowych / usługowych. Budujemy serwer (tylko język C i Linux) z niestandardowym protokołem nad TCP z interfejsem Java. Jesteśmy zaangażowani w około 20% prac związanych z kodowaniem i mamy do czynienia z sytuacją, w której musimy wybierać pomiędzy Micro lub Monolityczną architekturą jądra.

Wiem, że Micro vs. Monolithic ma zwykle związek z architekturą jądra, ale mówimy konkretnie o serwerach.

Dlaczego serwer niestandardowy, a nie coś istniejącego?

• Nasze potrzeby dotyczące interfejsu użytkownika są znaczące i bardzo dynamiczne, dlatego rozwiązania oparte na przeglądarce internetowej / przeglądarce internetowej nie były odpowiednie.
• Przetwarzanie danych statystycznych jest znaczące po stronie klienta, dlatego też przeglądarki niewiele pomogły. (Oczywiście moglibyśmy przetwarzać dane po stronie serwera i przekazywać przetworzone dane klientowi, ale oznaczałoby to duże obciążenie serwera i marnowanie zasobów klienta).
• Co więcej, dzięki co najmniej trzem technologiom (JS / HTML / CSS) do zarządzania nawet pojedynczym wydarzeniem sprawia, że ​​całe doświadczenie jak zamiatanie domu w środku burzy pustynnej - zamiatasz go n-razy, kurz gromadzi się n + 1 razy.

Co z serwerem Micro i Monolithic? Co ty mówisz?

Rozważ następujące (hipotetyczne) żądanie klienta:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Po otrzymaniu takiego żądania serwer zazwyczaj to robi (ignorujemy techniki współbieżności, takie jak wątek i widelce dla uproszczenia):

• Analizuj ciąg żądania
• Zidentyfikuj akcję (pobierz HistoricDataSets LIMIT Year (2010)w naszym przypadku)
• Wejdź w interakcję z warstwą utrwalającą (np. Oracle, powiedzmy w naszym przykładzie) i pobierz dane.

• Sformatuj dane zgodnie z protokołem. Dawny:

  id odpowiedzi: 123
  sukces: prawda
  tekst odpowiedzi: DataSets

• Odpowiedz klientowi z tak sformatowanymi danymi.

Nazywamy to Monolitycznym Serwerem (podobnie jak monolityczne jądro, w którym wszystkie działania systemu operacyjnego są wykonywane w przestrzeni jądra).

Ponownie rozważ to samo żądanie, tym razem po otrzymaniu serwera (przyjęliśmy tylko pamięć współdzieloną jako IPC, ponownie dla uproszczenia):

• Umieszcza żądanie w pamięci współużytkowanej dla Parserprocesu
• ParserAnalizuje ciąg, określa zadania i kieruje Executionerproces do wykonania zadania.
• ExecutionerNastępnie przekazuje dane do Fomatterprocesu, który po formatowania danych w ciąg protokół wraca do serwera.
• Serwer wysyła go do klienta (odpowiedź).

Oczywiście, zamiast Parser, Executioneri Formatterto mogło być jedno ale odrębny proces. Nazywamy to Micro Server (podobnie jak mikro-jądro, które wymaga minimalnego minimum). Serwer skutecznie nasłuchuje i odpowiada, podczas gdy wszystkie kroki są wykonywane przez różne procesy.

Który wybrać? Jesteśmy zmieszani! Podczas gdy serwery monolityczne są wypróbowywane i testowane (większość serwerów HTTP?) I są łatwiejsze do zaprogramowania i całkiem dobrze radzą sobie z współbieżnością. Mikro serwery, na pierwszy rzut oka, wydają się szybkie i zgodne z zasadą UNIX jednego programu do wykonywania jednego zadania, ale są również skomplikowane w rozwoju, szczególnie. mając na uwadze współbieżność.

Pytanie (pytania)
- Jakie są (być może) zalety i wady każdego podejścia?
- Kiedy użyć którego? (Można to również zinterpretować jako ogólne pytanie: kiedy używać IPC?)
- Jeśli wybierzesz Mikro-jądro, jakie funkcje muszą być częścią rdzenia-serwera, a co nie?

Podobne / pokrewne pytania

• Niebezpieczeństwa związane z ogromnym monolitycznym zastosowaniem
• Zewnętrzna wbudowana przeglądarka Vs (styczna)
• Porady dotyczące konwertowania aplikacji monolitycznej na wielowątkową (styczną)

• Nasi potencjalni klienci można podzielić na dwie kategorie:
  • Duże: około 1700 - 2000 żądań na minutę
  • Mały: około 650 - 700 żądań na minutę
• Można założyć, że objętość danych na cykl żądań (żądanie i kolejna odpowiedź) jest normalnie dystrybuowana ze średnią ~ 1,20 MB, a co gorsza około 250-300 MB.
• Koncepcja produktu jest stosunkowo nowa, ale może wpływać na podstawowe operacje, dlatego oczekujemy, że budżety klientów będą elastyczne dopiero po pewnym opóźnieniu (9-12 miesięcy) po wdrożeniu, co ogranicza ilość sprzętu, na którą klient będzie skłonny popełnić esp. te małe.
• Każdy klient będzie miał swój własny stos klient-serwer. Serwer będzie działał na sprzęcie klienta zarządzanym przez zespół klienta, a klienci będą wdrażani na komputerach funkcjonalnych pracowników
• Zdalne aktualizacje aplikacji klienckich i serwerowych są koniecznością
• PUSHUsługi serwera w czasie rzeczywistym mogą być „wysoce” pożądane, jeśli produkt kliknie!

Czasami ekonomia rządzi znacznie bardziej krytyczną odpowiedzią niż podstawowa teoria stojąca za wyborami. Najważniejsze jest to, że jeśli patrzysz na coś „rozległego” w twoim przypadku, w którym aplikacja wymaga naprawdę trudnego wdrożenia - im mniejsza liczba wymyślonych przez siebie kół, tym lepiej. Jeśli to działa, nie obchodzi mnie, czy jest monolityczny czy mikro; jeśli nie, to też mnie to nie obchodzi!

Może być prawdą, że bardzo konwencjonalne aplikacje oparte na stronach internetowych mogą nie być dla Ciebie - ale musisz spojrzeć nieco szerzej i zobaczyć, że możesz użyć rzeczy gotowych do użycia, a następnie ewoluować, aby sprawdzić, czy możesz zastąpić ten element czymś lepszy. W ten sposób nie tylko zaoszczędzisz czas na pierwszym miejscu, ale także poprawisz zrozumienie tego, co naprawdę ważne w prawdziwym życiu. Oto kilka wskazówek, które możesz rozważyć.

1. Jeśli naprawdę potrzebujesz bardzo wysokiej skalowalności, zastanów się, w jaki sposób Twoje serwery podzielą zadanie, a nie dzielą liczby tak szybko, jak to możliwe. W końcu będziesz mieć obciążenie, którego jeden serwer nie jest w stanie podjąć, nawet jeśli Intel tworzy najszybszy procesor na ziemi, a klient jest gotowy zapłacić! Dlatego routing żądań i równoważenie obciążenia są ważniejsze niż wydajność samego protokołu.

2. HTTP jest nadal najlepszy - jeśli potrzebujesz skalować. (Możesz także łatwo kupić moduły równoważące obciążenie, jeśli go używasz). Niestandardowy protokół wymaga niestandardowych ustaleń.

3. HTTP nie oznacza, że ​​musisz ominąć HTML, w ogóle skrypt Java. Nie oznacza to nawet, że musisz mieć zwykły serwer Apache i przeglądarkę internetową. Możesz używać HTTP między dwoma niestandardowymi klientami i elementami, takimi jak serwer AOL lub lighthttpd, które mogą być używane jako biblioteka, jeśli komunikacja nie jest ogromnym transferem danych. Możesz także używać SOAP po obu stronach z zestawami narzędzi, takimi jak gSOAP .

4. Nawet jeśli HTTP zdecydowanie nie pasuje do rachunku, rozważ coś takiego jak BEEP , który pomoże Ci zwiększyć wydajność. Alternatywnie istnieje wiele sprawdzonych mechanizmów RPC, RMI.

5. Spróbuj przekonać się, że możesz wykonać maksimum pracy, wykonując równoległe przetwarzanie w zapleczu, a serwery są pytane tylko po zakończeniu pracy. Jeśli to działa - istnieją frameworki takie jak MPI lub istnieje wiele innych zestawów narzędzi do rozproszonego przetwarzania danych, które mogą być pomocne.

6. Wreszcie, chociaż mogę nie być w stanie poznać dokładnych potrzeb, ale może być konieczne albo rozprowadzenie dużej ilości danych, albo wykonanie dużej ilości obliczeń, jeśli potrzebujesz obu - nadal istnieje pewna podstawowa nieefektywność architektoniczna.

Dla mnie tworzenie nowego protokołu i tworzenie nowej struktury serwera to podwójny eksperyment, którego nie powinieneś robić razem. Jeśli twoje stawki są tak wysokie, najpierw powinieneś spróbować eksperymentować z istniejącymi narzędziami, aby zobaczyć granice dotychczasowych działań - tylko wtedy poznasz prawdziwe wyzwania.

W badaniach systemów rozproszonych osiągnięto znacznie więcej niż tylko aplikacje internetowe. Więc powinieneś to zbadać.

Dipan.

Wydaje mi się to bardzo akademickie. I szczerze mówiąc, uważam, że drugie podejście jest równie monolityczne. To jest tak daleko, jak powinieneś:

1. Przeanalizuj żądanie
2. Obsługuj żądanie

Moduł obsługi żądań wybrany na podstawie parametrów żądania powinien obejmować wszystkie aspekty obsługi żądania. To, czy moduł obsługi faktycznie wykonuje zapytania w magazynie danych i czy używa standardowego formatowania do zwrócenia danych, nie ma znaczenia dla powyższej warstwy. W rzeczywistości prawdopodobnie tak się stanie, ale nie ma żadnej wartości, aby zakładać o tym.

1. Jądro monolityczne jest znacznie starsze niż Microkernel . Jest używany w Uniksie. podczas gdy Idea mikrojądra pojawiła się pod koniec lat 80 .

2. przykład OS z monolitycznymi jądrami to UNIX, LINUX, natomiast OS z Microkernel to QNX, L4, HURD , początkowo Mach (nie Mac OS X) później przekształci się w jądro hybrydowe, nawet MINIX nie jest czystym jądrem, ponieważ sterownik urządzenia jest skompilowany jako część jądra.

3. Jądro monolityczne jest szybsze niż mikrojądro . podczas gdy pierwszy mikrojądro Mach jest o 50% wolniejszy niż jądro monolityczne, podczas gdy późniejsza wersja jak L4 tylko o 2% lub 4% wolniej niż jądro monolityczne .

4. Jądro monolityczne jest na ogół nieporęczne . podczas gdy czyste monolityczne jądro musi być małe, a nawet zmieścić się w pamięci podręcznej pierwszego poziomu procesora (mikrojądra pierwszej generacji).

5. w Monolitycznym sterowniku urządzenia jądra znajduje się w przestrzeni jądra . natomiast w sterowniku Microkernel znajduje się w przestrzeni użytkownika .

6. ponieważ sterownik urządzenia znajduje się w przestrzeni jądra, sprawia, że ​​monolityczne jądro jest mniej bezpieczne niż mikrojądro. (Awaria sterownika może prowadzić do awarii), podczas gdy mikrokernele są bardziej bezpieczne niż monolityczne jądro, stąd używane w niektórych urządzeniach wojskowych.

7. Jądra monolityczne używają sygnałów i gniazd w celu zapewnienia IPC, podczas gdy podejście mikrojądra wykorzystuje kolejki komunikatów . 1 gen mikrojądra źle zaimplementował IPC, więc działały wolno przy przełączaniu kontekstu.

8. dodanie nowej funkcji do systemu monolitycznego oznacza rekompilację całego jądra, natomiast można dodawać nową funkcję lub łatki bez ponownej kompilacji .