Pitkään en ole ymmärtänyt eroa RPC:n (eli etäproseduurikutsu) ja HTTP-kutsujen välillä. Sallikaa minun nauraa tässä~Naiivi! Tässä artikkelissa esitellään lyhyesti C/S-arkkitehtuurin kaksi muotoa, ensinnäkin niiden tärkein ero, eli RPC perustuu pääasiassa TCP/IP-protokollaan, kun taas HTTP-palvelu perustuu pääasiassa HTTP-protokollaan. Me kaikki tiedämme, että HTTP-protokolla on siirtokerroksen protokollan TCP:n päällä, joten tehokkuuden kannalta RPC on tietysti parempi! Keskustellaanpa yksityiskohtaisesti RPC- ja HTTP-palveluista.
OSI-verkon seitsemänkerroksinen malli
Ennen kuin puhun RPC:n ja HTTP:n erosta, koen tarpeelliseksi ymmärtää OSI:n seitsemän kerroksen verkkorakennemalli (vaikka käytännössä se on käytännössä viisi kerrosta), joka voidaan jakaa seuraaviin kerroksiin: (ylhäältä alas)
- Ensimmäinen kerros: levityskerros. Verkon viestintä- ja tiedonsiirtorajapinnat määritellään;
- Toinen kerros: esityskerros. Määritellä siirtomuoto, koodaus ja purku eri järjestelmissä olevien tietojen määrittelyt jne.;
- Kolmas kerros: keskustelukerros. Hallinnoi käyttäjäistuntoja ja hallitse loogisten yhteyksien muodostamista ja keskeyttämistä käyttäjien välillä.
- Neljäs kerros: kuljetuskerros. Se hallinnoi verkon päästä päähän -tiedonsiirtoa;
- Kerros 5: Verkkokerros. Määrittele, miten dataa siirretään verkkolaitteiden välillä;
- Kuudes kerros: linkkikerros. Yllä olevan verkkokerroksen datapaketit kapseloidaan datakehyksiin, jotta fyysisen kerroksen siirto helppoutuu.
- Kerros 7: Fyysinen kerros. Tämä kerros keskittyy pääasiassa tämän binäärisen datan välittämiseen.
Käytännössä viiden kerroksen protokollarakenteessa ei ole esityskerrosta ja istuntokerrosta. On sanottava, että ne yhdistyvät sovelluskerrokseen. Meidän tulisi keskittyä sovelluskerrokseen ja kuljetuskerrokseen. Koska HTTP on sovelluskerroksen protokolla, kun taas TCP on siirtokerroksen protokolla. Nyt kun tunnemme verkon kerrosmallin, ymmärrämme paremmin, miksi RPC-palvelut ovat mukavampia kuin HTTP-palvelut!
RPC-palvelut
RPC-palvelut esitellään kolmesta näkökulmasta: RPC-arkkitehtuuri, synkroniset asynkroniset kutsut ja suositut RPC-kehykset.
RPC-arkkitehtuuri
Puhutaanpa RPC-palveluiden perusarkkitehtuurista. Sallikaa minun häpeällisesti varastaa kuva~ Näemme selvästi, että täydellinen RPC-arkkitehtuuri sisältää neljä ydinkomponenttia: Client, Server, Client Stub ja Server Stub, jotka voidaan ymmärtää stubiksi. Keskustellaan näistä komponenteista erikseen:
- Asiakas, palvelun soittaja.
- Palvelin, todellinen palveluntarjoaja.
- Asiakasstub tallentaa palvelimen osoiteviestin, pakkaa sitten asiakkaan pyyntöparametrit verkkoviestiksi, ja lähettää sen palveluosapuolelle etänä verkon kautta.
- Palvelinpuolen stub vastaanottaa asiakkaan lähettämiä viestejä, purkaa viestit ja kutsuu paikallisia metodeja.
RPC:tä käytetään pääasiassa suurissa yrityksissä, koska suurilla yrityksillä on monia järjestelmiä, monimutkaiset liiketoimintalinjat ja tehokkuusedut ovat erittäin tärkeitä. Tämä tapahtuu varsinaisessa kehityksessä, ja projekteja hallinnoidaan yleensä mavenilla. Esimerkiksi meillä on järjestelmäpalvelu, joka käsittelee tilaukset, ensin määrittelee kaikki rajapinnat (tässä erityisesti rajapinnan Javassa) ja pakkaa sitten koko projektin jar-pakettiin. Miksi tehdä näin? Pääasiallinen tarkoitus on pienentää jar-paketin kokoa asiakkaan puolella, koska aina kun paketti julkaistaan, liian moni jar-paketti vaikuttaa tehokkuuteen. Se myös irrottaa asiakkaan ja palvelimen toisistaan parantaakseen koodin siirrettävyyttä.
Synkroniset ja asynkroniset kutsut
Mikä on synkroninen kutsu? Mikä on asynkroninen kutsu? Synkroninen kutsu tarkoittaa, että asiakas odottaa kutsun suorittamista ja palauttaa tuloksen. Asynkroniset kutsut tarkoittavat, että asiakas ei odota kutsun suorittamista ja palautusta tulokseen, mutta voi silti saada ilmoituksen palautustuloksesta callback-toiminnon kautta. Jos asiakas ei välitä lopputuloksesta, se voi muuttua yksisuuntaiseksi puheluksi. Tämä prosessi on jossain määrin samankaltainen kuin Javan kutsuttavat ja ajettavat rajapinnat: kun suoritamme asynkronisesti, jos haluamme tietää suorituksen tuloksen, voimme käyttää kutsuttavaa rajapintaa ja saada asynkronisen suorituksen tulostiedot Future-luokan kautta. Jos et välitä suoritustuloksesta, voit käyttää ajettavaa käyttöliittymää, koska se ei palauta tulosta, tietenkin kutsuttavuus on myös mahdollista, eikä meidän tarvitse saada tulevaisuutta.
Suosittu RPC-kehys
On edelleen monia suosittuja avoimen lähdekoodin RPC-kehyksiä. Tässä kolme kohokohtaa:
- gRPC on Googlen äskettäin julkistama avoimen lähdekoodin ohjelmisto, joka perustuu uusimpaan HTTP 2.0 -protokollaan ja tukee monia yleisiä ohjelmointikieliä. Tiedämme, että HTTP 2.0 on päivitetty versio HTTP-protokollasta, joka perustuu binääriin, ja suuret selaimet tukevat sitä tällä hetkellä nopeasti. Tämä RPC-kehys perustuu HTTP-protokollaan, ja taustalla oleva kehys hyödyntää Netty-kehyksen tukea.
- Thrift on avoimen lähdekoodin projekti Facebookille, joka on ensisijaisesti monikielinen palvelukehys. Siinä on koodigeneraattori, joka automaattisesti generoi palvelukoodikehyksen IDL-määrittelytiedostolle, jonka se määrittelee. Käyttäjien tarvitsee suorittaa vain toissijainen kehitys ennen sitä, ja taustalla oleva RPC-viestintä on läpinäkyvää. Käyttäjille kuitenkin tietyn alan kielen oppiminen maksaa edelleen.
- Dubbo on tunnettu avoimen lähdekoodin RPC-kehys, jota Alibaba Group käyttää laajasti monissa internet-yrityksissä ja yrityssovelluksissa. Sekä protokollat että sarjallistamiskehykset voidaan kytkeä sisään. Sama etäkäyttöliittymä perustuu Java-rajapintaan ja perustuu kevään kehitykseen helpon kehityksen vuoksi. Se voidaan helposti paketoida yhdeksi tiedostoksi ja ajaa itsenäisesti, mikä on linjassa nykyisen mikropalveluiden käsitteen kanssa.
Salaa kerron, että ryhmä ei enää käytä dubboa paljon,Nykyään yleisemmin käytetty versio on nimeltään HSF, tunnetaan myös nimellä "niin mukava". Avoimen lähdekoodin sisältöä saattaa tulla myöhemmin, joten odotetaan ja katsotaan.
HTTP-palvelu
Itse asiassa olen jo kauan sitten luonnehtinut yrityskehitysmallia HTTP-rajapinnan kehitykseksi, jota usein kutsumme RESTful-tyylisiksi palvelurajapinnoiksi. Itse asiassa se on viestintämenetelmä, jota käytetään usein informaatiosaarekkeiden ratkaisemisen alkuvaiheessa, kun rajapintoja on vähän ja järjestelmien välillä on vähemmän vuorovaikutusta; Edut ovat yksinkertaisia, suoria ja helppoja kehittää. Käytä valmiita HTTP-protokollaa siirtoon. Muistamme, että kun teimme taustakehitystä yrityksessä, kehitimme pääasiassa rajapintoja ja meidän piti myös kirjoittaa suuri rajapintadokumentti, jossa tarkasti kerrottiin, mitä syöte ja tulos olivat. Selitä kunkin rajapinnan pyyntömenetelmä ja ne asiat, joihin tulee kiinnittää huomiota pyyntöparametreissa. Esimerkiksi seuraava esimerkki:
POSTIhttp://www.httpexample.com/restful/buyer/info/share
Rajapinta voi palauttaa JSON-merkkijonon tai XML-dokumentin. Asiakas käsittelee tämän palautetun tiedon, mikä nopeuttaa kehitystä. Kuitenkin suurille yrityksille, kun sisäisiä alijärjestelmiä ja rajapintoja on paljon, RPC-kehyksen edut tulevat esiin: ensinnäkin se on pitkä linkki, eikä tarvitse kätellä kolme kertaa kuten http joka kerta, mikä vähentää verkon ylikuormitusta; toiseksi RPC-kehyksessä on yleensä rekisteröintikeskus sekä rikas valvonta ja hallinta; Julkaiseminen, offline-rajapinnat, dynaaminen laajennus jne. ovat soittajalle ei-havaitsevia ja yhtenäisiä toimintoja.
yhteenveto
Yleisesti ottaen RPC-palvelut ovat pääasiassa suurille yrityksille, kun taas HTTP-palvelut ovat pääasiassa pienille yrityksille, koska RPC on tehokkaampi ja HTTP-palveluiden kehitysiteraatiot nopeampia. Lyhyesti sanottuna, millainen viitekehys valitaan, ei määräydy markkinoiden suositun perusteella, vaan koko projektin täydelliseen arviointiin, jotta kahden kehityskehyksen vaikutusta koko projektiin voidaan tarkasti verrata ja lopulta päättää, mikä on projektille parhaiten sopiva. Emme saa käyttää RPC:tä jokaisessa projektissa pelkästään RPC:n vuoksi, vaan sopeutua paikallisiin olosuhteisiin ja analysoida yksittäistä tilannetta.
|
Julkaistu 1.4.2019 14.02.45
|
|
|
|
