почему все приложения в ис используют технологию rpc
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 технологий.
1. Перечислите функции администратора системы. Перечислите функции администратора системы
— определение и согласование с фирмами-поставщиками всей аппаратно-программной и организационной части по реализации системы;
— планирование развития информационных систем и внедрения сервисов;
— решение вопросов ведения проектов;
— обучение технического персонала и пользователей;
— консультирование по компьютерным проблемам персонала предприятия и технических служб;
— решение проблем сбора статистики, мониторинга, диагностики, восстановления и сохранения системы, а также всех вопросов организации соответствующих программных и аппаратных продуктов для этой деятельности;
— разработка программных продуктов на языках управления заданиями (например, скриптах) с целью создания технологии работы компании и синхронизации работы компонентов информационной системы;
— определение ошибок в работе прикладных, системных и аппаратных средств, используемых предприятием, и решение вопросов по их устранению.
открытой системой может быть названа любая система (компьютер, вычислительная сеть, операционная система, программный продукт), которая построена в соответствии с открытыми спецификациями для интерфейсов, служб и форматов
Еще протокол описывает условия эксплуатации, ограничения и другие особые характеристики.
Стандарт – это попыткареализации протокола в аппаратуре или ПО, которая отражается в документе, согласованном и принятом аккредитованной организацией, разрабатывающей стандарты.
F – Fault – обнаружение отказов в устройствах сети, сопоставление аварийной информации от различных устройств, локализация отказов и инициирование корректирующих действий.
C – Configuration – возможность отслеживания изменений, конфигурирования, передачи и установки программного обеспечения на всех устройствах сети.
A – Account – возможность сбора и передачи учетной информации для генерации отчетов об использовании сетевых ресурсов.
P – Performance – управление производительностью на основе наблюдения за показателями работы сети (QoS, ToS) и распределение сетевых ресурсов.
S – Security – возможность управления доступом к сетевым ресурсам и защитой от угроз.
Модель ITIL является библиотеке рекомендаций, включающей в себя в разных вариантах от 40 до 60 книг
7. В каких организациях применяется модель еТОМ?
На предприятиях телекоммуникационной отрасли (включая администрирование ИС компаний связи) и на других предприятиях связи в т.ч. применяющих решения OSS/BSS.
OSS – Operation Service Support; BSS – Business Service Support.
8. Почему все приложения в ИС используют технологию RPC?
Потому что эта совокупность библиотек позволяет вызывать C-процедуры для общения между узлами сети. При помощи процедур RPC реализован NFS – протокол организации и доступа к файловой системе в удаленном варианте. К тому же это открытый стандарт.
представляют собой кабели (витая пара, коаксиальный кабель, оптоволоконный кабель), которые передают электрические и световые сигналы. Возможности передачи данных ограничены возможностями кабеля
Назначение – Gigabit Ethernet; 10GbE(до 37 м), 4 пары проводов используются.
NEXT, FEXT, Attenuation. Alien crosstalk.
Это оптоволокно, в котором свет передается одним лучом лазера. Они применяются на дальние расстояния (сердечник, оболочка – 9 и 125 мкм, длина волн 1300 нм и 1550 нм, затухание – 1Дб/км).
Административная подсистема – идущая между клозетом и ER;
Горизонтальная подсистема – идущая между ER и розеткой (в которой может находиться специальный адаптер, согласующий сопротивление различных кабельных систем – balun)
Подсистема рабочего места – идущая между розеткой и рабочими станциями или терминалами.
EIA/TIA 568 – описывает требования к помещениям, в которых устанавливается СКС и оборудование связи;
EIA/TIA 606 – стандарт администрирования ТК инфраструктуры в служебных и производственных зданиях.
EIA/TIA 607 – стандарт, устанавливающий требования к инфраструктуре телекоммуникационной системы заземления и выравнивания потенциалов в служебных и производственных зданиях.
называется хаб (hub).
Хаб не проводит анализа информации. Он на короткое время запоминает значения сигнала «О» или «1», соответствующим образом их регенерирует, усиливает и отправляет во все присоединенные сегменты сети. Эти функции должны выполняться на пути от источника до получателя столько раз, сколько необходимо для обеспечения требуемого качества передачи.
SR – source routing – маршрутизирование от источника
Сквозная – cut-through – фрейм передается, как только коммутатор получил его заголовок.
2. Специальные фильтры: запретить печатать, например;
3. Виртуальные сети (возможно).
В сети уровня доступа коммутация STA не нужна.
Администратор должен соответствующим образом настроить оборудование, осуществляющее разделение на VLAN, которые могут базироваться на портах, на MAC-адресах, на сетевых протоколах или комбинациях этих возможностей.
1. базовый (магистральный) уровень (предназначен для создания оптимизированной и надежной транспортной структуры для передачи данных с большими скоростями);
2. Уровень распределения (определяет границы сети и обеспечивает манипуляцию пакетами в сети);
3. Уровень доступа (данные передаются в сеть, и осуществляется входной контроль).
• 48 портов 10/100BASE-T
• 2 комбо-порта 10/100/1000 BASE-T / 100/1000 SFP
Дополнительный резервный источник питания
• Коммутационная матрица: 17,6 Гбит/с
• Скорость перенаправления пакетов: 13,1 Mpps
• Буфер пакетов: 3 МБ
• Макс. 256 IPv4 интерфейсов, 32 IPv6 интерфейса
• IPv6 Neighbor Discovery (ND)
Маршрутизация уровня 3
• До 7 286 IPv4 внешних маршрутов
• До 1 821 IPv6 внешних маршрутов
• До 3 575 IPv4 внешних маршрутов
• До 1 821 IPv6 внешних маршрутов
• До 256 записей статической маршрутизации для IPv4, 128 записей для IPv6
• Маршрутизация на основе политик
Многоадресная рассылка уровня 3
• До 1 024 IPv4 групп многоадресной рассылки
• До 256 IPv6 групп многоадресной рассылки
• Управление полосой пропускания
• QoS на основе времени
Управление
• Управление на основе Web-интерфейса (Поддержка Ipv4/IPv6)
• Интерфейс командной строки CLI
• Сервер Telnet (Поддержка IPv4/IPv6)
• Клиент Telnet (Поддержка IPv4/IPv6)
• Клиент TFTP (Поддержка IPv4/IPv6)
• Клиент FTP (Поддержка IPv4/IPv6)
• Remote Copy Protocol (RCP)
• Файловая система Flash
• Поддержка нескольких копий ПО (Multiple Images)
• Поддержка нескольких копий конфигураций (Multiple Configurations)
Безопасность
cUL, CB
Сертификаты
IPv6 Ready Logo Phase 2
• 4 порта 10/100Base-TX с поддержкой PoE
• 2 порта 10/100/1000Base-T
Стандарты и протоколы
• IEEE 802.3 10Base-T Ethernet (медная витая пара)
• IEEE 802.3u 100Base-TX Fast Ethernet (медная витая пара)
• IEEE 802.3ab 1000Base-T Gigabit Ethernet (медная витая пара)
• Управление потоком IEEE 802.3x
Производительность
Скорость перенаправления пакетов
• 2 МБ
Программное обеспечение
— Управление потоком 802.3x
— Предотвращение блокировок HOL
— Поддержка зеркалирования для входящего/ исходящего/ трафика в обоих направлениях
Многоадресная рассылка уровня 2
• Механизмы обработки очередей
— Weighted Round Robin (WRR)
Безопасность
Она реализуется с помощью протоколов маршрутизации: RIP, OSPF, EIGRP.
Возникновение долгоживущих маршрутных петель обусловлено ошибками в настройке процесса маршрутизации внутри домена маршрутизации.
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 на этом зарождающемся этапе (до широкого распространения) нецелесообразно и не нужно.