GRPC

В основе работы gRPC лежат несколько ключевых компонентов:

• Protocol Buffers (Protobuf): По умолчанию gRPC использует Protobuf в качестве языка описания интерфейсов (IDL) и формата обмена сообщениями. Protobuf — это механизм сериализации структурированных данных, разработанный Google. В специальных файлах с расширением .proto описывается структура данных (сообщения) и сервисы с их методами. Этот формат является бинарным, что делает его более компактным и быстрым по сравнению с текстовыми форматами вроде JSON или XML^[17].
• Определение сервисов: В файле .proto разработчик определяет сервис, указывая методы, которые можно вызвать удалённо, а также типы их входных и выходных сообщений^[18]. Этот файл служит «контрактом» между клиентом и сервером.
• Транспорт на базе HTTP/2: gRPC использует протокол HTTP/2, который обеспечивает значительные преимущества по сравнению с HTTP/1.1. Ключевые возможности HTTP/2, используемые в gRPC, — это мультиплексирование (отправка нескольких запросов и ответов в рамках одного TCP-соединения), двунаправленная потоковая передача и сжатие заголовков.
• Генерация кода: На основе файла .proto компилятор protoc автоматически генерирует код для клиента (заглушка, или stub) и сервера (скелет) на множестве поддерживаемых языков программирования, таких как C++, Java, Python, Go и других. Это избавляет от необходимости писать шаблонный код для сериализации, десериализации и сетевого взаимодействия^[19].

Процесс взаимодействия между клиентом и сервером в gRPC выглядит следующим образом:

1. Определение контракта: Разработчик создает файл .proto, в котором описывает сервис, его методы и структуры сообщений (запросы и ответы).
2. Генерация кода: С помощью компилятора protoc генерируется серверный интерфейс и клиентская заглушка (stub).
3. Реализация на сервере: На стороне сервера разработчик реализует сгенерированный интерфейс, то есть пишет логику для методов, определенных в контракте. Затем запускается gRPC-сервер, который слушает входящие вызовы.
4. Вызов на клиенте: На стороне клиента есть локальный объект-заглушка (stub), который реализует те же методы, что и сервис на сервере.
5. Взаимодействие: Клиентское приложение вызывает метод у объекта-заглушки^[17]. Заглушка сериализует параметры запроса в бинарный формат Protobuf и отправляет их на сервер по протоколу HTTP/2^[20]. Сервер получает сообщение, десериализует его, выполняет соответствующий метод и отправляет сериализованный ответ обратно клиенту^[20].

gRPC поддерживает четыре типа удалённых вызовов процедур:

• Унарный вызов (Unary RPC): Самый простой тип, аналогичный обычному вызову функции. Клиент отправляет один запрос и получает один ответ от сервера.
• Серверная потоковая передача (Server streaming RPC): Клиент отправляет один запрос, а в ответ получает поток сообщений от сервера^[21]. Это полезно, когда серверу нужно передать большой объем данных^[21].
• Клиентская потоковая передача (Client streaming RPC): Клиент отправляет на сервер поток сообщений^[18]. После того как клиент завершит передачу, сервер отправляет в ответ одно сообщение^[22].
• Двунаправленная потоковая передача (Bidirectional streaming RPC): Обе стороны (клиент и сервер) могут отправлять друг другу сообщения в рамках одного соединения, используя независимые потоки. Это позволяет создавать сложные интерактивные и real-time приложения^[21].

История gRPC берёт начало с внутреннего фреймворка Google, который назывался Stubby и был создан около 2001 года. Он использовался как универсальная RPC-инфраструктура для соединения большого количества микросервисов в центрах обработки данных компании. На протяжении почти 15 лет Stubby был ключевым элементом внутренней архитектуры Google, обрабатывая миллиарды запросов в секунду.

