Jestem pewien, że nagłówek wywołał zdrową reakcję – „no cóż, znów się zaczęło…”. Pozwól jednak, że przykuję Twoją uwagę na 5–10 minut i postaram się nie zawieść Twoich oczekiwań.
Struktura artykułu będzie następująca: zostanie przyjęte stwierdzenie stereotypowe i ujawniona zostanie „natura” powstania tego stereotypu. Mam nadzieję, że pozwoli to Państwu spojrzeć z nowej perspektywy na wybór paradygmatu wymiany danych w Waszych projektach.
Aby było jasne, czym jest RPC, proponuję rozważyć standard . W przypadku REST nie ma jasności. I nie powinno tak być. Wszystko, co musisz wiedzieć o REST - jest nie do odróżnienia od .
Żądania RPC są szybsze i wydajniejsze, ponieważ umożliwiają wysyłanie żądań wsadowych.
Chodzi o to, że w RPC można wywołać kilka procedur na raz w jednym żądaniu. Na przykład utwórz użytkownika, dodaj do niego awatar i w tej samej prośbie zasubskrybuj go do niektórych tematów. Tylko jedna prośba, a ile korzyści!
Rzeczywiście, jeśli masz tylko jeden węzeł zaplecza, żądanie wsadowe będzie wydawać się szybsze. Ponieważ trzy żądania REST będą wymagały trzy razy więcej zasobów z jednego węzła do nawiązania połączenia.
Należy pamiętać, że pierwsze żądanie w przypadku REST musi zwrócić identyfikator użytkownika, aby możliwe było wykonanie kolejnych żądań. Co również negatywnie wpływa na ogólny wynik.
Jednak taką infrastrukturę można znaleźć tylko w rozwiązaniach wewnętrznych i przedsiębiorstwach. W ostateczności, w małych projektach WEBOWYCH. Ale pełnoprawnych rozwiązań WEBowych, a nawet tych zwanych HighLoad, nie warto budować. Ich infrastruktura musi spełniać kryteria wysokiej dostępności i obciążenia. A obraz się zmienia.
Kolorem zielonym zaznaczono kanały działalności infrastrukturalnej w ramach tego samego scenariusza. Zwróć uwagę, jak teraz zachowuje się RPC. Żądanie wykorzystuje infrastrukturę tylko na jednej nodze, od modułu równoważącego do zaplecza. O ile REST nadal przegrywa w pierwszym żądaniu, to nadrabia stracony czas wykorzystując całą infrastrukturę.
Wystarczy wpisać w scenariusz nie dwie prośby o wzbogacenie, ale powiedzmy pięć lub dziesięć… i odpowiedź na pytanie „kto teraz wygra?” staje się niejasne.
Proponuję spojrzeć na problem jeszcze szerzej. Diagram pokazuje, w jaki sposób wykorzystywane są kanały infrastruktury, ale infrastruktura nie ogranicza się do kanałów. Ważnym elementem infrastruktury o dużym obciążeniu są pamięci podręczne. Zdobądźmy teraz jakiś rodzaj artefaktu użytkownika. Wielokrotnie. Powiedzmy 32 razy.
Zobacz, jak infrastruktura RPC uległa znacznej poprawie, aby sprostać wymaganiom dużego obciążenia. Rzecz w tym, że REST wykorzystuje pełną moc protokołu HTTP, w przeciwieństwie do RPC. Na powyższym schemacie moc ta realizowana jest poprzez metodę żądania – GET.
Metody HTTP mają między innymi strategie buforowania. Można je znaleźć w dokumentacji pod adresem . W przypadku RPC używane są żądania POST, które nie są uważane za idempotentne, czyli wielokrotne powtórzenia tych samych żądań POST mogą zwracać różne wyniki (np. po wysłaniu każdego komentarza pojawi się kolejna kopia tego komentarza) ().
W rezultacie RPC nie jest w stanie efektywnie wykorzystywać pamięci podręcznych infrastruktury. Prowadzi to do konieczności „importowania” pamięci podręcznych oprogramowania. Diagram przedstawia Redis w tej roli. Pamięć podręczna oprogramowania z kolei wymaga od programisty dodania dodatkowej warstwy kodu i zauważalnych zmian w architekturze.
Policzmy teraz, ile żądań REST i RPC „zrodziło” w rozważanej infrastrukturze?
wnioski
W pudełku
do backendu
do SZBD
do miękkiej pamięci podręcznej (Redis)
RAZEM
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
W porównaniu z pierwszym schematem różnica jest uderzająca. Teraz korzyści z REST stają się jasne. Ale radzę nie poprzestawać na tym. Rozwinięta infrastruktura obejmuje sieć CDN. Często rozwiązuje także kwestię przeciwdziałania atakom DDoS i DoS. Otrzymujemy:
Tutaj sytuacja dla RPC staje się naprawdę zła. RPC po prostu nie jest w stanie delegować obciążenia do CDN. W zakresie przeciwdziałania atakom możemy polegać wyłącznie na systemach.
Czy można na tym zakończyć? I znowu, nie. Metody HTTP, jak wspomniano powyżej, mają swoją „magię”. I nie bez powodu metoda GET jest szeroko stosowana w Internecie. Należy pamiętać, że ta metoda pozwala uzyskać dostęp do fragmentu treści, ustawić warunki, które elementy infrastruktury mogą zinterpretować przed przekazaniem kontroli do kodu itd. Wszystko to pozwala na tworzenie elastycznych, łatwych w zarządzaniu infrastruktur, które są w stanie obsłużyć naprawdę duże przepływy żądań. Ale w RPC ta metoda... jest ignorowana.
Dlaczego więc mit, że żądania wsadowe (RPC) są szybsze, jest tak trwały? Osobiście wydaje mi się, że większość projektów po prostu nie osiąga takiego poziomu rozwoju, na którym REST jest w stanie pokazać swoją siłę. Co więcej, w małych projektach chętniej pokazuje swoje słabości.
Wybór REST lub RPC nie jest dobrowolnym wyborem jednostki w projekcie. Wybór ten musi spełniać wymagania projektu. Jeśli projekt jest w stanie wycisnąć z REST wszystko, co się da, a naprawdę tego potrzebuje, to REST będzie doskonałym wyborem.
Ale jeśli, aby uzyskać wszystkie korzyści z REST, trzeba zatrudnić specjalistów devops do projektu, aby szybko skalować infrastrukturę, administratorów do zarządzania infrastrukturą, architekta do zaprojektowania wszystkich warstw usługi WEB… i projekt jednocześnie sprzedaje trzy paczki margaryny dziennie... Ja pozostałbym przy RPC, bo... ten protokół jest bardziej utylitarny. Nie będzie to wymagało głębokiej wiedzy na temat działania pamięci podręcznych i infrastruktury, ale skupi się na prostych i zrozumiałych wywołaniach potrzebnych mu procedur. Biznes będzie szczęśliwy.
Żądania RPC są bardziej niezawodne, ponieważ mogą wykonywać żądania wsadowe w ramach pojedynczej transakcji
Ta właściwość RPC jest zdecydowaną zaletą, ponieważ Utrzymanie spójności bazy danych jest łatwe. Ale w przypadku REST robi się to coraz bardziej skomplikowane. Żądania mogą docierać niespójnie do różnych węzłów zaplecza.
Ta „wada” REST-u jest odwrotną stroną opisanej powyżej jego zalety – możliwością efektywnego wykorzystania wszystkich zasobów infrastruktury. Jeśli infrastruktura jest źle zaprojektowana, a tym bardziej, jeśli architektura projektu i w szczególności baza danych są źle zaprojektowane, to jest to naprawdę duży problem.
Ale czy żądania wsadowe są tak niezawodne, jak się wydaje? Spójrzmy na przypadek: tworzymy użytkownika, wzbogacamy jego profil o jakiś opis i wysyłamy mu SMS z sekretem, aby dokończyć rejestrację. Te. trzy wywołania w jednym żądaniu zbiorczym.
Spójrzmy na diagram. Prezentuje infrastrukturę z elementami o wysokiej dostępności. Z bramkami SMS istnieją dwa niezależne kanały komunikacji. Ale... co widzimy? Podczas wysyłania SMS-a pojawia się błąd 503 - usługa chwilowo niedostępna. Ponieważ Wysyłanie SMS-ów jest pakowane w żądanie zbiorcze, wówczas całe żądanie musi zostać wycofane. Działania w DBMS są anulowane. Klient otrzymuje błąd.
Następną próbą jest loteria. Albo żądanie ponownie trafi do tego samego węzła i zwróci błąd, albo będziesz miał szczęście i zostanie wykonane. Ale najważniejsze jest to, że przynajmniej raz nasza infrastruktura zadziałała już na próżno. Było obciążenie, ale nie było zysku.
OK, wyobraźmy sobie, że napracowaliśmy się (!) i przemyśleliśmy opcję, gdy żądanie może zostać częściowo zrealizowane pomyślnie. A resztę postaramy się dokończyć ponownie po pewnym czasie (Który? Czy decyduje front?). Ale loteria pozostała ta sama. Prawdopodobieństwo ponownego niepowodzenia prośby o wysłanie SMS-a wynosi 50/50.
Zgadzam się, od strony klienta usługa nie wydaje się tak niezawodna jak byśmy chcieli... a co z REST?
REST ponownie wykorzystuje magię HTTP, ale teraz z kodami odpowiedzi. Gdy na bramce SMS wystąpi błąd 503, backend rozgłasza ten błąd do modułu równoważącego. Balancer odbiera ten błąd i bez zrywania połączenia z klientem wysyła żądanie do innego węzła, który pomyślnie przetwarza żądanie. Te. klient otrzymuje oczekiwany rezultat, a infrastruktura potwierdza swój wysoki tytuł „wysoce dostępnego”. Użytkownik jest zadowolony.
I znowu to nie wszystko. Balancer nie tylko otrzymał kod odpowiedzi 503. Podczas odpowiadania zgodnie ze standardem wskazane jest podanie tego kodu z nagłówkiem „Retry-After”. Nagłówek daje jasno do zrozumienia balanserowi, że nie warto zakłócać tego węzła na tej trasie przez określony czas. A kolejne prośby o wysłanie SMS-a zostaną wysłane bezpośrednio do węzła, który nie ma problemów z bramką SMS.
Jak widać niezawodność JSON-RPC jest przereklamowana. Rzeczywiście łatwiej jest zorganizować spójność w bazie danych. Ale w tym przypadku poświęceniem będzie niezawodność systemu jako całości.
Konkluzja jest w dużej mierze podobna do poprzedniej. Gdy infrastruktura jest prosta, oczywistość JSON-RPC jest zdecydowanie zaletą. Jeśli projekt zakłada wysoką dostępność przy dużym obciążeniu, REST wydaje się rozwiązaniem bardziej poprawnym, choć bardziej złożonym.
Próg wejścia do REST jest niższy
Myślę, że powyższa analiza, obalająca utarte stereotypy na temat RPC, jednoznacznie pokazała, że próg wejścia do REST jest niewątpliwie wyższy niż do RPC. Wynika to z konieczności głębokiego zrozumienia działania protokołu HTTP, a także konieczności posiadania wystarczającej wiedzy na temat istniejących elementów infrastruktury, które można i należy wykorzystać w projektach WEBowych.
Dlaczego więc wiele osób uważa, że REST będzie prostszy? Moim osobistym zdaniem ta pozorna prostota pochodzi z manifestacji REST. Te. REST nie jest protokołem, ale koncepcją... REST nie ma standardu, są pewne wytyczne... REST nie jest bardziej skomplikowany niż HTTP. Pozorna wolność i anarchia przyciągają „wolnych artystów”.
Oczywiście REST nie jest bardziej skomplikowany niż HTTP. Jednak sam HTTP jest dobrze zaprojektowanym protokołem, który udowodnił swoją wartość przez dziesięciolecia. Jeśli nie ma głębokiego zrozumienia samego HTTP, nie można ocenić REST.
Ale w przypadku RPC - możesz. Wystarczy sięgnąć po jego specyfikację. Więc potrzebujesz ? A może nadal jest to trudny REST? Ty decydujesz.
Mam szczerą nadzieję, że nie zmarnowałem Państwa czasu.
Źródło: www.habr.com