Ноль.

В настоящее время микросервисные архитектуры сталкиваются с удаленными вызовами между службами. Существует два распространенных метода удаленного вызова: RPC: удаленный вызов процедуры Remote Produce Call, аналогичный RMI. Пользовательский формат данных, основанный на встроенной TCP-связи, быстрый и эффективный. Ранний веб-сервис и ныне популярный даббо являются типичными примерами RPC. Http: http на самом деле является протоколом сетевой передачи, основанным на TCP, который определяет формат передачи данных. В настоящее время связь между клиентским браузером и сервером в основном использует протокол Http. Его также можно использовать для совершения удаленных вызовов службы поддержки. Недостатком является то, что инкапсуляция сообщений раздута. Популярный стиль Rest можно реализовать через протокол http.

один. Введение 1. RPC(remote procedure call)

Выполните функцию на удаленном сервере, вызвав службу (метод) сервера как локальную службу (метод). Общие реализации включают XML-RPC и JSON-RPC. Методы связи в основном одинаковы. Единственная разница — формат передачи данных. (1) Преимущества: ​ ​ Простой дизайн, легко понять Легкая полезная нагрузка Высокая производительность (2) Недостатки: ​ Высокая связь между интерфейсным и внутренним кодом Читабельность кода плохая, и соответствующий код нелегко найти. Это приведет к большому количеству определенных функций, которыми сложно управлять. (3) Ядро RPC является ядром распределенной архитектуры. В зависимости от режима ответа он делится на два типа: Синхронный вызов: клиент вызывает метод сервера, ждет, пока сервер вернет результат или истечет время ожидания, а затем продолжает свою работу. Асинхронный вызов: клиент отправляет сообщение промежуточному программному обеспечению, больше не ждет ответа сервера и напрямую продолжает свою работу. Методы реализации синхронного вызова включают WebService и RMI. Сервисы, предоставляемые веб-сервисом, основаны на веб-контейнерах, а нижний уровень использует протокол http, поэтому он подходит для вызовов между разнородными системами на разных языках. RMI на самом деле является реализацией RPC языка Java, позволяющей методам возвращать объекты Java и базовые типы данных, и подходит для вызовов между различными системами, созданными с использованием языка JAVA.

JAVA-реализацией асинхронных вызовов является JMS (Java Message Service). Текущее промежуточное программное обеспечение JMS с открытым исходным кодом включает в себя ActiveMQ и промежуточное программное обеспечение сообщений Kafka от сообщества Apache, а также RocketMQ от Alibaba.   

