Для чего нужен rpc
Удаленные процедуры: вызов удаленных процедур, определение и особенности
Многие пользователи компьютерных систем слышали о таких понятиях, как удаленные процедуры, вызов удаленных процедур или RPC. Вот только далеко не все представляют себе, что это за технологии, как они работают и для чего нужны. А ведь многие из тех, кто отключил данную службу в Windows-системах, зачастую могут получать и ошибки, относящиеся к критическим сбоям. Об этом и многом другом далее пойдет речь.
Удаленный вызов процедур: что это?
Начать стоит с некоторых теоретических сведений. Как считается, удаленные процедуры (вызов удаленных процедур) – это механизм, позволяющий запускать или использовать какие-либо функции компьютерных систем в отличном от используемого терминала адресном пространстве. Проще говоря, это способ доступа к удаленному компьютеру, например, через локальную сеть или интернет-подключение.
Однако удаленные процедуры (вызов удаленных процедур), обозначаемые как RPC (сокращение от английского Remote Procedure Call), можно отнести не только к удаленным компьютерам. На локальном уровне такие технологии тоже применяются. В качестве простейшего примера можно привести вызов определенной функции одной программы из другого приложения посредством взаимодействия через специальные библиотеки.
Кроме того, абсолютно во всех версиях Windows имеется такая служба, а при ее отключении или отказе работоспособности модификация XP не работает вообще.
Принцип действия
Как правило, служба «Удаленный вызов процедур RPC» для работы в режиме клиент-сервер требует наличия как минимум двух основных компонентов: сетевого протокола для обмена данными и языка сериализации (перевода какого-то процесса или информационной структуры данных в битовую последовательность).
Архитектуры могут быть совершенно разными и отличающимися по своим возможностям. Но для обмена данными на так называемом транспортном уровне чаще всего применяются протоколы UDP и TCP, реже – HTTP.
Чтобы не вдаваться в технические аспекты, самым простым объяснением принципа работы таких технологий может стать следующие пример: клиентский процесс формирует запрос серверу с описанием выбранной процедуры с указанными параметрами и отправляет его, после чего сервер выполняет требуемую директиву и отправляет клиенту ответ, который отображается на клиентской машине. Однако сам серверный обработчик находится, так сказать, в режиме ожидания и активируется только в моменты получения клиентских запросов. При этом совсем не обязательно, чтобы выполнение схемы «запрос-ответ» производилось немедленно.
При этом максимальный эффект производительности достигается при обмене относительно малыми объемами данных и небольшим временем отклика компонентов, между которыми установлена интерактивная связь.
Удаленные процедуры (вызов удаленных процедур): характерные черты и реализации
Таким образом, можно выделить две главные особенности названных технологий:
Что же касается реализаций, удаленные процедуры (вызов удаленных процедур) сегодня используют несколько базовых технологий, среди которых наиболее широко применяются следующие:
Проблемы и задачи
Теперь несколько слов о недостатках. Самая главная проблема, а соответственно, и задача реализации, состоит в том, что одна и та же операция вызова удаленной процедуры через узел службы «Удаленный вызов процедур» должна одновременно выполняться на разных машинах, причем зачастую с различными операционными системами, адресными пространствами и архитектурой. В процессе данные параметров должны копироваться с одного терминала на другой. Для этого используется не только транспортный протокол, но и сериализация, позволяющая преобразовать в байтовую последовательность разные типы данных.
Второй момент связан с тем, что удаленные процедуры (вызов удаленных процедур) используют не один процесс, как на локальном уровне, а два (на клиентской машине и на сервере). Посему аварийное завершение программы на одном из терминалов может вызвать такую же реакцию и на другом.
Наконец, одной из основных называется проблема совместимости ввиду неоднородности некоторых языков программирования, несмотря даже на установленные единые стандарты.
Основные типы подсистем
Удаленный вызов процедур Windows 10 или любой другой системы рангом ниже подразумевает использование специальных подсистем:
Какие типы программ требуют выполнения RPC?
Если же говорить о том, какие программные модули операционных систем требуют держать службу RPC включенной, все их перечислить просто невозможно.
Но среди всем известных компонентов Windows-систем можно отметить службу факсов, службы криптографии, регистрацию ошибок, справку и поддержку, доступ к устройствам HID, службу сообщений (Messenger), администрирование дисков и логических разделов, управление съемными накопителями, аудиосистему, установщик Windows и еще бог весть что.
Думается, этого списка достаточно, чтобы понять, насколько многие компоненты системы, да и сам пользователь, зависимы от этой службы.
На что влияет RPC
Вообще, исходя из предыдущего описания, можно оценить влияние RPC. Так, например, известно немало случаев, когда при отключении этой службы полностью пропадал звук, невозможным оказывалось восстановление системы после критических сбоев или инициированное пользователем, «слетали» настройки беспроводной сети.
Но самое печальное состоит в том, что, если отключить удаленный вызов процедур RPC, иногда бывает невозможно даже получить доступ к основным настройкам системы, будь пользователь хоть трижды администратором на собственном терминале.
Можно ли отключить эту службу
По большому счету, многие пытались (и пытаются) службу «Удаленный вызов процедур» отключить. Делать это категорически запрещается. В общем-то, и сама система при осуществлении такой попытки сделать этого не даст, выдав соответствующее уведомление.
Но не все знают, что в разделе службы (services.msc) есть еще такая штука, как «Локатор удаленного вызова процедур RPC». Вот его-то как раз и можно отключить безболезненно для системы. Приложения, которые могут его использовать в своей работе, самостоятельно вызовут сервис при необходимости.
Устранение сбоев и ошибок
Наконец, посмотрим, что можно сделать, если выдается ошибка при удаленном вызове процедуры. В самом простом случае можно попытаться включить службу заново (если, конечно, получится).
Для этого в соответствующем разделе, где находится искомая служба, двойным кликом вызывается меню редактирования параметров, нажимается кнопка включения, а сам тип включения устанавливается на автоматический. Если проделать такую процедуру при стандартной загрузке системы не представляется возможным, можно попытаться произвести аналогичные действия в безопасном режиме. Некоторые специалисты советуют заодно на время проведения действий на всякий случай отключить антивирусное ПО.
Если это не поможет, но под рукой имеется установочный или восстановительный диск системы, можно запустить командную консоль с правами администратора (загружаться с диска не нужно) и прописать в ней такие команды:
После этого запускаем «Диспетчер задач» (Ctrl + Del + Alt или taskmgr в меню «Выполнить») и завершаем процесс Explorer.exe.
Далее в командной консоли прописываем следующее: copy %TEMP%\explorer.exe %SYSTEMROOT% /y.
В «Диспетчере» останавливаем все процессы svhost.exe, после чего в течение 60 секунд нужно успеть в командой строке ввести строку copy %TEMP%\svchost.exe %systemroot%\system32 /y.
Наконец, если есть доступ к редактору системного реестра (regedit) восстановлен, нужно пройти по ветке HKCC через разделы SYSTEM и CurrentControlSet и добраться до параметра CSConfigFlags, изменив его значение на ноль.
Это далеко не все методы исправления ошибок, связанных с RPC. Дело в том, что, если эта служба повлекла за собой нарущения в работе других сервисов, возможно, сначала придется устранять проблемы с их работоспособностью, а только потом предпринимать какие-то действия в отношении RPC. И не всегда к вышеописанным параметрам и настройкам можно получить полный доступ. Если уж совсем ничего не получится, как это ни плачевно звучит, придется полностью переустанавливать операционную систему, хотя хочется надеяться, что до этого дело не дойдет.
Заключение
Вот кратко и все, что касается технологии и службы RPC. На самом деле все это выглядит намного сложнее, нежели было представлено в данном описании, и для полного понимания вопроса необходимо обладать хотя бы начальными знаниями. Но для того, чтобы иметь об RPC общее представление, этого пока достаточно.
Что же касается отключения, не вздумайте заниматься подобными вещами, иначе вся система откажет. Приведенные решение по исправлению сбоев обычно помогают, но полной гарантии все равно дать нельзя, ведь деактивация службы могла вызвать сбои и в других компонентах.
Remote Procedure Call
Remote Procedure Call
Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC) ) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).
Содержание
Реализации
Существуют множество технологий, обеспечивающих RPC:
Принцип
Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова локальных процедур являются:
Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:
Подсистемы
— управление исходящими и входящими соединениями. — поддержка понятия «граница сообщения» для транспортных протоколов, не поддерживающих его непосредственно (TCP). — поддержка гарантированной доставки для транспортных протоколов, не поддерживающих ее непосредственно (UDP).
В некоторых реализациях RPC (.NET Remoting) границы подсистем являются открытыми полиморфными интерфейсами, и возможно написать свою реализацию почти всех перечисленных подсистем. В других реализациях (DCE RPC в Windows) это не так.
См. также
Вызов удаленных процедур (RPC) Концепция удаленного вызова процедур
Идея вызова удаленных процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова локальных процедур являются:
Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут «осиротевшими», а при аварийном завершении удаленных процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.
Кроме того, существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем. Базовые операции RPC
Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов
count=read (fd, buf, nbytes);
где fd — целое число, buf — массив символов, nbytes — целое число.
Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.
Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.
Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.
Решение о том, какой механизм передачи параметров использовать, принимается разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке С, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.
Применение
Значительная часть инструментов удаленного управления операционной системой Windows (Event Viewer, Server Manager, управление печатью, списками пользователей) использует DCE RPC как средство общения по сети между управляемой службой и управляющим приложением пользовательского интерфейса. Поддержка DCE RPC присутствовала в Windows NT с самой первой версии 3.1. Клиенты DCE RPC поддерживались и в облегченной линии операционных системы Windows 3.x/95/98/Me.
Системные библиотеки Windows, предоставляющие возможности такого управления и служашие базовым уровнем для управляюших приложений пользовательского интерфейса (netapi32.dll и отчасти advapi32.dll), на деле содержат в себе клиентский код интерфейсов DCE RPC, осуществляющих это управление.
Это архитектурное решение было предметом активной критики в адрес Microsoft. Универсальные процедуры маршаллинга, присутствующие в DCE RPC, очень сложны и имеют огромный потенциал наличия дефектов, эксплуатируемых в сети путем посылки умышленно искаженного пакета DCE RPC. Значительная часть дефектов безопасности Windows, обнаруженных с конца 90-х до середины 2000-х годов, представляла собой именно ошибки в коде маршаллинга DCE RPC.
Помимо DCE RPC, в Windows активно применяется технология DCOM. Так, например, она используется как средство общения между инструментами управления веб-сервером IIS и собственно управляемым сервером. Полнофункциональный интерфейс общения с почтовой системой MS Exchange Server — MAPI — также основан на DCOM.
Как работает RPC
Средства удаленного вызова процедур делают его пользователям, как будто клиент напрямую вызывает процедуру, расположенную в удаленной серверной программе. У каждого клиента и сервера есть свои адресные пространства; то есть каждый из них имеет свой собственный ресурс памяти, выделенный для данных, используемых процедурой. На следующем рисунке показана архитектура RPC.
Как показано на рисунке, клиентское приложение вызывает локальную процедуру-заглушку вместо фактического кода, реализующего процедуру. Заглушки компилируются и связываются с клиентским приложением. Вместо того, чтобы содержать фактический код, реализующий удаленную процедуру, код заглушки клиента:
Для вызова удаленной процедуры сервер выполняет следующие действия.
Затем выполняется удаленная процедура, которая, возможно, создает выходные параметры и возвращаемое значение. После завершения удаленной процедуры аналогичная последовательность действий возвращает клиенту данные.
Клиент завершает процесс, принимая данные по сети и возвращая их вызывающей функции.
Библиотеки времени выполнения предоставляются в двух частях: библиотеку импорта, которая связана с приложением и библиотекой времени выполнения RPC, которая реализована как библиотека динамической компоновки (DLL).
Серверное приложение содержит вызовы функций библиотеки времени выполнения сервера, которые регистрируют интерфейс сервера и позволяют серверу принимать удаленные вызовы процедур. Серверное приложение также содержит удаленные процедуры, связанные с конкретным приложением, которые вызываются клиентскими приложениями.
Русские Блоги
Введение в основы RPC: введение в принципы и простые примеры
1. RPC
1. Что такое RPC
2. Зачем использовать RPC?
Фактически это обусловлено высоким спросом на разработку приложений до определенной стадии.
1. Если мы разрабатываем простое одиночное приложение, логика проста, пользователей не так много, а трафик не велик, тогда нам это не нужно;
2. Когда число посещений нашей системы увеличивается, бизнес растет, и мы обнаружим, что один компьютер с этой системой больше не может себе позволить. В настоящее время мы можем разделить бизнес на несколькоНесвязанные приложенияОтдельно развернуты на своих соответствующих машинах для уточнения логики и снижения давления. В это время нам также может не понадобиться RPC, поскольку приложения не связаны друг с другом.
3. Естественно, когда у нас будет все больше и больше приложений и все больше и больше приложений, мы обнаружим, что некоторые функцииНельзя легко разделить или нет, В это время общедоступная бизнес-логика может быть извлечена и объединена в независимое сервисное приложение службы. Как исходные, так и вновь добавленные приложения могут взаимодействовать с этими независимыми приложениями-службами для выполнения полных бизнес-функций. Так что в это время нам срочно нужноЭффективное средство связи между приложениямиКак видите, для того, чтобы удовлетворить эту потребность, пришло время RPC показать свою силу!
На самом деле сценарий, описанный в 3, также Сервис, микросервис сАрхитектура распределенной системы Основная сцена. Таким образом, структура RPC является мощным способом достижения вышеуказанной структуры.
Во-вторых, принцип и рамки RPC
В документе Нельсона указывалось, что процедура внедрения СРП состоит из пяти частей:
Соотношение между этими пятью частями показано на рисунке ниже
Здесь пользователь является клиентской стороной, когда пользователь хочет инициировать удаленный вызов, он фактически вызывается локальноuser-stub, Пользовательская заглушка отвечает за кодирование вызываемых интерфейсов, методов и параметров через согласованные спецификации протокола и передачу их удаленному экземпляру через локальный экземпляр RPCRuntime. После получения запроса удаленный экземпляр RPCRuntime передает его заглушке на сервер для декодирования и инициирует локальный вызов, и результат вызова возвращается пользователю.
Крупнозернистый RPC реализует концептуальную структуру, здесь мы дополнительно уточним, из каких компонентов он должен состоять, как показано на следующем рисунке.
Сервер RPC использует RpcServer для экспорта метода удаленного интерфейса, а клиент использует RpcClient для импорта метода удаленного интерфейса. Клиент вызывает метод удаленного интерфейса, как локальный метод. Структура RPC обеспечивает реализацию интерфейса через прокси. Фактический вызов будет делегирован прокси RpcProxy. Агент инкапсулирует информацию о вызове и перенаправляет вызов в RpcInvoker для фактического выполнения. RpcInvoker на клиенте поддерживает канал RpcChannel с сервером через соединитель RpcConnector и использует RpcProtocol для выполнения кодирования (кодирования) протокола и отправляет закодированное сообщение запроса на сервер через канал.
Приемник RpcAcceptor сервера RPC получает запрос вызова клиента, а также использует RpcProtocol для выполнения декодирования (декодирования) протокола. Декодированная информация о вызове передается в RpcProcessor для управления процессом вызова, и, наконец, вызов делегируется в RpcInvoker для фактического выполнения и возврата результата вызова. Ниже приведены подробные обязанности каждой части:
1. RpcServer
Ответственный за экспорт (экспорт) удаленного интерфейса
2. RpcClient
Реализация прокси, отвечающая за импорт удаленных интерфейсов
3. RpcProxy
Прокси-реализация удаленного интерфейса
4. RpcInvoker
Реализация клиента: отвечает за кодирование информации о вызове и отправку запроса вызова на сервер и ожидание возврата результата вызова
Реализация сервера: отвечает за вызов конкретной реализации интерфейса сервера и возврат результата вызова
5. RpcProtocol
Ответственный за протокол кодирования / декодирования
6. RpcConnector
Отвечает за поддержание канала связи между клиентом и стороной обслуживания и отправку данных стороне обслуживания
7. RpcAcceptor
Отвечает за получение клиентских запросов и возврат результатов запроса.
8. RpcProcessor
Он отвечает за управление вызывающим процессом на стороне службы, включая управление пулом вызывающих потоков, временем ожидания и т. Д.
9. RpcChannel
Канал передачи данных
В-третьих, обычно используемая среда RPC в Java
Текущая обычно используемая среда RPC выглядит следующим образом:
3. Spring Cloud Spring Cloud состоит из множества подпроектов, таких как Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul и т. Д., Которые предоставляют инструменты, обычно используемые для создания распределенных систем и микросервисов, такие как управление конфигурацией, обнаружение служб, прерыватели цепи, интеллектуальная маршрутизация, Прокси, шина управления, одноразовый токен, глобальная блокировка, выбор мастера, распределенный сеанс и состояние кластера и т. Д. Соответствуют всем решениям, необходимым для построения микросервисов. Spring Cloud основан на Spring Boot, что делает разработку и развертывание чрезвычайно простыми.
В-четвертых, разница между RPC и очередью сообщений
1. Функциональные различия
В архитектуре разница между RPC и Message заключается в том, что Message имеет очередь сообщений промежуточного узла, которая может хранить сообщения.
Особенности сообщения
1. Очередь сообщений сохраняет давление запроса и постепенно освобождает его, позволяя процессору обрабатывать его в своем темпе.
2. Очередь сообщений вводит новый узел. Надежность системы будет зависеть от узла очереди сообщений.
3. Очередь сообщений Асинхронный односторонний Новости. Отправка сообщений разработана таким образом, что нет необходимости ждать завершения обработки сообщения.
Так что для Синхронный возврат Использование очереди сообщений становится проблематичным.
Особенности RPC
Синхронный вызов. Для сценариев, в которых вы хотите дождаться возвращаемого результата / результата обработки, RPC является очень естественным и интуитивно понятным способом (RPC также может быть асинхронным вызовом).
В результате ожидания Consumer (клиент) будет потреблять потоки. При использовании в асинхронном RPC потребление потоков клиента (клиента) может быть устранено. Тем не менее, невозможно временно хранить сообщения / запросы, такие как сообщения, и давление будет напрямую передано поставщику услуг.
2. Различия в применимых случаях
1. RPC подходит, если вы хотите получить результат синхронно.
2. Если вы хотите использовать простой, то RPC; операция RPC основана на простом в использовании интерфейсе, используйте режим для имитации локальных вызовов. Программирование в асинхронном режиме является более сложным.
3. Не хочу отправителя (получатель RPC, отправитель сообщения) Ограничено стороной обработки (RPC Provider, Message Receiver), используйте очередь сообщений.
По мере роста бизнеса некоторые вычислительные мощности станут узким местом и будут продолжаться Синхронный вызов асинхронного сообщения Ремонт. Такая трансформация фактически меняет способ использования бизнеса. Например, после отправки исходной страницы операции на следующей странице будет показан результат обработки, а после преобразования асинхронного сообщения следующая страница станет «операция отправлена, и вы получите уведомление о ее завершении».
3. Описание неподходящих случаев
1. Синхронный вызов RPC использует очередь сообщений для передачи информации о вызове. Приведенный выше анализ показывает, что таким образом отправитель ожидает, занимая промежуточную точку ресурсов. Это становится сложным, но нет эквивалентного усиления.
2. Для вызова, возвращаемое значение которого равно void, вы можете сделать это, потому что фактически этому бизнесу вызовов часто не нужно получать результат обработки синхронно, если он может быть обработан. (Метод RPC может гарантировать, что вызов возвращается и обработка завершена. Это невозможно гарантировать после использования метода сообщения.)
3. Возвращаемое значение является вызовом void и используется сообщение. По сути, метод использования сообщения Wrap становится вызовом службы (метод использования вызова службы прост, основан на бизнес-интерфейсе).
V. Основные технические аспекты структуры RPC
Несколько основных технических моментов, реализованных в рамках RPC:
(1) Сервисное воздействие:
Удаленный поставщик должен предоставить в некоторой формеИнформация о сервисном звонке,в том числе, но не ограничиваетсяОпределение интерфейса сервиса、структура данныхИли промежуточныйФайл определения сервиса, Например, Facebook ThriftФайл IDL, Веб-сервисФайл WSDLВызывающий службу должен получать информацию, связанную с удаленным вызовом службы, определенным образом.
Существует также специальный звонок в JavaПолиморфизмТо есть, может быть несколько реализаций интерфейса, так что из них вызывается при удаленном вызове? Семантика этого локального вызова неявно реализуется посредством ссылочного полиморфизма, предоставляемого jvm, поэтому для RPC межпроцессные вызовы не могут быть реализованы неявно. Если есть две реализации интерфейса DemoService выше, вам необходимо экспортировать интерфейсСпециальные теги для разных нужд реализации, Затем вам нужно передать тег при удаленном вызове, чтобы вызвать правильный класс реализации, который решаетПолиморфный звонокСемантическая проблема.
(2) Удаленный прокси-объект:
Служба, используемая вызывающей стороной службы, фактически является локальным агентом удаленной службы. Говоря прямо, значит пройтиДинамический проксивыполнить.
(3) Связь:
Структура RPC не имеет ничего общего с конкретным протоколом. RPC может быть основан наПротокол HTTP или TCPВеб-служба представляет собой RPC на основе протокола HTTP, имеет хорошую кроссплатформенность, но ее производительность не так хороша, как RPC на основе протокола TCP.
3. Режим ввода-вывода: Для поддержки высокого параллелизма традиционная блокировка ввода-вывода явно не подходит, поэтому нам нужноАсинхронный ввод-выводКоторый является НИО. Java предоставляет решение NIO, а Java 7 также обеспечивает лучшую поддержку NIO.2.
(4) Сериализация:
1. СериализацияВ конце концов, это связь на большие расстояния, и объект должен быть преобразован в двоичный поток для передачи. Различные среды RPC имеют разные сценарии применения и будут использовать разные технологии в сериализации. Что касается сериализации, Java предоставляет метод сериализации по умолчанию, но в случае высокого параллелизма этот метод принесет некоторые узкие места производительности, поэтому на рынке появилась серия отличных платформ сериализации, таких как : Protobuf, Kryo, Hessian, Jackson и т. Д., Которые могут заменить сериализацию по умолчанию в Java, тем самым обеспечивая более эффективную производительность.
2. Закодированный контентПо соображениям эффективности, чем меньше закодированная информация, тем лучше (меньше передаваемых данных) и чем проще правила кодирования, тем лучше (высокая эффективность выполнения). Ниже приведена информация, необходимая для кодирования:
6. Простая реализация фреймворка RPC и анализ его примеров
Сервер предоставляет услуги, ожидаемые клиентом, которые обычно включают в себя три части: интерфейс службы, внедрение службы и возможность регистрации службы, а именно: интерфейс службы
Предоставление сервиса: только когда сервис открыт, клиент может сделать вызов. Это одна из функций инфраструктуры RPC.
Служба, предоставляемая клиентским сервером-потребителем, обычно включает две части: интерфейс службы и ссылку на службу, две части, а именно: интерфейс службы: совместно использовать один и тот же интерфейс службы с сервером
Ссылка на сервис: потребитель делает удаленные вызовы через инфраструктуру RPC, которая также является одной из функций инфраструктуры RPC
(3). Реализация прототипа фреймворка RPC
Инфраструктура RPC в основном включает две основные функции: одну для служб предоставления информации на стороне сервера и одну для справочных служб на стороне клиента. Сервер выставлен сервис
Из простой реализации инфраструктуры RPC логика сервера RPC заключается в следующем: сначала создайте ServerSocket, отвечающий за прослушивание определенного порта и получение запросов на подключение клиента, а затем используйте собственный механизм сериализации / десериализации Java для анализа запроса, включая вызываемый метод. Имя, список параметров и фактические параметры, и, наконец, отражают конкретную реализацию интерфейса службы, вызывая сервер и возвращая результат клиенту. На этом процесс сервера простого вызова PRC завершен. Клиентская справочная служба
Выше приведен простой и полный код, реализованный простой структурой RPC.
VII. Объяснение некоторых вопросов о структуре СРП
(1). Как инфраструктура RPC обеспечивает прозрачный вызов удаленного сервиса?
(2). Как опубликовать свой сервис?
Как позволить другим использовать наш сервис? Можно ли напрямую написать сервисный IP и порт, как в коде выше? На самом деле, в реальной производственной реализации способ использования уведомлений о человеческой плоти нереален, потому что в реальном производстве служебные машины слишком часто подключены к сети или отключены. Если вы обнаружите, что один компьютер не предоставляет достаточно услуг, вам нужно добавить еще один. В это время вы должны сообщить вызывающему абоненту, что у меня теперь есть два IP-адреса. Вы должны опросить вызов для достижения балансировки нагрузки; Когда машина зависает, вызывающая сторона обнаруживает, что половина службы недоступна, и он может только вручную изменить код, чтобы удалить ip, который зависает на этой машине. Это должно быть довольно больно!
(3). Сериализация и десериализация
Мы знаем, что объекты Java не могут быть переданы напрямую по сети. Итак, как можно отправить наш RPC-запрос на сервер и как клиент может получить ответ от сервера? Ответ заключается в том, что при передаче объектов Java сначала сериализуйте их, а затем десериализуйте и восстановите объекты на соответствующем терминале для обработки. Фактически, существует много видов технологий сериализации / десериализации, таких как собственный метод сериализации Java, JSON, сериализация Али Hessian и ProtoBuff и т. Д. Они имеют различия в эффективности, но имеют свои собственные характеристики.