Lange tijd heb ik het verschil tussen RPC (oftewel Remote Procedure Call) en HTTP-aanroepen niet gevonden. Laat me hier alsjeblieft lachen~Naïef! Dit artikel introduceert kort de twee vormen van C/S-architectuur, allereerst hun belangrijkste verschil, namelijk dat RPC voornamelijk gebaseerd is op het TCP/IP-protocol, terwijl HTTP-service voornamelijk gebaseerd is op het HTTP-protocol; we weten allemaal dat het HTTP-protocol bovenop het transportlaagprotocol TCP ligt, dus qua efficiëntie is RPC natuurlijk beter! Laten we het in detail hebben over RPC-diensten en HTTP-diensten.
OSI-netwerk zevenlaags model
Voordat ik het verschil tussen RPC en HTTP bespreek, vind ik het noodzakelijk om het zevenlaagse netwerkstructuurmodel van OSI te begrijpen (hoewel het in de praktijk in feite vijf lagen is), dat kan worden onderverdeeld in de volgende lagen: (van boven naar beneden)
- De eerste laag: applicatielaag. Interfaces voor communicatie en gegevensoverdracht in het netwerk zijn gedefinieerd;
- De tweede laag: de representatielaag. Het definiëren van het transmissieformaat, coderings- en decoderingsspecificaties van gegevens in verschillende systemen, enzovoort;
- De derde laag: de gesprekslaag. Beheer gebruikerssessies en controleer het tot stand brengen en onderbreken van logische verbindingen tussen gebruikers.
- De vierde laag: de transportlaag. Het beheert end-to-end datatransmissie in het netwerk;
- Laag 5: Netwerklaag. Definieer hoe data tussen netwerkapparaten wordt overgedragen;
- Zesde laag: linklaag. De datapakketten van de netwerklaag hierboven zijn ingekapseld in dataframes om de overdracht van de fysieke laag te vergemakkelijken.
- Laag 7: Fysieke laag. Deze laag draait vooral om het verzenden van deze binaire data.
In de praktijk is er geen presentatielaag en sessielaag in de vijflaagse protocolstructuur. Er moet gezegd worden dat ze samensmelten met de applicatielaag. We moeten ons richten op de applicatielaag en de transportlaag. Omdat HTTP een protocol op de applicatielaag is, terwijl TCP een protocol op de transportlaag is. Nu we het netwerk-layeringmodel kennen, begrijpen we beter waarom RPC-diensten mooier zijn dan HTTP-services!
RPC-diensten
RPC-diensten worden geïntroduceerd vanuit drie perspectieven: RPC-architectuur, synchrone asynchrone oproepen en populaire RPC-frameworks.
RPC-architectuur
Laten we het hebben over de basisarchitectuur van RPC-diensten. Laat me beschamend een beeld stelen~ We zien duidelijk dat een complete RPC-architectuur vier kerncomponenten bevat, namelijk Client, Server, Client Stub en Server Stub, die als een stub kunnen worden begrepen. Laten we het apart over deze componenten hebben:
- Klant, de beller van de dienst.
- Server, de echte dienstverlener.
- De client-stub slaat het adresbericht van de server op, verpakt vervolgens de verzoekparameters van de client in een netwerkbericht, waarna het via het netwerk op afstand naar de servicepartij wordt gestuurd.
- De serverzijde stub ontvangt berichten die door de client worden verzonden, pakt de berichten uit en roept lokale methoden aan.
RPC wordt voornamelijk gebruikt in grote ondernemingen, omdat grote ondernemingen veel systemen, complexe bedrijfslijnen hebben en efficiëntievoordelen zeer belangrijk zijn. Dit gebeurt in de daadwerkelijke ontwikkeling, en projecten worden meestal beheerd met Maven. We hebben bijvoorbeeld een systeemservice die bestellingen verwerkt, eerst alle interfaces declareert (hier specifiek de interface in Java), en vervolgens het hele project verpakt in een jar-pakket. Waarom doe je dit? Het belangrijkste doel is om de grootte van het jar-pakket aan de clientzijde te verkleinen, omdat elke keer dat een pakket wordt uitgebracht, te veel jar-pakketten altijd de efficiëntie beïnvloeden. Het ontkoppelt ook client en server om de codeportabiliteit te verbeteren.
Synchrone en asynchrone aanroepen
Wat is synchroon bellen? Wat is een asynchroon gesprek? Een synchrone aanroep is wanneer de client wacht tot de aanroep is voltooid en het resultaat teruggeeft. Asynchrone aanroepen betekenen dat de client niet wacht tot de oproep wordt uitgevoerd en het resultaat teruggeeft, maar toch de melding van het retourresultaat via de callback-functie kan ontvangen. Als de klant zich niet druk maakt om het resultaat, kan het een eenrichtingsgesprek worden. Dit proces lijkt enigszins op de aanroepbare en uitvoerbare interfaces in Java; wanneer we asynchroon uitvoeren, kunnen we, als we het resultaat van de uitvoering willen weten, de aanroepbare interface gebruiken en kunnen we de resultaatinformatie van asynchrone uitvoering via de Future-klasse verkrijgen. Als je niet geeft om het uitvoeringsresultaat, kun je gewoon de runnable interface gebruiken omdat die het resultaat niet teruggeeft, natuurlijk is callable ook mogelijk, we hoeven de toekomst niet te krijgen.
Populair RPC-framework
Er zijn nog steeds veel populaire open source RPC-frameworks. Hier zijn drie hoogtepunten:
- gRPC is een recent aangekondigde open-source software van Google, gebaseerd op het nieuwste HTTP 2.0-protocol, en ondersteunt veel veelvoorkomende programmeertalen. We weten dat HTTP 2.0 een verbeterde versie van het HTTP-protocol is gebaseerd op binaire code, en grote browsers ondersteunen dit momenteel in hoog tempo. Dit RPC-framework is gebaseerd op het HTTP-protocol, en de onderliggende maakt gebruik van de ondersteuning van het Netty-framework.
- Thrift is een open-source project voor Facebook, voornamelijk een cross-language service development framework. Het heeft een codegenerator om automatisch een servicecode-framework te genereren voor het IDL-definitiebestand dat het definieert. Gebruikers hoeven alleen secundaire ontwikkeling te doen voordat ze dit doen, en de onderliggende RPC-communicatie is transparant. Voor gebruikers zijn er echter nog steeds een zekere kosten om de taal van een specifiek vakgebied te leren.
- Dubbo is een bekend RPC-framework open source van Alibaba Group, dat veel wordt gebruikt in veel internetbedrijven en bedrijfsapplicaties. Zowel protocollen als serialisatieframeworks kunnen worden ingesloten. Dezelfde externe interface is gebaseerd op de Java Interface en maakt gebruik van het springframework voor eenvoudige ontwikkeling. Het kan eenvoudig in één bestand worden verpakt en onafhankelijk worden uitgevoerd, wat consistent is met het huidige concept van microservices.
Stiekem vertellen ze je dat de groep dubbo niet meer veel gebruikt,De methode die nu het meest wordt gebruikt, heet HSF, ook bekend als "zo comfortabel". Er kan later open source zijn, dus laten we afwachten.
HTTP-dienst
Sterker nog, lang geleden heb ik het enterprise-ontwikkelingsmodel altijd omschreven als HTTP-interfaceontwikkeling, wat we vaak RESTful-stijl service-interfaces noemen. Het is inderdaad een communicatiemethode die vaak wordt gebruikt in de vroege fase van het oplossen van informatie-eilanden in het geval van weinig interfaces en minder interactie tussen systemen; De voordelen zijn eenvoudig, direct en gemakkelijk te ontwikkelen. Gebruik het kant-en-klare HTTP-protocol voor verzending. We herinneren ons dat toen we eerder achtergrondontwikkeling deden bij het bedrijf, we vooral interfaces ontwikkelden, en we moesten ook een groot interfacedocument schrijven, waarin strikt werd aangegeven wat de input en output waren. Leg de aanvraagmethode van elke interface uit en de zaken waar aandacht aan besteed moet worden in de verzoekparameters. Bijvoorbeeld, het volgende voorbeeld:
VERZENDENhttp://www.httpexample.com/restful/buyer/info/share
De interface kan een JSON-string of een XML-document teruggeven. De client verwerkt vervolgens deze teruggegeven informatie, wat een snellere ontwikkeling mogelijk maakt. Voor grote ondernemingen echter, wanneer er veel interne subsystemen en interfaces zijn, worden de voordelen van het RPC-framework getoond; allereerst is het een lange verbinding en is het niet nodig om drie keer de hand te schudden zoals bij http, wat de netwerkoverhead vermindert; ten tweede beschikt het RPC-kader over het algemeen over een registratiecentrum en een rijk monitoring- en beheersysteem; Publiceren, offline interfaces, dynamische uitbreiding, enzovoort, zijn niet-perceptieve en uniforme bewerkingen voor de beller.
samenvatting
Over het algemeen zijn RPC-diensten vooral bedoeld voor grote ondernemingen, terwijl HTTP-diensten vooral voor kleine ondernemingen zijn, omdat RPC efficiënter is en HTTP-serviceontwikkelingsiteraties sneller zullen zijn. Kortom, welk soort kader gekozen wordt, wordt niet bepaald door wat populair is op de markt, maar door het volledig evalueren van het hele project, zodat de impact van de twee ontwikkelingsframeworks op het hele project zorgvuldig wordt vergeleken en uiteindelijk wordt bepaald wat het meest geschikt is voor het project. We mogen RPC niet voor elk project gebruiken om het gebruik van RPC, maar moeten ons aanpassen aan lokale omstandigheden en de specifieke situatie analyseren.
|
Geplaatst op 01-04-2019 14:02:45
|
|
|
|