2. REST (Передача репрезентативного состояния), передача состояния уровня представления. При разработке API используйте пути для поиска ресурсов, операций определения методов и согласования типов ресурсов с помощью Content-Type и Accept. REST — это архитектурный стиль, который относится к набору архитектурных ограничений и принципов. Приложение или проект, удовлетворяющий этим ограничениям и принципам, является RESTful. Спецификация REST рассматривает весь контент как ресурс, и все в сети является ресурсом. REST не создает новые технологии, компоненты или сервисы, он просто использует существующие функции и возможности Интернета. Может быть реализован полностью через протокол HTTP, используя протокол HTTP для обработки передачи данных. Операции архитектуры REST с ресурсами включают получение, создание, изменение и удаление ресурсов, которые соответствуют методам GET, POST, PUT и DELETE, предоставляемым протоколом HTTP. REST означает передачу репрезентативного состояния (REST), это стиль архитектуры программного обеспечения. REST использует универсальные методы глаголов (GET, PUT, DELETE, POST), определенные протоколом HTTP, для уникальной идентификации сетевых ресурсов с помощью URI. Ответчик описывает ресурсы, которые он запрашивает, посредством связи без сохранения состояния в соответствии с различными потребностями запрашивающей стороны. (1) Преимущества: Сильно развязанный интерфейс и серверная часть Это легко понять, даже не читая документацию, можно примерно понять, для чего используется интерфейс; Интерфейс имеет единственную функцию, его легко расширять и использовать повторно; ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ (2) Недостатки: Иногда полезная нагрузка становится чрезвычайно большой Одной и той же странице может потребоваться вызов множества API для получения разных данных, что уменьшит удобство работы при плохой сети. (3) Особенности: Ресурсы. Ресурсы представляют собой набор ориентированных на пользователя наборов данных на основе json (или другого представления). Выражением информации с помощью ресурсов обычно являются данные в концептуальной модели. ​​​​Stateless: так называемый Stateless означает, что все ресурсы могут быть расположены через URI, и это позиционирование не имеет ничего общего с другими ресурсами и не изменится из-за изменений в других ресурсах.     Унифицированный интерфейс: архитектурный стиль RESTful предусматривает, что метаоперации с данными, а именно операции CRUD (создание, чтение, обновление и удаление, то есть добавление, удаление и изменение данных), соответственно соответствуют методам HTTP: GET используется для получения ресурсов, а POST используется для создания новых ресурсов (также может использоваться для обновления ресурсов), PUT используется для обновления ресурсов, а DELETE используется для удаления ресурсов. Это унифицирует интерфейс для всех операций с данными. , удаление, проверка и изменение данных могут быть выполнены только с помощью метода HTTP. URI: вы можете использовать URI (унифицированный указатель ресурса), чтобы указать на ресурс, то есть каждый URI соответствует определенному ресурсу. Чтобы получить этот ресурс, просто получите доступ к его URI, чтобы URI стал адресом или идентификатором каждого ресурса. (4) Принципы проектирования: Все в сети абстрагировано на ресурсы                                               Каждый ресурс имеет уникальный идентификатор ресурса. Один и тот же ресурс имеет несколько форм выражения (xml, json и т. д.). Различные операции с ресурсами не изменят идентификатор ресурса. Все операции не имеют состояния Связь без сохранения состояния означает, что сервер (ответчик) не сохраняет никаких ресурсов, связанных с конкретным HTTP-запросом, а состояние приложения должно быть предоставлено запрашивающей стороной во время процесса запроса. Требуется, чтобы во время сетевого взаимодействия любой веб-запрос был изолирован от других запросов. Когда запрашивающая сторона делает запрос, сам запрос содержит всю информацию, необходимую ответчику для ответа на запрос. Проще говоря, информация о состоянии, хранящаяся на сервере, имеет состояние, а информация о состоянии, хранящаяся на клиенте, не имеет состояния. Принцип REST без сохранения состояния просто способствует достижению балансировки нагрузки. В распределенной веб-системе имеется несколько доступных серверов. Со временем один сервер выходит из строя и может быть передан. на другие серверы для обработки, чего не могут сделать запросы с отслеживанием состояния. RESTful — это архитектура, реализующая стиль дизайна REST, например RESTful API (API стиля дизайна REST). (5) Стиль ​ ​Использование методов HTTP для унификации интерфейса Используйте код состояния HTTP для возврата информации о состоянии. 3. GraphQL (язык графических запросов)

Он вобрал в себя некоторые общие преимущества RPC и REST, используя запрос в качестве базовой единицы, удобно получать нужные данные;     (1) преимущество:         Отличная производительность на низких скоростях сети.         Декларативный поиск данных         Получите соответствующие данные в соответствии с требованиями пользовательского интерфейса и избегайте ненужной передачи данных.     (2) недостаток:         относительно сложно определить         Проблемы с кэшированием требуют более надежного механизма для обеспечения кэширования на уровне полей.         Версия постоянно обновляется и еще не является зрелой. два. Сравнивать: 1. Поставщик службы RPC и интерфейс вызывающей стороны слишком зависят друг от друга, что приводит к сложности кодирования. Однако интерфейс REST более легкий, чем RPC. Зависимость между поставщиком службы и вызывающей стороной зависит только от контракта, и это так. нет уровня кода Сильная зависимость. 2. Службы RPC чувствительны к платформе, и их сложно просто повторно использовать: REST может быть реализован на разных платформах, и вызывающие программы на любом языке могут реализовать его в соответствии с определением интерфейса. 3. Dubbo использует RPC для сервисных вызовов, а SpringCloud использует REST. 4. Протокол связи REST использует HTTP, а RPC обычно использует TCP. 5. Производительность, производительность REST низкая, производительность RPC высокая. 6. Гибкость, REST имеет высокую гибкость, RPC имеет низкую гибкость. 7. С точки зрения использования интерфейс Http фокусируется только на поставщике услуг (сервере). Его не волнует способ вызова клиента или метод вызова. В обычных обстоятельствах, когда клиент использует Http для совершения вызовов, ему достаточно только этого. передавать контент, поэтому клиенту необходимо уделять больше внимания сетевой передаче при его использовании. Потеря, относительно неподходящая для развития бизнеса; службы RPC требуют, чтобы клиентский интерфейс был согласован с сервером. Сервер предоставляет метод, и клиент напрямую инициирует вызов через интерфейс. Бизнес-разработчику нужно только обратить внимание на вызов. бизнес-метод Однако, больше не обращая внимания на детали сетевой передачи, он более эффективен в развитии. 8. С точки зрения производительности, при использовании Http сам Http предоставляет богатые функции состояния и функции расширения. Однако, поскольку Http предоставляет слишком много функций, во время передачи по сети необходимо передавать больше информации. С точки зрения производительности это относительно неэффективно. Однако передача по сети службы RPC передает только данные, относящиеся к бизнес-контенту, поэтому передаваемые данные меньше, а производительность выше.

