Twierdziłbym, że jest to bardziej kwestia ekonomiczna. Jest to jednak wezwanie do osądu, które inżynierowie powinni być w stanie wykonać. Dlatego odpowiadam.
Podzielę swoją odpowiedź na cztery części:
- Zarządzanie ryzykiem
- Strategie
- Koszty
- Intuicja
Zarządzanie ryzykiem
Czasami więc twój klient nie otrzymuje odpowiedzi z serwera. Zakładam, że nie dzieje się tak z powodu błędu programowego (w przeciwnym razie rozwiązaniem jest naprawa, więc zrób to). Zamiast tego musi to wynikać z sytuacji losowej, na którą nie masz wpływu ...
Ale nie poza twoją wiedzą. Musisz wiedzieć:
- Jak często to się zdarza.
- Jaki to ma wpływ.
Na przykład, jeśli awaria i ponowna próba zdarzają się tylko w około 2% przypadków, prawdopodobnie nie warto tego robić. Jeśli zdarzy się to w 80% przypadków, cóż ... zależy ...
Ile czasu musi czekać klient? A jak to przekłada się na koszty ... Widzisz, masz niewielkie opóźnienie w regularnej aplikacji, to chyba nie jest wielka sprawa. Jeśli jest to znaczące, a masz aplikację czasu rzeczywistego lub grę online, odstraszy to użytkowników i prawdopodobnie lepiej inwestować w więcej lub lepsze serwery. W przeciwnym razie prawdopodobnie możesz umieścić komunikat „ładowanie” lub „czekanie na serwer”. O ile opóźnienie nie jest naprawdę duże (rzędu dziesiątek sekund), może być zbyt duże nawet w przypadku zwykłej aplikacji.
Strategie
Jak powiedziałem powyżej, istnieje więcej niż jeden sposób rozwiązania tego problemu. Zakładam, że masz już implementację pętli try-fail-retry. Zobaczmy więc ...
- Umieść komunikat ładowania. Jest tani, pomaga utrzymać użytkownika.
- Zapytanie równoległe. Może być szybszy, nadal może zawieść. Będzie wymagał nadmiarowego serwera (może być kosztowny), zmarnuje czas serwera i ruch sieciowy.
- Zapytanie równoległe w celu ustalenia szybszego serwera i korzystania z niego odtąd. Może być szybszy, nadal może zawieść. Będzie wymagał nadmiarowego serwera (może być kosztowny), nie zmarnuje tyle czasu serwera i ruchu sieciowego.
Zauważ, że mówię, że nadal mogą się nie powieść. Jeśli założymy, że zapytanie do serwera ma 80% szansy na awarię, to równoległe zapytanie do dwóch serwerów ma 64% szansy na niepowodzenie. W związku z tym nadal możesz spróbować ponownie.
Dodatkową zaletą wyboru szybszego serwera i korzystania z niego jest to, że szybszy serwer jest mniej podatny na awarie z powodu problemów z siecią.
Co mi przypomina, jeśli możesz dowiedzieć się, dlaczego żądanie się nie powiedzie, zrób to. Pomoże ci to lepiej zarządzać sytuacją, nawet jeśli nie możesz zapobiec awariom. Na przykład, czy potrzebujesz większej prędkości transferu po stronie serwera?
Trochę więcej:
- Wdróż wiele serwerów na całym świecie i wybierz serwer według geolokalizacji.
- Wykonuj równoważenie obciążenia po stronie serwera (dedykowana maszyna przyjmie wszystkie żądania i przekaże je do serwerów, możesz mieć tam równoległość lub lepszą strategię równoważenia).
A kto powiedział, że musisz zrobić tylko jedną z nich? Możesz umieścić komunikat ładowania, wysłać zapytanie do wielu serwerów rozmieszczonych w folderze Wrold, aby wybrać szybciej i używać go tylko odtąd, po ponownym niepowodzeniu w pętli, a każdy z tych serwerów może być klastrem maszyn z równoważeniem obciążenia . Dlaczego nie? Cóż, kosztuje ...
Koszty
Istnieją cztery koszty:
- Koszt opracowania (zwykle bardzo tani)
- Koszt wdrożenia (zwykle wysoki)
- Koszt czasu wykonania (zależy od rodzaju aplikacji i modelu biznesowego)
- Koszt awarii (prawdopodobnie niski, ale niekoniecznie)
Musisz je zrównoważyć.
Powiedzmy na przykład, że zarabiasz około dolara na zadowolonego użytkownika. Że masz 3000 użytkowników dziennie. Że żądania kończą się niepowodzeniem przez około 50% czasu. I że 2% użytkowników wychodzi bez płacenia, gdy żądanie nie powiedzie się. Oznacza to, że tracisz (3000 * 50% * 2%) 30 dolarów dziennie. Teraz powiedzmy, że opracowanie nowej funkcji będzie kosztować 100 dolarów, a wdrożenie serwerów będzie kosztować 800 dolarów - i zignorowanie kosztów środowiska wykonawczego - oznacza to, że uzyskasz zwrot z inwestycji w ((100 + 800) / 30 ) 30 dni. Teraz możesz sprawdzić swój budżet i zdecydować.
Nie uważaj tych wartości za reprezentatywne dla rzeczywistości, wybrałem je ze względu na matematykę.
Dodatki:
- Pamiętaj, że ignoruję również szczegóły. Na przykład możesz mieć niewielkie koszty wdrożenia, ale płacisz za czas procesora i musisz to wziąć pod uwagę.
- Niektórzy klienci mogą to docenić, jeśli nie zmarnujesz ich pakietu danych na zbędne żądania.
- Ulepszenie produktu może pomóc w uzyskaniu naturalnej reklamy.
- Nie zapomnij o kosztach alternatywnych. Czy powinieneś rozwijać coś innego?
Chodzi o to, że jeśli weźmiesz pod uwagę problem związany z równoważeniem kosztów, możesz oszacować koszt rozważanych strategii i użyć tej analizy do podjęcia decyzji.
Intuicja
Intuicja, jeśli jest wspierana przez doświadczenie. Nie sugeruję przeprowadzania tego rodzaju analiz za każdym razem. Niektóre osoby tak robią i to jest w porządku. Sugeruję, abyście trochę to zrozumieli i wypracowali intuicję.
Ponadto w inżynierii, oprócz wiedzy, którą zdobywamy z faktycznej nauki, uczymy się również w praktyce i opracowujemy wytyczne dotyczące tego, co działa, a co nie. Dlatego często mądrze jest zobaczyć aktualny stan techniki ... chociaż czasami trzeba zobaczyć poza swoim obszarem.
W takim przypadku patrzyłbym na gry wideo online. Mają ekrany ładowania, mają wiele serwerów, wybiorą serwer na podstawie opóźnienia, a nawet mogą zezwolić użytkownikowi na zmianę serwerów. Wiemy, że to działa.
Sugerowałbym to zrobić zamiast marnować ruch sieciowy i czas serwera na każde żądanie, należy również pamiętać, że nawet w przypadku nadmiarowego serwera może wystąpić awaria.