В марте 2015 года Google приняла решение разработать следующую версию Stubby, сделав её общедоступной и с открытым исходным кодом под названием gRPC. Целью было предоставить широкому сообществу разработчиков те же возможности масштабируемости и производительности, которые были доступны внутри Google^[23]. В отличие от своего предшественника, новый фреймворк был построен на основе современного стандарта HTTP/2 и использовал Protocol Buffers в качестве языка описания интерфейсов (IDL). По словам разработчиков, буква «g» в названии, изначально означавшая «Google», с каждым новым релизом получает новое шуточное значение.

В августе 2016 года вышла версия gRPC 1.0, что означало готовность фреймворка к использованию в производственных средах. К этому моменту он уже поддерживал множество языков программирования, включая C++, Java, Go, Node.js, Ruby, Python и C#^[23]. Важным этапом в признании технологии стало её принятие в Cloud Native Computing Foundation (CNCF) в качестве инкубационного проекта в феврале 2017 года.

В 2018 году фреймворк gRPC продолжал активно развиваться, следуя регулярному шестинедельному циклу релизов. В течение года было выпущено множество версий, начиная с v1.8 и заканчивая v1.17 в декабре^[24]. Основные усилия были направлены на повышение производительности, стабильности и добавление новых функций в реализациях для различных языков программирования.

Ключевые моменты развития в 2018 году:

• gRPC Core и C++: Команда gRPC совместно с компанией Kitware Inc. начала работу по модернизации поддержки CMake для упрощения процесса сборки и интеграции фреймворка^[25].
• gRPC Java: Реализация для Java получила несколько заметных нововведений. Начиная с версии 1.15.0 (сентябрь 2018 года), была прекращена поддержка Java 6, а минимально необходимой версией стала Java 7^[26]. В версии 1.14.0 были улучшены возможности балансировки нагрузки^[27], а в версии 1.15.0 реализовано объединение пакетов (flush coalescing) для оптимизации сетевого взаимодействия и представлен `GoogleDefaultChannelBuilder` для упрощённой настройки безопасного соединения в среде Google Compute Engine^[26].
• gRPC Go: В версии v1.10.0 была добавлена опция `CallContentSubtype`, позволяющая переопределять подтип контента для RPC-вызова^[28]. Кроме того, выход Go 1.11 в августе 2018 года с начальной поддержкой модулей заложил основу для упрощения управления зависимостями в проектах, использующих gRPC^[29].
• gRPC C#: В ноябре 2018 года началась работа над новой, полностью управляемой реализацией `grpc-dotnet` для .NET Core. Этот проект, создаваемый Microsoft в сотрудничестве с Google, был призван обеспечить более глубокую интеграцию с экосистемой ASP.NET Core и в будущем заменить реализацию на базе нативной библиотеки C-core^[25].
• gRPC PHP: В течение года расширение для PHP регулярно обновлялось для поддержки новых версий ядра gRPC (1.8, 1.9, 1.10), а также были исправлены утечки памяти, связанные с созданием каналов и обработкой метаданных^[30].

Таким образом, 2018 год стал для gRPC периодом планомерного развития существующих возможностей и годом начала стратегически важных проектов, таких как новая реализация для .NET.

В 2019 году фреймворк gRPC продолжил своё активное развитие, следуя шестинедельному циклу релизов. В течение года было выпущено несколько версий ядра gRPC (gRPC Core), от v1.18.0 в январе до v1.26.0 в декабре, которые затрагивали зависимые языки, такие как C++, C#, Objective-C, PHP, Python и Ruby^[31].

Одним из главных событий 2019 года стало развитие и популяризация gRPC-Web — технологии, которая позволила использовать gRPC непосредственно в браузерных приложениях^[32]. Ранее это было невозможно из-за ограничений браузерных API по работе с HTTP/2. gRPC-Web работает через небольшой прокси-сервер, который транслирует запросы между браузером (использующим HTTP/1.1) и gRPC-сервером (использующим HTTP/2)^[32], открывая для веб-разработчиков доступ к таким преимуществам gRPC, как строгая типизация, высокая производительность и работа с потоками данных^[32]. В течение года выходили обновления для gRPC-Web, включая релизы 1.0.7 и 1.1.0, которые добавили новые функции, например, поддержку перехватчиков (interceptors)^[33].

