Už dlho som nerozlúštil rozdiel medzi RPC (t. j. vzdialeným procedurálnym volaním) a HTTP volaniami. Prosím, dovoľte mi sa tu zasmiať~Naivné! Tento článok stručne predstavuje dve formy architektúry C/S, predovšetkým ich najzásadnejší rozdiel, teda RPC je založený hlavne na protokole TCP/IP, zatiaľ čo HTTP služba je hlavne založená na HTTP protokole. Všetci vieme, že HTTP protokol je nad transportnou vrstvou TCP, takže z hľadiska efektivity je RPC samozrejme lepší! Poďme sa podrobne porozprávať o RPC službách a HTTP službách.
OSI sieťový sedemvrstvový model
Predtým, než začneme hovoriť o rozdieloch medzi RPC a HTTP, považujem za nevyhnutné pochopiť sedemvrstvový sieťový model OSI (hoci v praxi ide v podstate o päť vrstiev), ktorý možno rozdeliť na nasledujúce vrstvy: (zhora nadol)
- Prvá vrstva: aplikačná vrstva. Sú definované rozhrania pre komunikáciu a prenos dát v sieti;
- Druhá vrstva: vrstva reprezentácie. Definovať formát prenosu, špecifikácie kódovania a dekódovania dát v rôznych systémoch a podobne;
- Tretia vrstva: konverzačná vrstva. Spravovať používateľské relácie a kontrolovať nadväzovanie a prerušovanie logických spojení medzi používateľmi.
- Štvrtá vrstva: transportná vrstva. Spravuje prenos dát od konca do konca v sieti;
- Vrstva 5: Sieťová vrstva. Definovať, ako sa dáta prenášajú medzi sieťovými zariadeniami;
- Šiesta vrstva: linková vrstva. Dátové pakety vyššie položenej sieťovej vrstvy sú zapuzdrené do dátových rámcov, aby sa uľahčil prenos fyzickej vrstvy.
- Vrstva 7: Fyzická vrstva. Táto vrstva je hlavne o prenose týchto binárnych dát.
V praktickej aplikácii neexistuje prezentačná vrstva ani relačná vrstva v päťvrstvovej protokolovej štruktúre. Treba povedať, že sa spájajú s aplikačnou vrstvou. Mali by sme sa zamerať na aplikačnú vrstvu a transportnú vrstvu. Pretože HTTP je protokol aplikačnej vrstvy, zatiaľ čo TCP je protokol transportnej vrstvy. Teraz, keď poznáme model sieťového vrstvenia, lepšie rozumieme, prečo sú RPC služby lepšie ako HTTP služby!
Služby RPC
RPC služby sú predstavené z troch perspektív: RPC architektúra, synchronné asynchrónne volania a populárne RPC frameworky.
Architektúra RPC
Poďme sa porozprávať o základnej architektúre RPC služieb. Dovoľte mi hanblivo ukradnúť obraz~ Jasne vidíme, že kompletná RPC architektúra obsahuje štyri základné komponenty, konkrétne Client, Server, Client Stub a Server Stub, ktorý možno chápať ako stub. Poďme sa o týchto komponentoch porozprávať samostatne:
- Klient, volajúci služby.
- Server, skutočný poskytovateľ služieb.
- Klientský stub uloží správu o adrese servera, potom zabalí parametre požiadavky klienta do sieťovej správy a následne ju vzdialene odošle servisnej strane cez sieť.
- Stub na strane servera prijíma správy odoslané klientom, rozbaľuje ich a volá lokálne metódy.
RPC sa hlavne používa vo veľkých podnikoch, pretože veľké podniky majú mnoho systémov, zložité obchodné línie a výhody efektivity sú veľmi dôležité. Toto sa robí priamo vo vývoji a projekty sa zvyčajne riadia pomocou maven. Napríklad máme systémovú službu, ktorá spracováva objednávky, najprv deklaruje všetky svoje rozhrania (tu konkrétne rozhranie v Jave) a potom celý projekt zabalí do jar balíka. Prečo to robiť? Hlavným účelom je zmenšiť veľkosť balíka jar na strane klienta, pretože zakaždým, keď sa balík vydá, príliš veľa balíkov jar vždy ovplyvní efektivitu. Zároveň oddeľuje klienta a server, aby zlepšil prenositeľnosť kódu.
Synchronné a asynchrónne volania
Čo je synchronný hovor? Čo je to asynchrónny hovor? Synchronné volanie je, keď klient čaká, kým sa volanie dokončí, a vráti výsledok. Asynchrónne volania znamenajú, že klient nečaká na vykonanie hovoru a nevráti výsledok, ale môže stále prijímať upozornenie na výsledok cez funkciu spätného volania. Ak klientovi na výsledku nezáleží, môže sa to zmeniť na jednosmerný hovor. Tento proces je do istej miery podobný volateľným a spustiteľným rozhraniam v Jave, keď vykonávame asynchrónne a potrebujeme poznať výsledok vykonania, môžeme použiť volateľné rozhranie a získať informácie o výsledku asynchrónneho vykonávania cez triedu Future. Ak vám nezáleží na výsledku vykonávania, môžete jednoducho použiť bežné rozhranie, pretože nevracia výsledok, samozrejme, volateľné je tiež možné, nepotrebujeme budúcnosť.
Populárny RPC rámec
Stále existuje mnoho populárnych open source RPC frameworkov. Tu sú tri hlavné body:
- gRPC je nedávno oznámený open-source softvér od Googlu, založený na najnovšom protokole HTTP 2.0, ktorý podporuje mnoho bežných programovacích jazykov. Vieme, že HTTP 2.0 je vylepšená verzia HTTP protokolu založená na binárnom systéme a hlavné prehliadače ho momentálne podporujú rýchlym tempom. Tento RPC rámec je založený na HTTP protokole a základ využíva podporu Netty frameworku.
- Thrift je open-source projekt pre Facebook, predovšetkým medzijazykový rámec pre vývoj služieb. Má generátor kódu, ktorý automaticky generuje rámec kódu služby pre IDL definačný súbor, ktorý definuje. Používatelia potrebujú vykonať len sekundárny vývoj predtým a základná RPC komunikácia je transparentná. Pre používateľov však stále existuje určitá cena za naučenie sa jazyka konkrétneho odboru.
- Dubbo je známy RPC framework open source od Alibaba Group, ktorý sa široko používa v mnohých internetových spoločnostiach a podnikových aplikáciách. Je možné zapojiť protokoly aj rámce serializácie. To isté vzdialené rozhranie je založené na Java rozhraní a spolieha sa na framework Spring pre jednoduchý vývoj. Dá sa jednoducho zabaliť do jedného súboru a spustiť nezávisle, čo je v súlade so súčasným konceptom mikroslužieb.
Tajne ti poviem, že skupina už dubbo veľmi nepoužíva,Ten, ktorý sa dnes používa častejšie, sa volá HSF, známej aj ako "tak pohodlné". Možno bude neskôr open source, tak počkajme a uvidíme.
HTTP služba
V skutočnosti som už dávno charakterizoval podnikový vývojový model ako vývoj HTTP rozhraní, čo často nazývame rozhrania v štýle RESTful. V skutočnosti ide o komunikačnú metódu často používanú v počiatočných fázach riešenia informačných ostrovov v prípade malého počtu rozhraní a menšej interakcie medzi systémami; Výhody sú jednoduché, priame a ľahko sa rozvíjajú. Využite hotový HTTP protokol na prenos. Pamätáme si, že keď sme predtým robili vývoj na pozadí v spoločnosti, vyvíjali sme hlavne rozhrania a tiež sme museli napísať rozsiahly dokument rozhrania, ktorý presne uvádzal, aké sú vstupy a výstupy. Vysvetlite spôsob požiadavky každého rozhrania a otázky, ktorým treba venovať pozornosť v parametroch požiadavky. Napríklad nasledujúci príklad:
STĹPhttp://www.httpexample.com/restful/buyer/info/share
Rozhranie môže vrátiť reťazec JSON alebo XML dokument. Klient potom spracuje tieto vrátené informácie, čo umožňuje rýchlejší vývoj. Avšak pre veľké podniky, keď je veľa interných podsystémov a rozhranií, sa ukazujú výhody RPC rámca, predovšetkým je to dlhé prepojenie a nie je potrebné podávať ruky trikrát ako http zakaždým, čím sa znižuje režijná záťaž siete; po druhé, rámec RPC má zvyčajne registračné centrum a bohaté monitorovanie a správu; Publikovanie, offline rozhrania, dynamické rozširovanie a podobne sú pre volajúceho neperceptívne a jednotné operácie.
súhrn
Vo všeobecnosti sú RPC služby určené najmä pre veľké podniky, zatiaľ čo HTTP služby sú určené najmä pre malé podniky, pretože RPC je efektívnejšie a iterácie vývoja HTTP služieb sú rýchlejšie. Stručne povedané, aký typ rámca zvoliť, nezávisí od toho, čo je populárne na trhu, ale od úplného vyhodnotenia celého projektu, aby sa starostlivo porovnal vplyv oboch vývojových rámcov na celý projekt a nakoniec sa rozhodlo, čo je pre projekt najvhodnejšie. Nemali by sme používať RPC pre každý projekt len kvôli samotnému využitiu RPC, ale musíme sa prispôsobiť miestnym podmienkam a analyzovať konkrétnu situáciu.
|
Zverejnené 1. 4. 2019 14:02:45
|
|
|
|
