Moja konfiguracja serwera dla mocno używanego API

Wkrótce kupię kilka serwerów dla aplikacji, którą zamierzam uruchomić, ale mam obawy dotyczące mojej konfiguracji. Doceniam wszelkie opinie, które otrzymuję.

Mam aplikację, która będzie korzystać z napisanego przeze mnie interfejsu API. Inni użytkownicy / programiści również będą korzystać z tego interfejsu API. Serwer API odbierze żądania i przekaże je serwerom roboczym. Interfejs API przechowuje tylko mysql db żądań do celów logowania, uwierzytelnienia i ograniczenia prędkości.

Każdy serwer roboczy wykonuje inną pracę, a w przyszłości w celu skalowania dodam więcej serwerów roboczych, aby były dostępne do wykonywania zadań. Plik konfiguracyjny interfejsu API zostanie poddany edycji w celu uwzględnienia nowych serwerów roboczych. Serwery robocze wykonają pewne przetwarzanie, a niektóre zapiszą ścieżkę do obrazu do lokalnej bazy danych, która zostanie później pobrana przez interfejs API do wyświetlenia w mojej aplikacji, niektóre zwrócą ciągi wyników procesu i zapiszą ją w lokalnej bazie danych .

Czy ta konfiguracja wygląda dla Ciebie wydajnie? Czy istnieje lepszy sposób na restrukturyzację? Jakie problemy powinienem wziąć pod uwagę? Zobacz obraz poniżej, mam nadzieję, że to pomoże w zrozumieniu.

Wyższa dostępność

Jak wspomina Chris, twój serwer API jest pojedynczym punktem awarii w twoim układzie. To, co konfigurujesz, to infrastruktura kolejkowania wiadomości, coś, co wiele osób zaimplementowało wcześniej.

Kontynuuj tą samą ścieżką

Wspominasz o otrzymywaniu żądań na serwerze API i wstawiasz zadanie do bazy danych MySQL działającej na każdym serwerze. Jeśli chcesz kontynuować tę ścieżkę, sugeruję usunięcie warstwy serwera API i zaprojektowanie Workerów tak, aby akceptowały polecenia bezpośrednio od użytkowników API. Możesz użyć czegoś tak prostego jak okrągły DNS, aby dystrybuować każde połączenie użytkownika interfejsu API bezpośrednio do jednego z dostępnych węzłów roboczych (i spróbuj ponownie, jeśli połączenie się nie powiedzie).

Użyj serwera kolejki wiadomości

Bardziej niezawodne infrastruktury kolejkowania wiadomości wykorzystują oprogramowanie zaprojektowane do tego celu, takie jak ActiveMQ . Możesz użyć interfejsu API RESTful ActiveMQ do akceptowania żądań POST od użytkowników interfejsu API, a bezczynni pracownicy mogą uzyskać kolejną wiadomość w kolejce. Jest to jednak prawdopodobnie przesada w stosunku do twoich potrzeb - jest zaprojektowany z myślą o opóźnieniu, szybkości i milionach wiadomości na sekundę.

Użyj Zookeepera

Jako środek, możesz spojrzeć na Zookeepera , nawet jeśli nie jest to konkretnie serwer kolejki wiadomości. Używamy w $ work do tego właśnie celu. Mamy zestaw trzech serwerów (analogicznych do serwera API), które obsługują oprogramowanie serwera Zookeeper i mamy interfejs internetowy do obsługi żądań od użytkowników i aplikacji. Interfejs WWW, a także połączenie zaplecza Zookeeper z pracownikami, mają moduł równoważenia obciążenia, aby upewnić się, że będziemy kontynuować przetwarzanie kolejki, nawet jeśli serwer nie działa z powodu konserwacji. Po zakończeniu pracy pracownik informuje klaster Zookeeper o zakończeniu zadania. Jeśli pracownik umrze, to zadanie zostanie wysłane do innej pracy do wykonania.

Inne obawy

• Upewnij się, że zadania zostały ukończone, jeśli pracownik nie odpowiada
• Skąd interfejs API będzie wiedział, że zadanie jest ukończone i odzyskać je z bazy danych pracownika?
• Spróbuj zmniejszyć złożoność. Czy potrzebujesz niezależnego serwera MySQL na każdym węźle roboczym, czy może oni rozmawiać z serwerem MySQL (lub replikowanym klastrem MySQL) na serwerach API?
• Bezpieczeństwo. Czy ktoś może przesłać pracę? Czy istnieje uwierzytelnienie?
• Który pracownik powinien dostać następną pracę? Nie wspominasz, czy zadania mają zająć 10ms czy 1 godzinę. Jeśli są szybkie, należy usunąć warstwy, aby zmniejszyć opóźnienie. Jeśli są one powolne, należy bardzo uważać, aby upewnić się, że krótsze zapytania nie utkną za kilkoma długofalowymi.

Największym problemem, jaki widzę, jest brak planowania przełączania awaryjnego.

Twój serwer API jest dużym pojedynczym punktem awarii. Jeśli ulegnie awarii, nic nie będzie działać, nawet jeśli serwery robocze nadal będą działać. Ponadto w przypadku awarii serwera roboczego usługa świadczona przez ten serwer nie jest już dostępna.

Sugeruję, aby spojrzeć na projekt Linux Virtual Server ( http://www.linuxvirtualserver.org/ ), aby dowiedzieć się, jak działa równoważenie obciążenia i przełączanie awaryjne oraz aby dowiedzieć się, w jaki sposób mogą one przynieść korzyści Twojemu projektowi.

Istnieje wiele sposobów strukturyzacji systemu. Który sposób jest lepszy to subiektywne połączenie, na które najlepiej odpowiedzieć. Sugeruję, żebyś przeprowadził badania; rozważ kompromisy różnych metod. Jeśli potrzebujesz informacji na temat metody implantacji, prześlij nowe pytanie.