Hosszú ideje nem értettem meg a különbséget az RPC (azaz Remote Procedure Call) és a HTTP hívások között. Kérlek, engedj meg, hogy nevessek itt~Naiv! Ez a cikk röviden bemutatja a C/S architektúra két formáját, először is, a legfontosabb különbséget, vagyis az RPC főként TCP/IP protokollon alapul, míg a HTTP szolgáltatás főként HTTP protokollon alapul, mindannyian tudjuk, hogy a HTTP protokoll a TCP transzportréteg protokoll fölött van, így hatékonyság szempontjából az RPC természetesen jobb! Beszéljünk részletesebben az RPC és HTTP szolgáltatásokról.
OSI hálózati hétrétegű modell
Mielőtt az RPC és a HTTP közötti különbségről beszélnénk, szükségesnek érzem megérteni az OSI hét rétegű hálózati szerkezeti modelljét (bár gyakorlatban alapvetően öt réteg), amely a következő rétegekre osztható: (felülről lefelé)
- Az első réteg: az alkalmazási réteg. A hálózatban a kommunikációs és adatátviteli interfészek definiálódnak;
- A második réteg: a reprezentációs réteg. Határozzák meg az átviteli formátumot, az adatok kódolását és dekódolását különböző rendszerekben, stb.;
- A harmadik réteg: a beszélgetés rétege. Kezelje a felhasználói üléseket, és irányítsa a logikai kapcsolatok létrehozását és megszakítását a felhasználók között.
- A negyedik réteg: a szállító réteg. A hálózaton belüli végpont–végpontok adatátvitelt kezeli;
- 5. réteg: Hálózati réteg. Határozzuk meg, hogyan kerülnek adatátvitel hálózati eszközök között;
- Hatodik réteg: link réteg. A fenti hálózati réteg adatcsomagjai adatkeretekbe vannak kapszulálva, hogy megkönnyítsék a fizikai réteg továbbítását.
- 7. réteg: Fizikai réteg. Ez a réteg főként a bináris adatok továbbítására szolgál.
Gyakorlati alkalmazásban nincs bemutatási és ülés réteg az ötrétegű protokollstruktúrában. Meg kell mondani, hogy ezek egyesülnek az alkalmazási réteggel. A alkalmazási rétegre és a szállítási rétegre kell koncentrálnunk. Mert a HTTP egy alkalmazásréteg protokoll, míg a TCP egy transzfer réteg protokoll. Nos, most, hogy ismerjük a hálózati rétegezési modellt, jobban megértjük, miért szebbek az RPC szolgáltatások, mint a HTTP szolgáltatások!
RPC szolgáltatások
Az RPC szolgáltatásokat három nézőpontból vezetik be: RPC architektúra, szinkron aszinkron hívások és népszerű RPC keretrendszerek.
RPC architektúra
Beszéljünk az RPC szolgáltatások alapvető architektúrájáról. Engedd meg, hogy szégyenkezettel ellopjam a képet~ Egyértelműen látjuk, hogy egy teljes RPC architektúra négy alapvető komponensből áll: Kliens, Szerver, Kliens Stub és Szerver Stub, ami érthető stubként. Beszéljük ezeket az összetevőket külön-külön:
- Ügyfél, a szolgáltatás hívója.
- Szerver, az igazi szolgáltató.
- A kliens stub tárolja a szerver címüzenetét, majd a kliens kérésparamétereit hálózati üzenetbe csomagolja, majd távolról továbbítja a szolgáltató félnek a hálózaton keresztül.
- A szerveroldali csoda fogadja az ügyfél által küldött üzeneteket, kibontja azokat, és helyi metódusokat hív.
Az RPC-t főként nagyvállalatoknál használják, mert a nagyvállalatoknak sok rendszere, összetett üzleti iránya és hatékonysági előnyei nagyon fontosak. Ez tényleges fejlesztés közben történik, és a projekteket általában mavennel kezelik. Például van egy rendszerszolgáltatásunk, amely a megrendeléseket feldolgozza, először minden interfészét (itt kifejezetten a Java interfészét) deklarálja, majd az egész projektet egy jar csomagba csomagolja. Miért csinálod ezt? A fő cél az, hogy csökkentsék a jar csomag méretét az ügyféloldalon, mert minden alkalommal, amikor egy csomagot kiadnak, a túl sok jar csomag mindig befolyásolja a hatékonyságot. Emellett szétválasztja a klienst és a szervert, hogy javítsa a kód hordozhatóságát.
Szinkron és aszinkron hívások
Mi az a szinkron hívás? Mi az aszinkron hívás? A szinkron hívás az a helyzet, amikor a kliens megvárja, hogy a hívás befejeződjön a végrehajtásra, és visszaadja az eredményt. Az aszinkron hívások azt jelentik, hogy a kliens nem várja meg a hívás végrehajtására és visszaküldését, de a visszahívás függvényen keresztül még mindig megkaphatja a visszahívás eredményéről szóló értesítést. Ha az ügyfél nem törődik az eredménysel, az egyirányú hívássá válhat. Ez a folyamat némileg hasonlít a Java hívható és futtatható interfészeire: amikor aszinkron módon futtatjuk, ha tudni kell a végrehajtás eredményét, használhatjuk a hívható interfészt, és a Future osztályon keresztül szerezzük meg az aszinkron végrehajtás eredményinformációit. Ha nem érdekel a végrehajtási eredmény, használhatod a futtatható felületet, mert az nem adja vissza az eredményt, persze hívható is lehetséges, nem kell a jövőt kapnunk.
Népszerű RPC keretrendszer
Még mindig sok népszerű nyílt forráskódú RPC keretrendszer létezik. Íme három kiemelt pont:
- A gRPC egy nemrégiben bejelentett nyílt forráskódú szoftver a Google által, amely a legújabb HTTP 2.0 protokollon alapul, és számos gyakori programozási nyelvet támogat. Tudjuk, hogy a HTTP 2.0 a bináris alapú HTTP protokoll továbbfejlesztett változata, és a nagy böngészők jelenleg gyorsan támogatják. Ez az RPC keretrendszer a HTTP protokollon alapul, és az alap a Netty keretrendszer támogatását használja.
- A Thrift egy nyílt forráskódú projekt a Facebook számára, elsősorban egy több nyelvű szolgáltatásfejlesztési keretrendszer. Van egy kódgenerátora, amely automatikusan generál egy szolgáltatási kód keretrendszert az általa meghatározott IDL definíciós fájlhoz. A felhasználóknak csak másodlagos fejlesztést kell végrehajtaniuk, és az alap RPC kommunikáció átlátható. Azonban a felhasználók számára még mindig van bizonyos költség egy adott terület nyelvének elsajátításának.
- A Dubbo egy jól ismert RPC keretrendszer, nyílt forráskódú az Alibaba Group-tól, amelyet széles körben használnak számos internetes cég és vállalati alkalmazás. Mind protokollok, mind sorozatos keretrendszerek bedughatók. Ugyanez a távoli felület a Java Interface-en alapul, és a Spring Framework-re támaszkodik az egyszerű fejlesztés érdekében. Könnyen csomagolható egyetlen fájlba és önállóan futtatható, ami összhangban áll a jelenlegi mikroszolgáltatások koncepciójával.
Titokban azt mondom, hogy a csoport már nem sokat használ dubbót,A leggyakrabban használt változatot ma HSF-nek hívják, más néven "so comfortable". Lehet, hogy később nyílt forráskódú lesz, szóval várjunk és meglátjuk.
HTTP szolgáltatás
Valójában régen mindig is a vállalati fejlesztési modellt HTTP interfész fejlesztésként jellemeztem, amit gyakran RESTful stílusú szolgáltatási interfészeknek hívunk. Valójában ez egy kommunikációs módszer, amelyet gyakran használnak az információszigetek korai szakaszában, kevés interfész és kevesebb interakció esetén a rendszerek között; Az előnyök egyszerűek, közvetlen és könnyen fejleszthetők. Használd a kész HTTP protokollt az átvitelhez. Emlékszünk, hogy amikor korábban háttérfejlesztést végeztünk a cégnél, főleg interfészeket fejlesztettünk, és egy nagy interfészdokumentumot is kellett írnunk, amely szigorúan megjelölte, hogy mik a bemenet és a kimenet. Magyarázza el az egyes interfészek kérési módszerét, valamint azokat a kérdéseket, amelyekre figyelni kell a kérésparaméterekben. Például a következő példa:
POSTAhttp://www.httpexample.com/restful/buyer/info/share
Az interfész visszavezethet JSON stringet vagy XML dokumentumot. Az ügyfél ezután feldolgozza ezt a visszaküldött információt, ami gyorsabb fejlesztést tesz lehetővé. Azonban nagy vállalatoknál, amikor sok belső alrendszer és sok interfész van, az RPC keretrendszer előnyei megmutatkoznak: először is, hosszú kapcsolat, és nincs szükség háromszor kezfogásra, mint a http minden alkalommal, így csökkentve a hálózati terhelést; másodszor, az RPC keretrendszere általában rendelkezik egy regisztrációs központtal, valamint gazdag monitorozással és menedzsmenttel; A publikálás, offline interfészek, dinamikus bővítés stb. nem észlelő és egységes műveletek a hívó számára.
összefoglalás
Általánosságban az RPC szolgáltatások főként nagyvállalatoknak, míg a HTTP szolgáltatások főként kisvállalkozásoknak, mert az RPC hatékonyabb, és a HTTP szolgáltatásfejlesztési iterációk gyorsabbak lesznek. Röviden, hogy milyen keretrendszert válasszunk, nem az határozza meg, mi népszerű a piacon, hanem hogy az egész projektet teljes egészében értékeljük, hogy alaposan összehasonlítsuk a két fejlesztési keretrendszer hatását az egész projektre, és végül eldöntsük, melyik a legmegfelelőbb a projekthez. Nem szabad minden projektre az RPC-t használni az RPC használata érdekében, hanem alkalmazkodnunk kell a helyi körülményekhez és elemeznünk a konkrét helyzetet.
|
Közzétéve 2019. 04. 01. 14:02:45
|
|
|
|