В течение года выходили обновления для различных языковых реализаций:

• Go: В 2019 году вышли версии Go 1.12 и 1.13^[34]. В реализации gRPC для Go (grpc-go) в версии v1.18.0 появилась экспериментальная опция `WaitForReady`, позволяющая управлять поведением RPC в ожидании готовности соединения^[35].
• PHP: В версии v1.20.0 были исправлены утечки памяти и ошибки сегментации, а в v1.23.0 — ошибки в конструкторе каналов. Релиз v1.26.0 включал обновления ядра, улучшения производительности и возможность задавать кастомное местоположение логов через php.ini^[36].
• Dart: В реализации для Dart была добавлена поддержка декодирования `grpc-status-details-bin` для получения более детальной информации об ошибках^[35].
• C#: Продолжался выпуск обновлений для C#, например, версии v1.19.0 и v1.20.0^[37].

В целом, 2019 год стал для gRPC периодом укрепления позиций в качестве стандарта для межсервисного взаимодействия и значительного расширения его применения на фронтенде благодаря gRPC-Web.

В 2020 году развитие фреймворка gRPC было в значительной степени сосредоточено на интеграции с сервисными сетями (service mesh) путём внедрения поддержки API xDS (eXtensible Discovery Service), что заложило основу для работы gRPC-сервисов без прокси-сайдкаров. В течение года выходили регулярные релизы, улучшающие производительность и расширяющие возможности для различных языков программирования. Было выпущено несколько версий gRPC, начиная с v1.27.0 и заканчивая v1.35.0, с периодичностью примерно раз в шесть недель^[31].

Центральным событием года стало внедрение и стабилизация поддержки xDS — API, изначально созданного для конфигурации прокси-сервера Envoy. Эта функциональность позволила gRPC-клиентам получать конфигурацию для балансировки нагрузки и маршрутизации напрямую от управляющего слоя (control plane) сервисной сети, такого как Istio или Google Cloud Service Mesh, минуя необходимость в развертывании отдельного прокси-сайдкара.

Ключевые этапы внедрения xDS:

• Апрель 2020 (v1.28.0): Была добавлена экспериментальная клиентская реализация API xDS v2 для языков Go и C++^[38]. Это позволило клиентам, написанным на этих языках, получать конфигурацию от совместимого с xDS сервера для балансировки нагрузки RPC-вызовов^[38].
• Июнь 2020 (v1.30.0): Состоялся знаковый релиз, в котором схема URI xds-experimental была заменена на стабильную xds^[39]. Эта функциональность стала доступна для C++, Python, Ruby, PHP и C#^[39]. Данный выпуск считается первым, обеспечившим базовую поддержку gRPC в режиме «proxyless service mesh», включая обнаружение сервисов, балансировку нагрузки и разделение трафика^[40].

В ноябре 2020 года на конференции EnvoyCon была представлена презентация, подробно описывающая интеграцию поддержки xDS в gRPC и преимущества для развертываний в сервисных сетях^[41].

Помимо работы над xDS, в 2020 году в gRPC были внесены и другие улучшения:

• gRPC Core: В версии 1.27.0 (февраль 2020) был добавлен новый подмодуль для libuv, улучшена поддержка системных корневых сертификатов на Android и исправлены сборки с OpenSSL 1.1.1+ на Windows^[38].
• Python: В течение года было добавлено несколько улучшений для асинхронной работы с asyncio. В частности, в версии 1.28.0 появилась поддержка сервисера для проверки работоспособности (health-checking), а в v1.30.0 — поддержка инструмента для интроспекции состояния канала Channelz и клиентских перехватчиков (interceptors) для потоковой передачи^[38].
• PHP: В конце года с выходом версии 1.34.0 была прекращена поддержка PHP 5 и добавлена поддержка PHP 8.
• Kotlin: В 2020 году активно продвигалось использование Kotlin с gRPC для создания современных бэкэнд-сервисов^[42].

