Od dawna nie rozróżniałem wywołań RPC (czyli zdalnych wywołań procedur) i wywołań HTTP. Proszę, pozwólcie mi się tu pośmiać~Naiwność! Ten artykuł krótko przedstawia dwie formy architektury C/S, przede wszystkim ich najważniejszą różnicę, czyli RPC opiera się głównie na protokole TCP/IP, podczas gdy usługa HTTP opiera się głównie na protokole HTTP; wszyscy wiemy, że protokół HTTP jest na wierzchu protokołu TCP warstwy transportowej, więc pod względem efektywności RPC jest oczywiście lepsze! Porozmawiajmy szczegółowo o usługach RPC i usługach HTTP.
Model siedmiowarstwowy sieci OSI
Zanim przejdziemy do różnicy między RPC a HTTP, uważam, że konieczne jest zrozumienie siedmiowarstwowego modelu struktury sieci OSI (choć w praktyce jest on zasadniczo pięciowarstwowy), który można podzielić na następujące warstwy: (od góry do dołu)
- Pierwsza warstwa: warstwa aplikacji. Definiowane są interfejsy komunikacji i transmisji danych w sieci;
- Druga warstwa: warstwa reprezentacji. Zdefiniuj format transmisji, specyfikacje kodowania i dekodowania danych w różnych systemach itd.;
- Trzecia warstwa: warstwa rozmowy. Zarządzanie sesjami użytkownika oraz kontrola nawiązywania i przerywania logicznych połączeń między użytkownikami.
- Czwarta warstwa: warstwa transportowa. Zarządza transmisją danych end-to-end w sieci;
- Warstwa 5: Warstwa sieciowa. Określić sposób przesyłania danych między urządzeniami sieciowymi;
- Szósta warstwa: warstwa linkowa. Pakiety danych warstwy sieciowej powyżej są enkapsulowane w ramki danych, aby ułatwić transmisję warstwy fizycznej.
- Warstwa 7: Warstwa fizyczna. Ta warstwa służy głównie do przesyłania tych danych binarnych.
W praktyce nie ma warstwy prezentacji ani warstwy sesji w pięciowarstwowej strukturze protokołu. Warto dodać, że łączą się one z warstwą aplikacji. Powinniśmy skupić się na warstwie aplikacyjnej i transportowej. Ponieważ HTTP jest protokołem warstwy aplikacji, podczas gdy TCP to protokół warstwy transportowej. Teraz, gdy znamy model warstw sieciowych, lepiej rozumiemy, dlaczego usługi RPC są lepsze niż usługi HTTP!
Usługi RPC
Usługi RPC są wprowadzane z trzech perspektyw: architektury RPC, synchronicznych wywołań asynchronicznych oraz popularnych frameworków RPC.
Architektura RPC
Porozmawiajmy o podstawowej architekturze usług RPC. Pozwólcie, że z wstydem ukradnę obraz~ Wyraźnie widzimy, że kompletna architektura RPC zawiera cztery kluczowe komponenty: Klient, Serwer, Klient-stub i Serwerowy stub, który można rozumieć jako stub. Porozmawiajmy o tych komponentach osobno:
- Klient, dzwoniący do usługi.
- Serwer, prawdziwy dostawca usług.
- Stub klienta przechowuje komunikat adresowy serwera, a następnie pakuje parametry żądania klienta do wiadomości sieciowej i wysyła je zdalnie do strony serwisowej przez sieci.
- Stub po stronie serwera odbiera wiadomości wysyłane przez klienta, rozpakowuje je i wywołuje lokalne metody.
RPC jest głównie stosowane w dużych przedsiębiorstwach, ponieważ duże przedsiębiorstwa mają wiele systemów, złożone linie biznesowe, a korzyści efektywnościowe są bardzo istotne. Odbywa się to podczas faktycznego rozwoju, a projekty są zazwyczaj zarządzane za pomocą maven. Na przykład mamy usługę systemową, która przetwarza zamówienia, najpierw deklaruje wszystkie swoje interfejsy (tutaj konkretnie interfejs w Javie), a następnie pakuje cały projekt do pakietu jar. Dlaczego to robić? Głównym celem jest zmniejszenie rozmiaru pakietu jar po stronie klienta, ponieważ za każdym razem, gdy pakiet jest wypuszczany, zbyt wiele pakietów jar zawsze wpływa na efektywność. Łączy także klienta i serwer, aby poprawić przenośność kodu.
Połączenia synchroniczne i asynchroniczne
Czym jest połączenie synchroniczne? Czym jest połączenie asynchroniczne? Wywołanie synchroniczne to sytuacja, gdy klient czeka na zakończenie wykonania wywołania i zwraca wynik. Wywołania asynchroniczne oznaczają, że klient nie czeka na wykonanie wywołania i zwrot wyniku, ale nadal może otrzymać powiadomienie o wyniku, który zwrócił się za pomocą funkcji callback. Jeśli klient nie zależy na wyniku, może to przerodzić się w jednostronny telefon. Proces ten jest w pewnym stopniu podobny do interfejsów wywoływalnych i uruchamialnych w Javie; gdy wykonujemy asynchronicznie, jeśli potrzebujemy znać wynik wykonania, możemy użyć interfejsu wywołalnego i uzyskać informacje o wyniku asynchronicznego wykonania przez klasę Future. Jeśli nie zależy Ci na wyniku wykonania, możesz po prostu użyć interfejsu uruchamialnego, bo nie zwraca wyniku, oczywiście wywołalność też jest możliwa, nie potrzebujemy przyszłości.
Popularny framework RPC
Wciąż istnieje wiele popularnych otwartych frameworków RPC. Oto trzy najważniejsze punkty:
- gRPC to niedawno ogłoszone oprogramowanie otwartego oprogramowania Google, oparte na najnowszym protokole HTTP 2.0, które obsługuje wiele popularnych języków programowania. Wiemy, że HTTP 2.0 to ulepszona wersja protokołu HTTP oparta na systemie binarnym, a główne przeglądarki obecnie obsługują go w szybkim tempie. Ten framework RPC opiera się na protokole HTTP, a podstawowy korzysta ze wsparcia frameworka Netty.
- Thrift to projekt open-source dla Facebooka, przede wszystkim framework do tworzenia usług obejmujących różne języki. Posiada generator kodu, który automatycznie generuje framework kodu serwisu dla pliku definiującego IDL. Użytkownicy muszą jedynie wykonać wtórny rozwój przed tym, a komunikacja RPC jest przejrzysta. Jednak dla użytkowników nauka języka danej dziedziny wiąże się z pewnym kosztem.
- Dubbo to znany framework RPC open source firmy Alibaba Group, szeroko stosowany w wielu firmach internetowych i aplikacjach korporacyjnych. Można podłączyć zarówno protokoły, jak i frameworki serializacyjne. Ten sam zdalny interfejs opiera się na interfejsie Java i opiera się na frameworku spring, co ułatwia rozwój. Można go łatwo zapakować w jeden plik i uruchomić niezależnie, co jest zgodne z obecną koncepcją mikroserwisów.
Potajemnie powiem ci, że grupa już prawie nie używa dubbo,Obecnie częściej stosowany jest HSF, znana również jako "tak wygodna". Może pojawi się open source później, więc poczekajmy i zobaczmy.
Usługa HTTP
W rzeczywistości, już dawno temu zawsze określałem model rozwoju korporacyjnego jako tworzenie interfejsów HTTP, co często nazywamy interfejsami usługowymi w stylu RESTful. Jest to metoda komunikacji często stosowana na wczesnym etapie rozwiązywania wysp informacyjnych w przypadku niewielkiej liczby interfejsów i mniejszej interakcji między systemami; Zalety są proste, bezpośrednie i łatwe do opracowania. Wykorzystaj gotowy protokół HTTP do transmisji. Pamiętamy, że gdy wcześniej tworzyliśmy w tle, głównie tworzyliśmy interfejsy, a także musieliśmy pisać obszerny dokument interfejsu, ściśle określający, jakie są dane wejściowe i wyjściowe. Wyjaśnij metodę żądań każdego interfejsu oraz kwestie, na które należy zwrócić uwagę, w parametrach żądania. Na przykład następujący przykład:
POSThttp://www.httpexample.com/restful/buyer/info/share
Interfejs może zwracać ciąg znaków JSON lub dokument XML. Klient następnie przetwarza te zwrócone informacje, co pozwala na szybszy rozwój. Jednak dla dużych przedsiębiorstw, gdy istnieje wiele wewnętrznych podsystemów i wiele interfejsów, widoczne są zalety frameworka RPC: przede wszystkim jest to długie łącze i nie ma potrzeby uściskania ręki trzy razy jak http za każdym razem, co zmniejsza narzut sieci; po drugie, ramy RPC zazwyczaj posiadają centrum rejestracji oraz bogaty monitoring i zarządzanie; Publikowanie, interfejsy offline, dynamiczna ekspansja itp. to operacje niepercepcyjne i zunifikowane dla dzwoniącego.
streszczenie
Ogólnie rzecz biorąc, usługi RPC są głównie przeznaczone dla dużych przedsiębiorstw, podczas gdy usługi HTTP są głównie dla małych przedsiębiorstw, ponieważ RPC jest bardziej wydajne, a iteracje rozwoju usług HTTP są szybsze. Krótko mówiąc, wybór ram nie zależy od tego, co jest popularne na rynku, lecz od pełnej oceny całego projektu, aby dokładnie porównać wpływ obu ram rozwojowych na cały projekt i ostatecznie zdecydować, co jest najbardziej odpowiednie dla danego projektu. Nie powinniśmy używać RPC w każdym projekcie tylko dla samego wykorzystania RPC, lecz dostosować się do warunków lokalnych i przeanalizować konkretną sytuację.
|
Opublikowano 01.04.2019 14:02:45
|
|
|
|
