rpc service что это
Выбор 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 service что это
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали замечательную утилиту командной строки robocopy, и с ее помощью научились создавать точные копии папок, двигать их в нужное расположение и многое другое. В сегодняшней публикации я покажу вам, как устранять ошибку «Сервер RPC недоступен (The rpc server is unavailable)», покажу примеры, когда ее мониторинг очень важен в работе корпоративных сервисов.
Для чего нужна служба «Удаленный вызов процедур (RPC)»
Процедура сообщения RPC
Когда программные операторы, использующие структуру RPC, компилируются в исполняемую программу, в скомпилированный код включается заглушка, которая выступает в качестве представителя кода удаленной процедуры. Когда программа запускается и выполняется вызов процедуры, заглушка получает запрос и пересылает его клиентской программе и времени выполнения на локальном компьютере. При первом вызове клиентской заглушки она связывается с сервером имен, чтобы определить транспортный адрес, по которому находится сервер.
Программа среды выполнения клиента знает, как обращаться к удаленному компьютеру и серверному приложению, и отправляет сообщение по сети, которое запрашивает удаленную процедуру. Точно так же сервер включает исполняющую программу и заглушку, которая взаимодействует с самой удаленной процедурой. Протоколы ответа-запроса возвращаются таким же образом.
Данная служба есть в любой операционной системе Windows, начиная от Windows 7 и заканчивая Windows 11 и в любой из Windows Server редакции.
Как работает RPC?
Когда вызывается служба RPC (удаленный вызов процедуры), вызывающая среда приостанавливается, параметры процедуры передаются по сети в среду, в которой должна выполняться процедура, а затем процедура выполняется в этой среде. Когда процедура завершается, результаты передаются обратно в вызывающую среду, где выполнение возобновляется, как если бы оно возвращалось из обычного вызова процедуры.
Во время RPC выполняются следующие шаги:
Если вы видите ошибку «Сервер RPC недоступен” (The RPC server is unavailable)», то у вас точно недоступен порт 135. Это может быть критичным для ряда ситуации. Например вы не сможете сохранить настройки RDS фермы, если у одного из хостов RDSH есть проблемы с RPC, то вы будите видеть ошибку «Could not change the connection state for server», вы не сможете перевести его в режим обслуживания (Drain Mode)
Или в приложении Terminal Services Manager будет ошибка при попытке получения данных «Сервер RPC недоступен«.
Так же RPC может быть причиной проблемы в репликации контроллеров домена, где в логах Windows будет фигурировать ошибка ID 1722. Это очень не приятный момент, который может привести к большим проблемам.
Типы RPC
Существует пять типов RPC:
Почему может не работать служба RPC
Преимущества удаленного вызова процедур
К преимуществам удаленного вызова процедур можно отнести следующее:
Недостатки RPC
Некоторые из недостатков RPC включают следующее:
Проверка доступности службы RPC
Если вдруг компьютер не ответил, то это не значит, что он не работает, может работать брандмауэр и просто блокировать ping пакеты.
Небольшой пример из практики, предположим, что вы мигрировали сервер в другую подсеть, в итоге в DNS должна быть изменена соответствующая запись, но Windows это поймет не сразу, так как у нее есть свой локальный кэш, он живет 15 минут, поэтому если при проверке DNS имени вам выдается не тот IP-адрес, вам необходимо произвести очистку кэша DNS.
Если удаленный RPC порт доступен вы в в строке TcpTestSucceeded будет стоять статус «True».
Если будет порт закрыт или блокируется, то ошибка «Сервер RPC недоступен (The rpc server is unavailable)» вам обеспечена. Поняв, что порт не отвечает, нужно удостовериться, что трафик от клиента до сервера не блокирует фаервол. По умолчанию в любой версии Windows есть встроенный брандмауэр. На время тестирования и поиска причины, я советую его выключить для всех профилей. Сделаем мы это через командную строку:
Данная команда выключит брандмауэр на всех трех профилях сетевой карты.
Далее если порт 135 стал доступен, то можно делать правила на удаленном сервере. Напоминаю, что нужно сделать правило для трех служб:
Еще хочу отметить, что если у вас есть сторонние антивирусные решения, например Касперский, то там так же есть встроенный сетевой экран, где так же нужно будет создать необходимые, разрешающие правила, которые корректно будут обрабатывать трафик динамических RPC портов.
Проверка работы служб RPC
Следующим шагом является проверка состояния службы на нужном вам сервере или компьютере. Проверять следует три службы:
В оболочке PowerShell выполните команду:
Для удаленного выполнения Enter-PSSession svt2019s01 далее Get-Service RpcSs,RpcEptMapper,DcomLaunch| Select DisplayName,Status,StartType
Напоминаю, что в команде svt2019s01, это имя удаленного сервера. Как видно из примера, все службы RPC запущены и имею автоматический тип запуска.
Если службы не запущены, то откройте оснастку «services.msc’, зайдите в свойства службы и выставите автозапуск и попробуйте запустить вручную.
Если по каким, то причинам вы не можете запустить службу из оснастки, то можно это сделать через реестр (Кстати реестр можно править и удаленно). Для этого есть несколько веток, но для начала откройте окно «Выполнить» и введите regedit.
В каждом из этих расположений есть ключик «Start«, выставите ему значение «2«, это будет означать автоматический запуск службы.
Дополнительные сетевые проверки
В некоторых случаях причиной ошибок с доступностью RPC выступает сбой на сетевых адаптерах. Помогает сброс сетевых настроек и перезагрузка. В сети с Active Directory, старайтесь, чтобы на всех ваших сетевых адаптерах в свойствах были выставлены обе галки IPV4 и IPV6, особенно это актуально для контроллеров домена, где вы легко можете получать ошибку 1722. Еще может помочь отключение протокола Teredo у IPv6. В командной строке выполните:
Устранение ошибок удаленного вызова процедур (RPC)
При подключении **** к Windows инструментов управления (WMI), SQL Server при удаленном подключении или при некоторых оснастках консоли управления Майкрософт (MMC) может возникнуть недоступен сервер RPC. Следующее изображение является примером ошибки RPC.
Это обычно встречаемая ошибка в сетевом мире, и можно потерять надежду очень быстро, не пытаясь понять многое, что происходит «под капотом».
При устранении неполадок используется много вышеуказанных сведений, наиболее важным является номер порта динамического RPC, который вы получаете во время разговора с EPM.
Как работает подключение
Клиент A хочет выполнить некоторые функции или хочет использовать службу, запущенную на удаленном сервере, сначала установит подключение к удаленному серверу, выполив трехполосное рукопожатие.
Порты RPC также могут быть предоставлены из определенного диапазона.
Настройка динамического распределения порта RPC
Динамическое распределение порта удаленного вызова процедуры (RPC) используется приложениями серверов и приложениями удаленного администрирования, такими как Dynamic Host Configuration Protocol (DHCP), менеджер Windows службы имен Интернета (WINS) и т. д. Динамическое распределение порта RPC будет поручить программе RPC использовать определенный случайный порт в диапазоне, настроенном для TCP и UDP, на основе реализации используемой операционной системы.
Клиенты, использующие брандмауэры, могут захотеть контролировать, какие порты использует RPC, чтобы их маршрутизатор брандмауэра мог быть настроен для переадтрансляцировать только эти порты протокола управления передачей (UDP и TCP). Многие серверы RPC в Windows вы можете указать порт сервера в настраиваемые элементы конфигурации, такие как записи реестра. Когда можно указать выделенный серверный порт, вы знаете, какой трафик течет между хостами через брандмауэр, и вы можете определить, какой трафик разрешен более адресно.
В качестве порта сервера выберите порт за пределами диапазона, который вы можете указать ниже. Полный список серверных портов, используемых в Windows и основных продуктах Майкрософт, можно найти в обзоре службы статьи и требованиях к сетевому порту для Windows. В статье также перечислены серверы RPC и какие RPC-серверы можно настроить для использования настраиваемых портов серверов за пределами объектов, которые предлагает время запуска RPC.
Некоторые брандмауэры также позволяют фильтровать UUID, где он узнает из запроса на конечный mapper RPC для UUID интерфейса RPC. В ответе имеется номер порта сервера, и последующая привязка RPC в этом порту разрешена для прохода.
Редактор реестра может изменить следующие параметры для RPC. Ключевые значения порта RPC, о чем идет речь ниже, находятся в следующем ключе реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet\ Тип данных имени входа
Порты REG_MULTI_SZ
PortsInternetAvailable REG_SZ Y или N (не чувствительны к делу)
UseInternetPorts REG_SZ ) Y или N (не чувствительны к делу)
Пример.
В этом примере порты от 5000 до 6000 включительно были произвольно выбраны для иллюстрации настройки нового ключа реестра. Это не рекомендация минимального количества портов, необходимых для любой конкретной системы.
Добавьте ключ к Интернету в статье: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
В ключе Интернета добавьте значения «Порты» (MULTI_SZ), «PortsInternetAvailable» (REG_SZ) и «UseInternetPorts» (REG_SZ).
Например, новый ключ реестра отображается следующим образом: Порты: REG_MULTI_SZ: 5000-6000 PortsInternetAvailable: REG_SZ: Y UseInternetPorts: REG_SZ: Y
Перезапустите сервер. Все приложения, которые используют динамическое распределение порта RPC, используют порты от 5000 до 6000 включительно.
Необходимо открыть диапазон портов над портом 5000. Номера портов ниже 5000 уже могут быть используются другими приложениями и могут вызывать конфликты с вашим приложением DCOM(s). Кроме того, предыдущий опыт показывает, что необходимо открыть не менее 100 портов, так как несколько системных служб используют эти порты RPC для взаимодействия друг с другом.
Минимальное количество необходимых портов может отличаться от компьютера к компьютеру. Компьютеры с повышенным трафиком могут оказаться в ситуации истощения порта, если динамические порты RPC ограничены. Учитывайте это при ограничении диапазона портов.
Если в конфигурации порта произошла ошибка или в пуле недостаточно портов, служба картографов конечных точек не сможет зарегистрировать серверы RPC с динамическими конечными точками. При ошибке конфигурации код ошибки будет 87 (0x57) ERROR_INVALID_PARAMETER. Это может повлиять Windows RPC-серверов, таких как Netlogon. В этом случае будет входить событие 5820:
Имя журнала. Источник системы: код событий NETLOGON: уровень 5820: Ключевые слова ошибки: классическое описание. Служба Netlogon не смогла добавить интерфейс RPC AuthZ. Служба была прекращена. Произошла следующая ошибка: «Параметр неправильный».
Если вы хотите глубоко погрузиться в работу, см. в рубцовской ленте RPC над ИТ-Pro.
Устранение ошибки RPC
PortQuery
Лучше всего всегда устранять проблемы RPC, прежде чем даже получить в следы, с помощью инструментов, таких как PortQry. Вы можете быстро определить, сможете ли вы сделать подключение, подав команду:
Частичный выход ниже:
Запрашиваемая целевая система: 169.254.0.2 Попытка разрешить IP-адрес с именем. IP-адрес разрешен для RPCServer.contoso.com запроса. TCP port 135 (epmap service): LISTENING Using ephemeral source port Querying Endpoint Mapper Database. Ответ сервера: UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d ncacn_ip_tcp:169.254.0.10 [49664]
Одно в смелейшем является эфемерным номером порта, к который вы успешно подключены.
Netsh
Вы можете запустить команды ниже, чтобы использовать Windows встроенный захват сетки, чтобы собрать одновременный след. Не забудьте выполнить ниже на «Администратор CMD», он требует высоты.
Теперь попробуйте воспроизвести проблему с клиентской машины и, как только вы почувствуете, что проблема была воспроизведена, перейдите вперед и остановите следы с помощью команды
Откройте трассировки в Microsoft Network Monitor 3.4 или Анализаторе сообщений и отфильтруйте трассировщик для
Ipv4.address== и ipv4.address== и просто должны tcp.port==135 tcp.port==135 помочь.
Посмотрите протокол «EPM» в столбце «Протокол».
Теперь проверьте, получают ли вы ответ с сервера. Если вы получили ответ, обратите внимание на динамический номер порта, который был выделен для использования.
Проверьте, успешно ли мы подключаемся к этому динамическим порту.
Фильтр должен быть таким: tcp.port== и ipv4.address==
Это поможет вам проверить подключение и изолировать, если будут замечены какие-либо проблемы в сети.
Порт, недоступный для
Самая распространенная причина, по которой сервер RPC недоступен, это когда динамический порт, к которым пытается подключиться клиент, недоступен. След стороне клиента будет затем показывать TCP SYN retransmits для динамического порта.
Порт не может быть досяжим по одной из следующих причин:
gRPC vs REST, что выбрать для нового сервера?
Так что же такое gRPC и в чем его отличие от, уже ставшего классическим, REST? Лучше ли gRPC? Может gRPC это снова хипстерская технология, которую все скоро забудут?
Не для кого ни секрет, что REST доминирует в современном мире API, особенно, когда речь идет о веб-приложениях и инфраструктурах, на основе микросервисов. Мало кто даже вспомнит, про то что микросервисы могут общаться по другому. Это наверное самый популярный ответ на собеседовании. Да если добавить еще feign клиента из Spring, то получается совсем красота и минимальные трудозатраты. Но для определенного набора сценариев использования, модель gRPC начала играть небольшую, но важную роль. Давайте попробуем разобраться, когда же нам стоит использовать REST, а когда gRPC.
Вот простая матрица, сравнивающая основы REST API и gRPC (картинка взята из интернета):
REST API и RPC API на примере микросервисов.
Что такое приложения на основе микросервисов?
Монолитное приложение содержит программирование всех своих сервисов и функций в единой неделимой кодовой базе, которая управляет всеми сервисами и функциями приложения. В то время как, приложения на основе микросервисов преодолевают самые большие ограничения традиционных монолитных приложений. Проблема в том, что по мере того, как разработчики подключают новые службы и функции к существующей структуре, становится все труднее изменять, обновлять и масштабировать приложение. Изменение одной части приложения может негативно повлиять на другие области. После многократного масштабирования, обновления и изменения монолита кодовая база в конечном итоге становится настолько взаимозависимой и трудной для понимания, что возникает необходимость перепроектировать всю систему с нуля.
REST API
REST описывает организацию клиент-сервер, в которой внутренние данные предоставляются клиентам через формат обмена сообщениями JSON или XML. По словам Роя Филдинга, API квалифицируется как «RESTful», если соответствует следующим ограничениям:
Единый интерфейс: API должен предоставлять потребителям API определенные ресурсы приложения.
Независимость клиент-сервера: клиент и сервер работают независимо. Клиент будет знать только те URI, которые указывают на ресурсы приложения. Обычно они публикуются в документации API.
Без сохранения состояния: сервер не сохраняет данные, относящиеся к запросу клиента. Клиент сохраняет эти «данные состояния» на своем конце (через кеш).
Кэшируемые: ресурсы приложения, предоставляемые API, должны быть кэшируемыми.
Многоуровневая: архитектура является многоуровневой, что позволяет поддерживать различные компоненты на разных серверах.
Код по запросу (COD): это единственное необязательное ограничение REST. Это позволяет клиенту получать исполняемый код в качестве ответа от сервера. Другими словами, именно сервер определяет, как будут выполняться конкретные действия.
Наконец, архитектура REST API обычно опирается на протокол HTTP, а REST API являются наиболее распространенным форматом для создания веб-приложений и подключения микросервисов. Когда REST API становится общедоступным как веб-служба, каждый компонент (или услуга), предоставляемый веб-службой, представляется клиентам как ресурс. Клиенты могут получить доступ к этим ресурсам через общий интерфейс, который принимает различные HTTP-команды, такие как GET, POST, DELETE и PUT.
API RPC
Как предшественник REST, RPC (удаленный вызов процедур) представляет собой программную архитектуру, восходящую к 1970-м годам. RPC позволяет вызывать функцию на удаленном сервере в определенном формате и получать ответ в том же формате. Не имеет значения, какой формат использует сервер, выполняющий запрос, и не имеет значения, локальный это сервер или удаленный. RPC позволяет вызывать функцию на сервере и получать результат в том же формате.
Основная концепция RPC API аналогична концепции REST API. RPC API определяет правила взаимодействия и методы, которые клиент может использовать для взаимодействия с ним. Клиенты отправляют вызовы, которые используют «аргументы» для вызова этих методов. Однако в случае RPC API метод находится в URL-адресе. Аргументы, вызывающие методы, находятся в строке запроса. Чтобы проиллюстрировать это, вот как запрос RPC API сравнивается с запросом REST API:
RPC: запрос RPC API может использовать POST / deleteSmth и иметь строку запроса, которая говорит
REST: запрос REST API записывает этот запрос как DELETE / smth / 777.
Погружение в API gRPC
Как вариант архитектуры RPC, gRPC был создан Google для ускорения передачи данных между микросервисами и другими системами, которым необходимо взаимодействовать друг с другом. По сравнению с REST API, gRPC API уникальны в следующих отношениях:
Протобуф (Protobuf) вместо JSON
Построен на HTTP 2 вместо HTTP 1.1
Создание собственного кода вместо использования сторонних инструментов, таких как Swagger
Передача сообщений в 7-10 раз быстрее
Более долгая имплементация и реализация, чем REST
Думаю, стоит детальнее разобрать каждое из этих различий между API REST и gRPC.
Protobuf вместо JSON / XML
И REST API, и RPC API отправляют и получают сообщения с использованием форматов обмена сообщениями JSON или XML. Они также могут использовать другие форматы, но наиболее распространены JSON и XML. Из них JSON стал самым популярным форматом, поскольку он гибкий, эффективный, платформенно-независимый и не зависит от языка. Он также основан на тексте и удобочитаем для человека, что упрощает работу операторам. Проблема в том, что для определенных случаев использования JSON недостаточно быстр или легковесен при передаче данных между системами.
В отличие от REST и RPC, gRPC преодолевает проблемы, связанные со скоростью и весом, и предлагает большую эффективность при передаче сообщений, используя формат обмена сообщениями Protobuf (буферы протокола). Вот несколько подробностей о Protobuf:
Независимость от платформы и языка, например как JSON
Сериализует и десериализует структурированные данные для передачи в двоичном формате.
Поскольку он является сильно сжатым форматом, он не обеспечивает удобочитаемости JSON.
Ускоряет передачу данных, удаляя множество обязанностей, которыми управляет JSON, поэтому он может сосредоточиться исключительно на сериализации и десериализации данных.
Передача данных происходит быстрее, потому что Protobuf уменьшает размер сообщений и служит легким форматом обмена сообщениями.
Построен на HTTP 2 вместо HTTP 1.1
API-интерфейсы REST обычно построены на HTTP 1.1, который использует модель взаимодействия запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы. API REST также могут использовать HTTP 2, они по-прежнему ограничены моделью запрос-ответ и не используют поддержку HTTP 2 для двунаправленной потоковой связи.
В отличие от этого, gRPC использует HTTP 2 и пользуется преимуществами поддержки HTTP 2 как для взаимодействия с клиентом, так и для двунаправленной связи. Таким образом, gRPC может управлять «унарными» взаимодействиями, аналогичными HTTP 1.1 (когда клиент отправляет один запрос, а сервер отправляет один ответ). В то же время клиенты могут также открывать долговременные соединения, в которых каждый вызов RPC открывает новый поток HTTP 2, также известный как двунаправленная, «мультиплексируемая» или потоковая связь.
В HTTP 2, когда микросервис получает несколько запросов от более чем одного клиента, он достигает мультиплексирования, обслуживая множество запросов и ответов одновременно. В этом отношении API-интерфейсы gRPC отступают от ограничений API-интерфейсов REST в их способности непрерывно передавать информацию.
GRPC предоставляет три типа потоковой передачи:
На стороне сервера: клиент отправляет сообщение запроса на сервер. Сервер возвращает поток ответов клиенту. После завершения ответов сервер отправляет сообщение о состоянии (и в некоторых случаях конечные метаданные), что завершает процесс. После получения всех ответов клиент завершает свой процесс.
На стороне клиента: клиент отправляет поток сообщений запросов на сервер. Сервер возвращает один ответ клиенту. Он (обычно) отправляет ответ после получения всех запросов от клиента и сообщения о состоянии (и в некоторых случаях конечных метаданных).
Встроенная генерация кода вместо использования сторонних инструментов
Функции генерации кода встроены в gRPC через встроенный компилятор протоколов. При использовании REST API необходимо использовать сторонний инструмент, например Swagger, для автоматической генерации кода для вызовов API на разных языках.
Компилятор protoc, поставляемый с gRPC, совместим с широким спектром языков программирования. Это делает gRPC отличным средством для многоязычных сред, где вы подключаете множество различных микросервисов, написанных на разных языках и работающих на разных платформах.
Напротив, REST API не предлагает функций генерации собственного кода. Вы должны использовать сторонний инструмент, такой как Swagger, для генерации кода для вызовов API на разных языках. Это не доставляет неудобств, но стоит отметить, что gRPC не зависит от каких-либо внешних инструментов для генерации кода.
Передача сообщений в 7-10 раз быстрее
Согласно широко цитируемым тестам, опубликованным Руваном Фернандо, соединения gRPC API значительно быстрее, чем соединения REST API. Фактически, он сообщил, что они в 7-10 раз быстрее:
GRPC примерно в 7 раз быстрее REST при получении данных и примерно в 10 раз быстрее, чем REST при отправке данных для этой конкретной полезной нагрузки. В основном это связано с плотной упаковкой буферов протокола и использованием HTTP / 2 в gRPC
Вот результаты, которые получил Руван:
Более долгая реализация и имплементация, чем REST
Несмотря на преимущества в скорости передачи сообщений, реализация gRPC API намного медленнее, чем реализация REST API. По словам Руана Фернандо, внедрение простой службы gRPC занимает около 45 минут. Реализация веб-API или REST API занимает всего около 10 минут.
Фернандо сообщает, что дополнительное время внедрения отражает отсутствие встроенной поддержки gRPC в сторонних инструментах. Это в первую очередь потому, что gRPC еще не получил широкого распространения, особенно по сравнению с повсеместным распространением REST API. Вот что Фернандо говорит о времени внедрения gRPC:
Мне пришлось потратить примерно 45 минут на внедрение этой простой службы gRPC, из которых я потратил всего около 10 минут на создание WebAPI. В основном это связано с тем, что REST давно стал мейнстримом, и большинство основных фреймворков (например, ASP.NET Core MVC) имеют встроенную поддержку для быстрого развертывания таких сервисов (с помощью соглашений и шаблонов)
Когда лучше использовать REST или gRPC?
Давайте сравним, когда вам следует рассмотреть возможность использования REST API и gRPC API:
Когда использовать REST API
Независимо от того, создаете ли вы внутреннюю систему или открытую систему, которая предоставляет свои ресурсы остальному миру, REST API, вероятно, останутся фактическим выбором для интеграции приложений в течение очень долгого времени. Кроме того, REST API идеально подходят, когда системе требуется высокоскоростная итерация и стандартизация протокола HTTP. Благодаря универсальной поддержке сторонних инструментов REST API должны быть вашим первым аргументом в пользу интеграции приложений, интеграции микросервисов и разработки веб-сервисов.
Когда использовать API gRPC
Что касается gRPC, в большинстве сторонних инструментов по-прежнему отсутствуют встроенные функции для совместимости с gRPC. Таким образом, gRPC в основном используется для создания внутренних систем, то есть инфраструктуры, закрытой для внешних пользователей. С учетом этого предостережения, API-интерфейсы gRPC могут быть полезны в следующих случаях:
Соединения с микросервисами: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
Системы где используется несколько языков программирования: благодаря поддержке генерации собственного кода для широкого спектра языков разработки, gRPC отлично подходит для управления соединениями в среде с наличием нескольких языков.
Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет вашей системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
Сети с низким энергопотреблением и низкой пропускной способностью: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость для сетей с ограниченным диапазоном пропускания и маломощных сетей (особенно по сравнению с JSON). Интернет вещей может быть примером такой сети, в которой могут быть полезны API gRPC.
Подведем итог о REST и gRPC
Из-за различных преимуществ API-интерфейсов gRPC, которые мы рассмотрели до сих пор, некоторые разработчики рассматривают gRPC как «будущее». Однако эти разработчики могут забегать вперед. gRPC еще не получил широкого распространения, и еще предстоит увидеть, будут ли его преимущества стимулировать более широкое распространение в будущем.
Для сравнения, REST поддерживается повсеместно, и практически каждая инфраструктура на основе микросервисов полностью зависит от API-интерфейсов REST как связующего звена, объединяющего их. Если ваш вариант использования не требует реализации gRPC, рисковать принятием gRPC на этом зарождающемся этапе (до широкого распространения) нецелесообразно и не нужно.