Olen varma, että otsikko aiheutti terveen reaktion - "No, se on taas alkanut..." Mutta anna minun vangita huomiosi 5-10 minuutiksi, ja yritän olla pettämättä odotuksiasi.
Artikkelin rakenne on seuraava: otetaan stereotyyppinen lausunto ja paljastetaan tämän stereotyypin syntymisen "luonne". Toivon, että tämä antaa sinun tarkastella projekteissasi tiedonvaihtoparadigman valintaa uudesta näkökulmasta.
Saadakseni selvää, mitä RPC on, ehdotan standardin harkitsemista . RESTillä ei ole mitään selkeyttä. Ja sen ei pitäisi olla. Kaikki mitä sinun tarvitsee tietää RESTistä - sitä ei voi erottaa .
RPC-pyynnöt ovat nopeampia ja tehokkaampia, koska niiden avulla voit tehdä eräpyyntöjä.
Pointti on, että RPC:ssä voit kutsua useita proseduureja kerralla yhdessä pyynnössä. Luo esimerkiksi käyttäjä, lisää hänelle avatar ja tilaa hänelle samassa pyynnöstä joitakin aiheita. Vain yksi pyyntö ja kuinka paljon hyötyä!
Itse asiassa, jos sinulla on vain yksi taustasolmu, se näyttää nopeammalta eräpyynnöllä. Koska kolme REST-pyyntöä vaatii kolme kertaa enemmän resursseja yhdeltä solmulta yhteyden muodostamiseen.
Huomaa, että REST:n tapauksessa ensimmäisen pyynnön on palautettava käyttäjätunnus, jotta myöhempiä pyyntöjä voidaan tehdä. Mikä myös vaikuttaa negatiivisesti kokonaistulokseen.
Mutta tällaisia infrastruktuureja löytyy vain talon sisäisistä ratkaisuista ja Enterprisesta. Viimeisenä keinona pienissä WEB-projekteissa. Mutta täysimittaisia WEB-ratkaisuja ja jopa HighLoad-nimiä ei kannata rakentaa. Niiden infrastruktuurin on täytettävä korkean käytettävyyden ja kuormituksen kriteerit. Ja kuva muuttuu.
Saman skenaarion mukaiset infrastruktuurin toimintakanavat on merkitty vihreällä. Huomaa, kuinka RPC käyttäytyy nyt. Pyyntö käyttää infrastruktuuria vain yhdellä jalalla tasapainottimesta taustajärjestelmään. Vaikka REST häviää edelleen ensimmäisessä pyynnössä, se korvaa menetetyn ajan käyttämällä koko infrastruktuuria.
Riittää, kun kirjoittaa käsikirjoitukseen ei kahta rikastuspyyntöä, vaan vaikkapa viisi tai kymmenen... ja vastaus kysymykseen "kuka voittaa nyt?" tulee epäselväksi.
Ehdotan, että tarkastellaan ongelmaa vielä laajemmin. Kaavio näyttää, kuinka infrastruktuurikanavia käytetään, mutta infrastruktuuri ei rajoitu kanaviin. Tärkeä osa suuren kuormituksen infrastruktuuria ovat välimuistit. Otetaan nyt jonkinlainen käyttäjän artefakti. Toistuvasti. Sanotaan 32 kertaa.
Katso, kuinka RPC-infrastruktuuri on parantunut merkittävästi vastaamaan suuren kuormituksen vaatimuksiin. Asia on, että REST käyttää HTTP-protokollan täyttä tehoa, toisin kuin RPC. Yllä olevassa kaaviossa tämä teho toteutetaan pyyntömenetelmällä - GET.
HTTP-menetelmillä on muun muassa välimuististrategioita. Löydät ne asiakirjoista osoitteessa . RPC:ssä käytetään POST-pyyntöjä, joita ei pidetä idempotenteina, eli samojen POST-pyyntöjen toistuminen voi palauttaa erilaisia tuloksia (esimerkiksi jokaisen kommentin lähettämisen jälkeen tästä kommentista tulee näkyviin toinen kopio) ().
Tämän seurauksena RPC ei pysty käyttämään tehokkaasti infrastruktuurin välimuistia. Tämä johtaa tarpeeseen "tuoda" ohjelmistovälimuistia. Kaaviossa Redis tässä roolissa. Ohjelmistovälimuisti puolestaan vaatii kehittäjää lisäämään ylimääräisen koodikerroksen ja arkkitehtuurissa havaittavia muutoksia.
Lasketaan nyt kuinka monta pyyntöä REST ja RPC "synnyttivät" tarkasteltavassa infrastruktuurissa?
pyynnöt
Saapuneet
backend
DBMS:ään
pehmeään välimuistiin (Redis)
YHTEENSÄ
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Ensimmäiseen järjestelmään verrattuna ero on silmiinpistävä. Nyt RESTin hyöty käy selväksi. Mutta suosittelen, ettet lopeta tähän. Kehitetty infrastruktuuri sisältää CDN:n. Usein se ratkaisee myös DDoS- ja DoS-hyökkäysten torjunnan. Saamme:
Täällä asiat menevät todella huonosti RPC: lle. RPC ei yksinkertaisesti pysty delegoimaan työkuormaa CDN:lle. Voimme luottaa vain järjestelmiin hyökkäyksiä vastaan.
Onko mahdollista lopettaa tähän? Ja taas, ei. HTTP-menetelmillä, kuten edellä mainittiin, on oma "taikansa". Eikä ole turhaa, että GET-menetelmää käytetään laajasti Internetissä. Huomaa, että tällä menetelmällä pääsee käsiksi sisältöön, se pystyy asettamaan ehtoja, jotka infrastruktuurielementit voivat tulkita ennen kuin ohjaus siirretään koodillesi, ja niin edelleen. Kaiken tämän avulla voit luoda joustavia, hallittavia infrastruktuureja, jotka voivat käsitellä todella suuria pyyntövirtoja. Mutta RPC:ssä tämä menetelmä... jätetään huomiotta.
Joten miksi myytti, että eräpyynnöt (RPC) ovat nopeampia, on niin jatkuva? Henkilökohtaisesti minusta vaikuttaa siltä, että useimmat projektit eivät yksinkertaisesti saavuta sitä kehitystasoa, jossa REST pystyy näyttämään vahvuutensa. Lisäksi pienissä projekteissa hän on halukkaampi näyttämään heikkoutensa.
REST:n tai RPC:n valinta ei ole projektissa olevan yksilön tahdonvoimainen valinta. Tämän valinnan on täytettävä hankkeen vaatimukset. Jos projekti pystyy puristamaan RESTistä kaiken, mitä se todella voi, ja se todella tarvitsee sitä, REST on erinomainen valinta.
Mutta jos haluat saada kaikki RESTin edut, sinun on palkattava projektiin devops-asiantuntijoita infrastruktuurin nopeaan skaalaamiseen, järjestelmänvalvojat infrastruktuurin hallintaan, arkkitehti suunnittelemaan kaikki WEB-palvelun tasot... ja projekti , samaan aikaan, myy kolme pakkausta margariinia päivässä... Minä pysyisin RPC:ssä, koska... tämä protokolla on hyödyllisempi. Se ei vaadi syvällistä tietämystä välimuistien ja infrastruktuurin toiminnasta, mutta se keskittyy kehittäjän yksinkertaisiin ja ymmärrettäviin kutsuihin hänen tarvitsemiinsa menettelyihin. Liike on onnellinen.
RPC-pyynnöt ovat luotettavampia, koska ne voivat suorittaa eräpyyntöjä yhdessä tapahtumassa
Tämä RPC:n ominaisuus on selvä etu, koska Tietokannan pitäminen yhtenäisenä on helppoa. Mutta RESTin kanssa se muuttuu yhä monimutkaisemmaksi. Pyynnöt voivat saapua epäjohdonmukaisesti eri taustasolmuihin.
Tämä RESTin "haitta" on sen edellä kuvatun edun kääntöpuoli - kyky käyttää tehokkaasti kaikkia infrastruktuurin resursseja. Jos infrastruktuuri on huonosti suunniteltu ja varsinkin projektin arkkitehtuuri ja erityisesti tietokanta ovat huonosti suunniteltuja, se on todella suuri tuska.
Mutta ovatko eräpyynnöt niin luotettavia kuin miltä ne näyttävät? Katsotaanpa tapausta: luomme käyttäjän, täydennämme hänen profiiliaan kuvauksella ja lähetämme hänelle salaisuuden sisältävän tekstiviestin rekisteröinnin viimeistelemiseksi. Nuo. kolme puhelua yhdessä eräpyynnössä.
Katsotaanpa kaaviota. Se esittelee infrastruktuurin, jossa on korkean käytettävyyden elementtejä. On kaksi itsenäistä viestintäkanavaa, joissa on SMS-yhdyskäytäviä. Mutta... mitä me näemme? Tekstiviestiä lähetettäessä tapahtuu virhe 503 - palvelu on tilapäisesti poissa käytöstä. Koska SMS-lähetys pakataan eräpyyntöön, jolloin koko pyyntö on palautettava. DBMS:n toiminnot peruutetaan. Asiakas saa virheilmoituksen.
Seuraava yritys on arpajaiset. Joko pyyntö osuu samaan solmuun uudestaan ja uudestaan palauttaa virheen tai olet onnekas ja se suoritetaan. Mutta pääasia on, että ainakin kerran infrastruktuurimme on jo toiminut turhaan. Kuorma oli, mutta voittoa ei ollut.
Okei, kuvitellaanpa, että jännitimme itseämme (!) ja mietimme vaihtoehtoa, milloin pyyntö voitaisiin osittain suorittaa onnistuneesti. Ja yritämme suorittaa loput uudelleen jonkin ajan kuluttua (kumpi? päättääkö etu?). Mutta lotto pysyi samana. Tekstiviestin lähetyspyynnöllä on 50/50 todennäköisyys epäonnistua uudelleen.
Samaa mieltä, asiakkaan puolelta palvelu ei vaikuta niin luotettavalta kuin haluaisimme... entä REST?
REST käyttää jälleen HTTP:n taikuutta, mutta nyt vastauskoodeilla. Kun SMS-yhdyskäytävässä tapahtuu virhe 503, taustaohjelma lähettää tämän virheen tasapainottimelle. Tasapainotin vastaanottaa tämän virheen ja katkaisematta yhteyttä asiakkaaseen lähettää pyynnön toiselle solmulle, joka käsittelee pyynnön onnistuneesti. Nuo. asiakas saa odotetun tuloksen ja infrastruktuuri vahvistaa korkean "hyvin saavutettavissa olevan" arvonsa. Käyttäjä on tyytyväinen.
Eikä tässä vielä kaikki. Tasapainotin ei vain saanut vastauskoodia 503. Standardin mukaisesti vastattaessa on suositeltavaa antaa tämä koodi "Retry-After" -otsikon kanssa. Otsikko tekee tasapainottajalle selväksi, että tätä solmua tällä reitillä ei kannata häiritä tietyksi ajaksi. Ja seuraavat tekstiviestin lähettämispyynnöt lähetetään suoraan solmuun, jolla ei ole ongelmia SMS-yhdyskäytävän kanssa.
Kuten näemme, JSON-RPC:n luotettavuus on yliarvostettua. Itse asiassa on helpompi järjestää johdonmukaisuus tietokannassa. Mutta tässä tapauksessa uhri on koko järjestelmän luotettavuus.
Päätelmä on pitkälti samanlainen kuin edellinen. Kun infrastruktuuri on yksinkertainen, JSON-RPC:n ilmeisyys on ehdottomasti plussaa. Jos projektiin liittyy korkea käytettävyys suurella kuormituksella, REST näyttää oikeammalta, vaikkakin monimutkaisemmalta ratkaisulta.
REST-tilaan pääsykynnys on matalampi
Uskon, että yllä oleva analyysi, joka kumoaa vakiintuneet stereotypiat RPC:stä, osoitti selvästi, että kynnys päästä REST:hen on epäilemättä korkeampi kuin RPC:hen. Tämä johtuu tarpeesta saada syvällinen ymmärrys HTTP:n toiminnasta, sekä tarpeesta saada riittävästi tietoa olemassa olevista infrastruktuurielementeistä, joita voidaan ja pitäisi käyttää WEB-projekteissa.
Joten miksi monet ihmiset ajattelevat, että REST on yksinkertaisempaa? Henkilökohtainen mielipiteeni on, että tämä näennäinen yksinkertaisuus tulee REST-ilmiöistä. Nuo. REST ei ole protokolla vaan konsepti... RESTillä ei ole standardia, siinä on joitain ohjeita... REST ei ole monimutkaisempi kuin HTTP. Näennäinen vapaus ja anarkia houkuttelevat "vapaita taiteilijoita".
REST ei tietenkään ole monimutkaisempi kuin HTTP. Mutta HTTP itsessään on hyvin suunniteltu protokolla, joka on osoittanut arvonsa vuosikymmenten ajan. Jos itse HTTP:stä ei ole syvällistä ymmärrystä, RESTiä ei voida arvioida.
Mutta RPC:stä - voit. Riittää, kun otat sen spesifikaation. Tarvitsetko siis ? Vai onko se silti hankala LOPAA? Sinä päätät.
Toivon vilpittömästi, etten ole hukannut aikaasi.
Lähde: will.com