В 2021 году фреймворк gRPC продолжил активное развитие, выпуская обновления примерно каждые шесть недель^[31]. В течение года вышли версии от v1.35 в январе до v1.42 в конце года^[31]. Основные изменения касались улучшения производительности, расширения функциональности и поддержки новых платформ.

Ключевые обновления 2021 года:

• Поддержка ARM64: В июне 2021 года была официально анонсирована поддержка запуска gRPC и Protocol Buffers на 64-битной архитектуре ARM (ARM64) в Linux^[43]. Этот шаг был обусловлен растущей популярностью ARM-процессоров в облачных вычислениях и встраиваемых системах.
• Развитие gRPC для .NET: Microsoft продолжила активное развитие реализации gRPC для .NET. В мае было объявлено, что будущее gRPC на платформе C# связано с библиотекой grpc-dotnet, которая пришла на смену Grpc.Core^[43]. С выходом .NET 6 в ноябре 2021 года gRPC получил значительные улучшения производительности, поддержку балансировки нагрузки на стороне клиента, механизм повторных попыток для обработки временных сбоев и поддержку HTTP/3^[31].
• Анализ трафика с помощью Wireshark: В феврале 2021 года была представлена возможность анализировать сообщения gRPC с использованием Wireshark^[43]. Это упростило отладку и разработку, позволив разработчикам детально изучать трафик, передаваемый по сети.

Помимо этого, продолжалось развитие экосистемы сторонних инструментов. Например, в августе 2021 года библиотека grpc-requests для Python получила полную поддержку TLS-соединений^[44]. В целом, 2021 год для gRPC был периодом стабильного развития, направленного на повышение производительности, расширение поддержки платформ и улучшение инструментов для разработчиков.

В 2022 году развитие фреймворка gRPC было сосредоточено на повышении производительности, расширении функциональности и адаптации к современным облачным средам. Одним из значимых шагов стало прекращение поддержки Java 7 в релизе gRPC-Java 1.44.0 в январе 2022 года^[45], который перешёл на байт-код Java 8^[45]. В августе вышла версия gRPC-Java 1.49.0, в которой был представлен новый балансировщик нагрузки с функцией обнаружения выбросов (outlier detection)^[46].

В марте 2022 года команда gRPC объявила о переносе своих тестов производительности в среду Google Kubernetes Engine (GKE) для получения более релевантных результатов в облачных средах.

Ярким примером внедрения gRPC в индустрии стал переход компании Uber на использование фреймворка для своей платформы push-уведомлений. В августе 2022 года компания сообщила о миграции с Server-Sent Events на двунаправленную потоковую передачу на базе gRPC^[47], что позволило упростить архитектуру и разработку новых функций^[47].

В мае было продлено время поддержки старой библиотеки `Grpc.Core` для C# до мая 2023 года, хотя основной фокус сместился на `grpc-dotnet`. Также продолжали выходить обновления для других языков, включая PHP^[48] и Go^[49].

В 2023 году развитие фреймворка gRPC характеризовалось планомерным выпуском обновлений, улучшением производительности и стабильности, а также важными изменениями в поддержке различных языков программирования. Следуя своему графику релизов, который предполагает выпуск новых версий примерно каждые шесть недель, в течение года были представлены версии gRPC с 1.52.0 по 1.60.0^[31][50].

gRPC Core (ядро фреймворка) получило ряд существенных улучшений, в частности, в версии 1.60.0. Была добавлена функциональность отслеживания каталога со списками отозванных сертификатов (CRL), внесены улучшения в работу движка событий (EventEngine) и реализована экспериментальная поддержка двухстековых конечных точек IPv4/IPv6^[51].

Обновления для языков программирования:

