rpc что это такое
Как работает RPC
Средства удаленного вызова процедур делают его пользователям, как будто клиент напрямую вызывает процедуру, расположенную в удаленной серверной программе. У каждого клиента и сервера есть свои адресные пространства; то есть каждый из них имеет свой собственный ресурс памяти, выделенный для данных, используемых процедурой. На следующем рисунке показана архитектура RPC.
Как показано на рисунке, клиентское приложение вызывает локальную процедуру-заглушку вместо фактического кода, реализующего процедуру. Заглушки компилируются и связываются с клиентским приложением. Вместо того, чтобы содержать фактический код, реализующий удаленную процедуру, код заглушки клиента:
Для вызова удаленной процедуры сервер выполняет следующие действия.
Затем выполняется удаленная процедура, которая, возможно, создает выходные параметры и возвращаемое значение. После завершения удаленной процедуры аналогичная последовательность действий возвращает клиенту данные.
Клиент завершает процесс, принимая данные по сети и возвращая их вызывающей функции.
Библиотеки времени выполнения предоставляются в двух частях: библиотеку импорта, которая связана с приложением и библиотекой времени выполнения RPC, которая реализована как библиотека динамической компоновки (DLL).
Серверное приложение содержит вызовы функций библиотеки времени выполнения сервера, которые регистрируют интерфейс сервера и позволяют серверу принимать удаленные вызовы процедур. Серверное приложение также содержит удаленные процедуры, связанные с конкретным приложением, которые вызываются клиентскими приложениями.
Выбор Request-Response парадигмы API: REST, RPC или GraphQL?
API определяет интерфейс, предоставляющий данные сервиса другим приложениям. Выбор правильного формата API крайне важен. Бизнес не всегда учитывает все факторы, выбирая формат. В результате не хватает возможности для добавления новых фич, которые могут понадобиться в дальнейшем.
Чтобы сэкономить время, силы, а самое главное деньги, стоит посмотреть на best practices, которые применяются на текущий момент. Это поможет разработать API, который позволит вносить необходимые изменения в будущем. За прошедшие годы появилось несколько форматов API, рассмотрим самые популярные из них.
Request-Response APIs
Первую группу API, которую мы рассмотрим, можно выделить как Request-Response API. Основные отличия данной группы:
Самые популярные request-response API: REST, RPC и GraphQL.
Самый популярный подход на данный момент. Используется такими поставщиками API, как, например, Google, Twitter и GitHub.
Когда мы говорим про REST, мы говорим про ресурсы. Ресурс — это объект, который может быть идентифицирован, назван, адресован или обработан в сети. REST представляет данные как ресурсы и использует стандартные HTTP-методы для представления транзакций создания, чтения, обновления и удаления этих ресурсов, то есть стандартные CRUD операции. По сути, все бизнес-сущности, которыми оперирует сервис, могут быть определены как ресурсы.
Общие правила, которым следует RESTful API:
Помимо типичных операций CRUD, API-интерфейсы REST могут иногда нуждаться в представлении операций, не относящихся к CRUD. В этом случае обычно используются следующие подходы:
Для API, предоставляющего CRUD-операции.
Remote Procedure Call (RPC)
Удаленный вызов процедур (RPC) — это одна из простейших парадигм API, в которой клиент вызывает исполнение блока кода на сервере. В то время как REST рассматривает всё как ресурсы, RPC рассматривает действия. Клиенты обычно передают имя метода и аргументы серверу и получают обратно JSON или XML.
Для API, предоставляющего действия, которые сложно инкапсулировать в CRUD операциях.
GraphQL
GraphQL — это язык запросов для API, который в последнее время приобрел значительную популярность. Он был разработан внутри Facebook в 2012 году до публичного выпуска в 2015 году. GraphQL позволяет клиентам определять структуру требуемых данных. Сервер возвращает именно эту структуру
В отличие от REST и RPC API, GraphQL требует только один эндпоинт URL. Также вам не нужны разные HTTP-методы для описания операции. Вместо этого вы указываете в теле JSON выполняете ли вы запрос или мутацию. GraphQL поддерживает методы GET и POST.
Плюсы:
Минусы:
RPC, Messaging, REST: Терминология
Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.
Вступление
Если вы работаете в области программирования распределенных систем или в интеграции систем, то большая часть изложенного здесь вам не в новинку.
Проблема возникает, когда встречаются люди, использующие разные технологии, и когда эти люди начинают технические разговоры. При этом часто возникает взаимное недопонимание, обусловленное терминологией. Я здесь попытаюсь свести воедино терминологии, используемые в разных контекстах.
Терминология
Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.
Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.
Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.
Messaging
С течением времени выяснилось, что попытка оградить программиста от того, что вызываемая функция все же отличается от локальной, не привела к желаемому результату. Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода Proxy. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.
Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.
Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.
Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.
В постоянной борьбе со сложностью кода, программисты сделали очередной шаг и создали REST.
Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции
EntityAddress ReadEntityAddress(string param1, string param2)
выразится в таком виде:
Заключение
Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.
13) Удаленный вызов процедур (RPC)
Что такое RPC?
Удаленный вызов процедур (RPC) — это метод межпроцессного взаимодействия. Используется для клиент-серверных приложений. Механизмы RPC используются, когда компьютерная программа вызывает выполнение процедуры или подпрограммы в другом адресном пространстве, которое закодировано как обычный вызов процедуры, при этом программист специально не кодирует детали для удаленного взаимодействия. Этот вызов процедуры также управляет транспортным протоколом низкого уровня, таким как протокол пользовательских дейтаграмм, протокол управления передачей / Интернет-протокол и т. Д. Он используется для передачи данных сообщения между программами. Полная форма RPC — Удаленный вызов процедур.
Из этого руководства по операционной системе вы узнаете:
Типы RPC
Обратный вызов RPC
Этот тип RPC обеспечивает парадигму P2P между участвующими процессами. Это помогает процессу быть как клиентом, так и сервером.
Функции Callback RPC:
Трансляция RPC
Широковещательный RPC — это запрос клиента, который транслируется в сети и обрабатывается всеми серверами, у которых есть метод обработки этого запроса.
Функции Broadcast RPC:
RPC в пакетном режиме
RPC в пакетном режиме помогает ставить в очередь отдельные запросы RPC в буфере передачи на стороне клиента, а затем отправлять их по сети одним пакетом на сервер.
Функции RPC в пакетном режиме:
Как работает RPC?
Архитектура RPC имеет в основном пять компонентов программы:
В процессе RPC выполняются следующие шаги:
Шаг 1) Клиент, заглушка клиента и один экземпляр времени выполнения RPC выполняются на клиентском компьютере.
Шаг 2) Клиент запускает процесс-заглушку клиента, передавая параметры обычным способом. Клиентская заглушка хранится в собственном адресном пространстве клиента. Он также просит локальную среду выполнения RPC отправить обратно на заглушку сервера.
Шаг 3) На этом этапе RPC доступен для пользователя путем выполнения обычной локальной процедурной калибровки. RPC Runtime управляет передачей сообщений между сетью через клиент и сервер. Он также выполняет работу по повторной передаче, подтверждению, маршрутизации и шифрованию.
Шаг 4) После завершения серверной процедуры он возвращается к заглушке сервера, которая упаковывает (маршаллы) возвращаемые значения в сообщение. Затем заглушка сервера отправляет сообщение обратно на транспортный уровень.
Шаг 5) На этом этапе транспортный уровень отправляет сообщение с результатом клиентскому транспортному уровню, который возвращает сообщение клиентской заглушке.
Шаг 6) На этом этапе клиентская заглушка демаршаллизирует (распаковывает) возвращаемые параметры в результирующем пакете, и процесс выполнения возвращается вызывающей стороне.
Характеристики RPC
Вот основные характеристики RPC:
Особенности RPC
Вот некоторые важные особенности RPC
Преимущества RPC
Вот плюсы / преимущества RPC
Недостатки RPC
Вот минусы / недостатки использования RPC:
Русские Блоги
Введение в основы 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 и т. Д. Они имеют различия в эффективности, но имеют свои собственные характеристики.