три. Применимые сценарии API на основе RPC больше подходит для поведения (то есть команд и процедур), а API на основе REST больше подходит для построения моделей (то есть ресурсов и сущностей) и обработки CRUD. REST использует методы HTTP, такие как: GET, POST, PUT, DELETE, OPTIONS и менее распространенный метод PATCH. RPC обычно использует только методы GET и POST. Метод GET обычно используется для получения информации, а метод POST может использоваться для выполнения всех действий.

Поскольку оба метода позволяют осуществлять удаленный вызов, какой нам следует выбрать? (1) С точки зрения скорости RPC быстрее, чем http. Хотя базовым уровнем является TCP, информация в протоколе http часто раздувается, но можно использовать сжатие gzip. (2) С точки зрения сложности реализация RPC более сложна, тогда как http относительно прост. (3) С точки зрения гибкости http лучше, поскольку он не заботится о деталях реализации и является кроссплатформенным и кросс-языковым.

Таким образом, оба имеют разные сценарии использования: (1) Если требуются более высокие требования к эффективности и в процессе разработки используется единый стек технологий, то целесообразно использовать RPC. (2) Если вам нужно быть более гибким, кросс-языковым и кросс-платформенным, очевидно, что http более подходит.

три. Подвести итог 1. RPC: так называемый удаленный вызов процедур. (ориентированный на метод)     SOA: так называемая сервис-ориентированная архитектура (ориентированная на сообщения).     ОТДЫХ: так называемый Representational state transfer (ресурсно-ориентированный)

2. При проектировании API, принимая решение о том, какую форму использовать, необходимо в первую очередь учитывать, кто будет использовать разработанный API: Если это проект, который фокусируется на объектах и ​​ресурсах, требует подключения к различным терминалам и пользователям, а также должен быть простым в использовании и чтении документов, тогда подойдет REST. Если он ориентирован на действия или некоторые внутренние микросервисы предъявляют высокие требования к отклику, вы можете рассмотреть RPC. Если вам необходимо предоставить данные в пользовательский интерфейс или вам нужно оптимизировать и сократить количество запросов в слабой сетевой среде, вы можете рассмотреть GraphQL. Для конечных пользователей попробуйте использовать Restful HTTP. Причина в том, что он обладает обширными знаниями и интуитивно понятен. Все языки программирования поддерживают HTTP (включая оболочку, что упрощает отладку). Для внутренних систем, если машин немного, можно также рассмотреть возможность использования Restful HTTP. Если машин много, попробуйте использовать двоичный RPC. В конце концов, разрыв в производительности по-прежнему огромен. Вызовы и тесты REST очень удобны, RPC немного громоздок, но эффективность RPC не вызывает сомнений, поэтому рекомендуется использовать RPC для внутренних вызовов между несколькими системами. Для внешних сервисов больше подходит Rest. RESTful API и RPC — это две совершенно разные концепции, и их нельзя сравнивать друг с другом. Если мы настаиваем на их сравнении, я считаю, что RESTful — это реализация RPC, то есть RPC включает в себя RESTful API, но RPC не равен RESTful API. RPC: Я думаю, что RPC — это идея, предложенная для удаленного вызова. Вы можете использовать любой метод для достижения своей цели (например: вам решать, какой сетевой протокол использовать для передачи данных). RESTful API: архитектура интерфейса, соответствующая стилю дизайна REST. Это также удаленный вызов через сеть, но удаленный вызов ограничен HTTP.