• C#: В октябре 2023 года было объявлено о продлении срока поддержки пакета Grpc.Core как минимум до октября 2024 года, чтобы дать разработчикам больше времени для миграции со старых версий .NET Framework. Рекомендованной реализацией при этом остаётся grpc-dotnet^[52].
• Java: Было подтверждено продолжение поддержки Java 8^[53], а также добавлен API для сбора статистики и трассировки (census)^[54].
• Go: Добавлена опция CallAuthority для переопределения заголовка :authority и по умолчанию включён балансировщик нагрузки «least request» (наименьшее количество запросов) при использовании xDS.
• Python: В ноябре 2023 года была добавлена поддержка Python 3.12^[55]. Пакет grpcio регулярно обновлялся в соответствии с релизами ядра gRPC^[56].
• PHP: В течение года стабильно выходили новые версии расширения, от 1.53.0 до 1.60.0^[57].
• Ruby: Библиотеки для Ruby регулярно обновлялись в соответствии с общим циклом релизов^[58].

Для gRPC-Web в ноябре 2023 года вышла версия 1.5.0, которая содержала различные улучшения, в том числе связанные с обработкой метаданных.

В целом, 2023 год продемонстрировал стабильное и последовательное развитие фреймворка, направленное на повышение его производительности, безопасности и удобства использования в различных средах и на разных языках программирования.

В 2024 году развитие фреймворка gRPC было сосредоточено на улучшении производительности, расширении функциональности и упрощении работы для разработчиков. Ключевые направления включали интеграцию с современными облачными технологиями, улучшения в области сервисных сетей (service mesh) и расширение поддержки языков программирования.

Основные направления развития и новые возможности:

• Service Mesh без прокси (Proxyless Service Mesh): Продолжилось совершенствование архитектуры сервисной сети без использования sidecar-прокси, что позволяет снизить задержки и потребление ресурсов. Была представлена возможность настройки gRPC в таком режиме с использованием Kubernetes Gateway API, что упрощает развертывание в облачных средах^[59].
• Поддержка OpenTelemetry: Была добавлена и улучшена поддержка OpenTelemetry для клиента и сервера Ktor, что позволяет генерировать данные телеметрии для лучшей наблюдаемости систем^[60].
• Расширение поддержки языков: Велась работа по добавлению официальной поддержки языка Rust^[61], Apple представила новую библиотеку для gRPC на языке Swift^[61], а в дорожную карту Ktor была включена интеграция gRPC для Kotlin^[60].
• Искусственный интеллект и gRPC: На конференции gRPConf 2024 обсуждался потенциал больших языковых моделей (LLM) для трансформации разработки с использованием gRPC^[59].

Важным событием года стала конференция gRPConf 2024, прошедшая 27 августа в кампусе Google в Саннивейле, Калифорния^[62]. На ней были представлены доклады от инженеров Google, Netflix, Apple и других технологических компаний. Основные темы включали обзор состояния gRPC, отраслевые тренды, десятилетнюю историю фреймворка и новые возможности^[61].

В 2025 году развитие фреймворка gRPC планируется сосредоточить на углублении интеграции с сервисными сетями, улучшении наблюдаемости, повышении расширяемости и дальнейшей адаптации для современных распределённых систем, включая приложения на базе искусственного интеллекта. Ключевые анонсы и планы были представлены на конференциях gRPC Conf.

Основные направления развития gRPC в 2025 году:

• Service Mesh без прокси (Proxyless Service Mesh): Продолжение совершенствования работы gRPC в рамках концепции сервисной сети без использования sidecar-прокси для более нативной и производительной интеграции^[63]. Планируются изменения для более естественной интеграции с Istio, что позволит избавиться от небезопасного соединения с агентом Istio.
• Улучшенная наблюдаемость с Channel ZV2: Для упрощения отладки gRPC-приложений будет представлена вторая версия инструмента ChannelZ — Channel ZV2. Она предоставит более гибкие и быстрые способы анализа иерархии ресурсов gRPC без необходимости изменять сам протокол. Первую реализацию планируется выпустить для C++ в конце года.
• Глобальное ограничение скорости (Global Rate Limiting): Внедрение новой функции для глобального управления частотой запросов. Она будет использовать существующий протокол xDS и новый протокол RLQS для агрегации информации о нагрузке с серверов, что позволит принимать решения об ограничении скорости на глобальном уровне.
• Новая модель плагинов и расширяемость: В стадии проектирования находится новая модель плагинов, которая позволит командам платформ внедрять сквозную логику, например, для авторизации, развернув специальный сервер (ext proc server) и настроив сервисную сеть на работу с ним.
• Интеграция с бессерверными архитектурами: Признавая, что сервисные сети используются не только в Kubernetes, команда gRPC работает над улучшением интеграции с бессерверными (serverless) решениями.
• gRPC и искусственный интеллект: Продолжение развития направления, связанного с использованием больших языковых моделей (LLM) для оптимизации рабочих процессов с gRPC, основываясь на обсуждениях с gRPConf 2024.

