Дълго време не съм разбрал разликата между RPC (т.е. Remote Procedure Call) и HTTP повиквания. Моля, позволете ми да се посмея тук~Наивно! Тази статия накратко представя двете форми на C/S архитектура, първо, тяхната най-съществена разлика – RPC е основно базиран на TCP/IP протокол, докато HTTP услугата е основно базирана на HTTP протокол, всички знаем, че HTTP протоколът е върху протокола на транспортния слой TCP, така че по отношение на ефективността RPC е разбира се по-добър! Нека поговорим подробно за RPC услугите и HTTP услугите.
Седемслойният модел на OSI мрежата
Преди да говоря за разликата между RPC и HTTP, смятам, че е необходимо да се разбере седемслойният модел на мрежова структура на OSI (макар че на практика той е основно пет слоя), който може да се раздели на следните слоеве: (отгоре надолу)
- Първият слой: приложният слой. Дефинирани са интерфейси за комуникация и предаване на данни в мрежата;
- Вторият слой: слоят за представяне. Дефиниране на формата на предаване, спецификациите за кодиране и декодиране на данни в различни системи и др.;
- Третият слой: слоят на разговора. Управление на потребителските сесии и контрол върху установяването и прекъсването на логически връзки между потребителите.
- Четвъртият слой: транспортният слой. Той управлява предаването на данни от край до край в мрежата;
- Слой 5: Мрежов слой. Дефинирайте как се прехвърлят данни между мрежовите устройства;
- Шести слой: линк слой. Пакетите от мрежовия слой по-горе са капсулирани в рамките на данни, за да улеснят предаването на физическия слой.
- Слой 7: Физически слой. Този слой е основно за предаване на тези двоични данни.
На практика в петслойната протоколна структура няма слой за представяне и сесия. Трябва да се каже, че те се сливат с приложния слой. Трябва да се фокусираме върху приложния слой и транспортния слой. Защото HTTP е протокол на приложния слой, докато TCP е протокол на транспортния слой. Е, сега, когато знаем модела на мрежово наслагване, можем по-добре да разберем защо RPC услугите са по-добри от HTTP услугите!
Услуги на RPC
RPC услугите се въвеждат от три гледни точки: RPC архитектура, синхронни асинхронни повиквания и популярни RPC рамки.
RPC архитектура
Нека поговорим за основната архитектура на RPC услугите. Позволете ми срамно да открадна картина~ Ясно виждаме, че пълната RPC архитектура съдържа четири основни компонента, а именно Клиент, Сървър, Клиентски стъб и Сървърен стъб, които могат да се разбират като стъб. Нека поговорим за тези компоненти поотделно:
- Клиентът, обаждащият се на услугата.
- Сървърът, истинският доставчик на услуги.
- Клиентският stub съхранява адресното съобщение на сървъра, след което пакетира параметрите на заявката на клиента в мрежово съобщение и го изпраща дистанционно на обслужващата страна през мрежата.
- Сървърната страница получава съобщения, изпратени от клиента, разопакова съобщенията и извиква локални методи.
RPC се използва основно в големи предприятия, тъй като големите предприятия имат много системи, сложни бизнес линии и предимствата в ефективността са много важни. Това се прави при реална разработка, а проектите обикновено се управляват с помощта на Maven. Например, имаме системна услуга, която обработва поръчки, първо декларира всички свои интерфейси (тук конкретно интерфейса в Java), а след това пакетира целия проект в jar пакет. Защо го правиш? Основната цел е да се намали размерът на опаковката на буркана от страна на клиента, защото всеки път, когато даден пакет бъде пуснат, твърде много пакети винаги влияят на ефективността. Той също така отделя клиента и сървъра, за да подобри преносимостта на кода.
Синхронни и асинхронни повиквания
Какво е Синхронно повикване? Какво е асинхронен повик? Синхронно повикване е, когато клиентът чака изпълнението на повикването и връща резултата. Асинхронните повиквания означават, че клиентът не чака изпълнението на повикването и връщането на резултата, но все пак може да получи известие за връщания резултат чрез функцията за обратно повикване. Ако клиентът не се интересува от резултата, разговорът може да се превърне в еднопосочно обаждане. Този процес е донякъде подобен на извикваемите и изпълняваемите интерфейси в Java – когато изпълняваме асинхронно, ако трябва да знаем резултата от изпълнението, можем да използваме извикваемия интерфейс и можем да получим информация за резултатите от асинхронното изпълнение чрез класа Future. Ако не ви интересува резултатът от изпълнението, можете просто да използвате runnable интерфейса, защото не връща резултата, разбира се, callable също е възможен, не ни трябва да получаваме бъдещето.
Популярна RPC рамка
Все още има много популярни отворени RPC фреймуърци. Ето три акцента:
- gRPC е наскоро обявен софтуер с отворен код от Google, базиран на най-новия протокол HTTP 2.0, и поддържа много често срещани програмни езици. Знаем, че HTTP 2.0 е подобрена версия на HTTP протокола, базирана на бинарен, и големите браузъри в момента го поддържат с бързи темпове. Тази RPC рамка е базирана на HTTP протокола, а основната платформа използва поддръжката на Netty framework.
- Thrift е проект с отворен код за Facebook, основно рамка за разработка на услуги с различни езици. Той има генератор на код, който автоматично генерира рамка за код на услуга за дефиниционния файл на IDL, който дефинира. Потребителите трябва само да извършат вторична разработка преди това, а основната комуникация чрез RPC е прозрачна. Въпреки това, за потребителите все още има определена цена за изучаване на езика на определена област.
- Dubbo е добре позната RPC рамка с отворен код от Alibaba Group, която се използва широко в много интернет компании и корпоративни приложения. Могат да се включат както протоколи, така и рамки за сериализация. Същият отдалечен интерфейс е базиран на Java интерфейса и разчита на spring framework за лесна разработка. Може лесно да се опакова в един файл и да се стартира независимо, което е в съответствие с настоящата концепция за микроуслуги.
Тайно ти казвам, че групата вече не използва дуббо,Този, който сега се използва по-често, се нарича HSF, известен още като "толкова удобен". Възможно е да има отворен код по-късно, така че нека изчакаме и видим.
HTTP услуга
Всъщност, преди много време винаги съм характеризирал корпоративния модел на разработка като разработка на HTTP интерфейси, което често наричаме интерфейси в стил RESTful. Всъщност това е комуникационен метод, който често се използва в ранния етап на решаване на информационни острови при малко интерфейси и по-малко взаимодействие между системите; Предимствата са прости, директни и лесни за развитие. Използвайте готовия HTTP протокол за предаване. Спомняме си, че когато преди правехме фонова разработка в компанията, основно разработвахме интерфейси, а също така трябваше да пишем голям интерфейсен документ, който строго посочваше входните и изходните данни. Обяснете метода на заявка във всеки интерфейс и въпросите, на които трябва да се обърне внимание в параметрите на заявката. Например, следният пример:
СТЪЛБhttp://www.httpexample.com/restful/buyer/info/share
Интерфейсът може да връща JSON низ или XML документ. Клиентът обработва тази върната информация, което позволява по-бързо развитие. Въпреки това, за големите предприятия, когато има много вътрешни подсистеми и много интерфейси, се показват предимствата на RPC рамката – първо, тя е дълга връзка и няма нужда да се ръкувате три пъти като при http всеки път, което намалява натоварването на мрежата; второ, рамката на RPC обикновено разполага с регистрационен център и богат мониторинг и управление; Публикуването, офлайн интерфейсите, динамичното разширяване и др. са невъзприемащи и унифицирани операции за обаждащия се.
резюме
Общо взето, RPC услугите са основно за големи предприятия, докато HTTP услугите са предимно за малки предприятия, защото RPC е по-ефективен и итерациите на разработка на HTTP услуги ще бъдат по-бързи. Накратко, какъв тип рамка да се избере не се определя от това, което е популярно на пазара, а от цялостната оценка на целия проект, така че внимателно да се сравни въздействието на двете рамки за разработка върху целия проект и накрая да се реши кое е най-подходящо за проекта. Не трябва да използваме RPC за всеки проект само заради използването на RPC, а да се адаптираме към местните условия и да анализираме конкретната ситуация.
|
Публикувано в 1.04.2019 г. 14:02:45 ч.
|
|
|
|
