Už dlouho jsem nerozlišoval mezi RPC (tj. vzdáleným procedurálním voláním) a HTTP voláním. Prosím, dovolte mi se tu zasmát~Naivní! Tento článek stručně představuje dvě formy architektury C/S, především jejich zásadní rozdíl, totiž RPC je založeno hlavně na protokolu TCP/IP, zatímco HTTP služba je založena především na HTTP protokolu, všichni víme, že HTTP protokol je nad transportní vrstvou TCP, takže z hlediska efektivity je RPC samozřejmě lepší! Pojďme si podrobněji promluvit o RPC službách a HTTP službách.
OSI síťový sedmivrstvý model
Než se pustím do rozhovoru o rozdílu mezi RPC a HTTP, považuji za nutné pochopit sedmivrstvý síťový model OSI (i když v praxi je to v podstatě pět vrstev), který lze rozdělit do následujících vrstev: (odshora dolů)
- První vrstva: aplikační vrstva. Jsou definována rozhraní pro komunikaci a přenos dat v síti;
- Druhá vrstva: vrstva reprezentace. Definovat formát přenosu, specifikace kódování a dekódování dat v různých systémech atd.;
- Třetí vrstva: konverzační vrstva. Spravovat uživatelské relace a kontrolovat navazování a přerušování logických spojení mezi uživateli.
- Čtvrtá vrstva: transportní vrstva. Řídí přenos dat od začátku do konce v síti;
- Vrstva 5: Síťová vrstva. Definovat, jak jsou data přenášena mezi síťovými zařízeními;
- Šestá vrstva: spojovací vrstva. Datové pakety výše uvedené síťové vrstvy jsou zapouzdřeny do datových rámců, aby se usnadnil přenos fyzické vrstvy.
- Vrstva 7: Fyzická vrstva. Tato vrstva se zaměřuje především na přenos těchto binárních dat.
V praktické aplikaci neexistuje v rámci pětivrstvé protokolové struktury prezentační vrstva a relační vrstva. Je třeba říct, že se spojují s aplikační vrstvou. Měli bychom se zaměřit na aplikační vrstvu a transportní vrstvu. Protože HTTP je protokol aplikační vrstvy, zatímco TCP je protokol transportní vrstvy. Teď, když známe model síťového vrstvení, lépe chápeme, proč jsou RPC služby lepší než HTTP služby!
Služby RPC
RPC služby jsou představeny ze tří perspektiv: architektura RPC, synchronní asynchronní volání a populární RPC frameworky.
Architektura RPC
Pojďme si promluvit o základní architektuře RPC služeb. Dovolte mi hanebně ukrást obrázek~ Jasně vidíme, že kompletní RPC architektura obsahuje čtyři základní komponenty, konkrétně Client, Server, Client Stub a Server Stub, které lze chápat jako stub. Pojďme si o těchto složkách mluvit zvlášť:
- Klient, volající služby.
- Server, skutečný poskytovatel služeb.
- Klientský stub ukládá adresní zprávu serveru, poté zabalí parametry požadavku klienta do síťové zprávy a odesílá ji servisní straně vzdáleně přes síť.
- Serverový stub přijímá zprávy odeslané klientem, rozbaluje je a volá lokální metody.
RPC se používá především ve velkých podnicích, protože velké podniky mají mnoho systémů, složité obchodní linie a výhody efektivity jsou velmi důležité. To se děje přímo ve vývoji a projekty se obvykle řídí pomocí maven. Například máme systémovou službu, která zpracovává příkazy, nejprve deklaruje všechna svá rozhraní (zde konkrétně rozhraní v Javě) a poté celý projekt zabalí do jar balíčku. Proč to dělat? Hlavním účelem je zmenšit velikost balíčku jar na straně klienta, protože pokaždé, když je balíček uvolněn, příliš mnoho balíčků jar vždy ovlivní efektivitu. Také odděluje klienta a server pro zlepšení přenositelnosti kódu.
Synchronní a asynchronní volání
Co je to synchronní hovor? Co je to asynchronní hovor? Synchronní volání znamená, že klient čeká na dokončení volání a vrátí výsledek. Asynchronní volání znamenají, že klient nečeká na spuštění hovoru a vrácení výsledku, ale může stále přijímat oznámení o výsledku zpětného volání prostřednictvím funkce callback. Pokud klientovi na výsledku nezáleží, může se to změnit v jednosměrný hovor. Tento proces je do jisté míry podobný volatelným a spustitelným rozhraním v Javě, když vykonáváme asynchronně, pokud potřebujeme znát výsledek vykonání, můžeme použít volatelné rozhraní a získat informace o výsledku asynchronního vykonávání prostřednictvím třídy Future. Pokud vám na výsledku nezáleží, můžete prostě použít runnable rozhraní, protože nevrací výsledek, samozřejmě volatelné je také možné, nepotřebujeme budoucnost.
Populární RPC framework
Stále existuje mnoho populárních open source RPC frameworků. Zde jsou tři hlavní body:
- gRPC je nedávno oznámený open-source software od Googlu, založený na nejnovějším protokolu HTTP 2.0, který podporuje mnoho běžných programovacích jazyků. Víme, že HTTP 2.0 je vylepšená verze HTTP protokolu založená na binárním formátu a hlavní prohlížeče jej v současnosti podporují velmi rychle. Tento RPC rámec je založen na protokolu HTTP a jeho základ využívá podporu frameworku Netty.
- Thrift je open-source projekt pro Facebook, především framework pro vývoj služeb napříč jazyky. Má generátor kódu, který automaticky generuje rámec pro rámec kódu služby pro IDL definující soubor, který definuje. Uživatelé musí provést pouze sekundární vývoj před tímto procesem a základní RPC komunikace je transparentní. Pro uživatele však stále existuje určitá cena za naučení jazyka konkrétního oboru.
- Dubbo je známý RPC framework open source od Alibaba Group, který je široce využíván v mnoha internetových firmách a podnikových aplikacích. Lze zapojit jak protokoly, tak rámce serializace. Stejné vzdálené rozhraní je založeno na Java Interface a spoléhá na framework Spring pro snadný vývoj. Lze jej snadno zabalit do jednoho souboru a spustit nezávisle, což je v souladu se současným konceptem mikroservisů.
Tajně ti říct, že skupina už dubbo moc nepoužívá,Ten, který se dnes používá častěji, se jmenuje HSF, také známé jako "tak pohodlné". Možná bude open source později, tak počkejme a uvidíme.
HTTP služba
Ve skutečnosti jsem už dávno charakterizoval podnikový vývojový model jako vývoj HTTP rozhraní, což je to, co často nazýváme servisními rozhraními ve stylu RESTful. Ve skutečnosti jde o komunikační metodu často používanou v rané fázi řešení informačních ostrovů v případě omezeného počtu rozhraní a menší interakce mezi systémy; Výhody jsou jednoduché, přímé a snadno rozvinutelné. Využijte hotový HTTP protokol pro přenos. Pamatujeme si, že když jsme dříve ve firmě dělali vývoj na pozadí, vyvíjeli jsme hlavně rozhraní a také jsme museli napsat rozsáhlý dokument rozhraní, který přesně určoval, jaké jsou vstupy a výstupy. Vysvětlete způsob požadavku každého rozhraní a záležitosti, kterým je třeba v parametrech požadavku věnovat pozornost. Například následující příklad:
POSThttp://www.httpexample.com/restful/buyer/info/share
Rozhraní může vracet JSON řetězec nebo XML dokument. Klient pak tyto vrácené informace zpracuje, což umožňuje rychlejší vývoj. Nicméně u velkých podniků, kdy je mnoho interních podsystémů a rozhraní mnoho, se projevují výhody RPC frameworku, především je to dlouhé spojení a není třeba si pokaždé podávat ruce třikrát jako http, což snižuje síťovou zátěž; za druhé, rámec RPC obecně má registrační centrum a bohaté monitorování a správu; Publikování, offline rozhraní, dynamická expanze atd. jsou pro volajícího nepercepční a jednotné operace.
shrnutí
Obecně platí, že RPC služby jsou určeny hlavně pro velké podniky, zatímco HTTP služby jsou určeny především pro malé podniky, protože RPC je efektivnější a iterace vývoje HTTP služeb jsou rychlejší. Stručně řečeno, jaký rámec zvolit, není určen tím, co je na trhu populární, ale celým projektem je třeba důkladně vyhodnotit, aby bylo možné pečlivě porovnat dopad obou vývojových rámců na celý projekt a nakonec rozhodnout, co je pro projekt nejvhodnější. Nesmíme používat RPC pro každý projekt jen proto, abychom ho použili, ale musíme se přizpůsobit místním podmínkám a analyzovat konkrétní situaci.
|
Zveřejněno 01.04.2019 14:02:45
|
|
|
|