На 26 августа 2025 года запланирована конференция gRPConf в кампусе Google в Саннивейле, где будут представлены последние обновления и примеры использования gRPC. В целом, gRPC укрепляет свои позиции как высокопроизводительный фреймворк для межсервисного взаимодействия в микросервисных архитектурах, IoT-системах и мобильных приложениях^[64].

Apache Thrift — фреймворк, изначально разработанный в Facebook, является одной из главных и наиболее зрелых альтернатив gRPC^[65]. Он продолжает активно развиваться под эгидой Apache Software Foundation^[66]. На протяжении 2019—2025 годов фреймворк регулярно получал обновления, направленные на повышение безопасности и стабильности, включая выпуск версий 0.13.0 в 2019 году для устранения уязвимостей^[67], 0.16.0 в 2022 году^[68], 0.21.0 в 2024 году и 0.22.0 в мае 2025 года^[69]. Несмотря на более медленные темпы развития по сравнению с gRPC, Thrift остаётся востребованным решением для высоконагруженных кросс-языковых сервисов^[70].

JSON-RPC — легковесный протокол удалённого вызова процедур, спецификация которого (версия 2.0) остаётся стабильной с 2013 года^[71]. Его основное преимущество — простота реализации^[72]. В 2022 году для него была предложена спецификация OpenRPC, аналогичная OpenAPI для REST, позволяющая автоматически генерировать документацию и код^[73]. В 2023 году протокол получил новый виток популярности с ростом фреймворка tRPC, который использует принципы JSON-RPC для создания полностью типизированных API в экосистеме TypeScript без необходимости кодогенерации^[74][75].

XML-RPC — один из ранних протоколов RPC, предшественник SOAP^[76]. К 2019 году он уже считался устаревшей технологией. В последующие годы он в основном упоминался в контексте проблем безопасности, в частности, в WordPress, где его использование было связано с brute-force и DDoS-атаками, что привело к рекомендациям по его отключению^[77][78]. Активного развития протокол не получает и в новых проектах практически не используется, уступив место REST и gRPC^[79].

ASN.1 (Abstract Syntax Notation One) — это не RPC-фреймворк, а международный стандарт для описания и кодирования данных, широко используемый в телекоммуникациях и криптографии^[80]. Стандарт развивается медленно, но стабильно; последняя крупная ревизия стандартов серии X.680 была опубликована ITU-T в 2021 году^[81]. Его развитие в основном касается обновления инструментов (компиляторов) и применения в новых стандартах связи, таких как 5G^[82].

Другие фреймворки. Помимо крупных игроков, в период 2019—2024 годов приобрели популярность более легковесные и нишевые RPC-фреймворки, часто созданные как более простые альтернативы gRPC:

• Twirp — фреймворк от Twitch, использующий Protocol Buffers, но работающий поверх HTTP/1.1 и JSON, что упрощает его использование и отладку^[83].
• ConnectRPC (ранее connect-go) — ещё одна альтернатива в экосистеме Go, совместимая с gRPC, но предлагающая более идиоматичный подход с использованием стандартных HTTP-методов^[83].
• BusRPC — фреймворк, представленный в 2023 году, который использует брокер сообщений NATS в качестве транспорта для разработки микросервисов^[84].