RPC-стиль

RPC-стиль — это архитектурный подход к проектированию программного обеспечения, основанный на принципах удалённого вызова процедур (Remote Procedure Call, RPC), при котором взаимодействие между клиентом и сервером строится вокруг вызова функций или методов, а не передачи документов или сообщений. В контексте веб-разработки и API RPC-стиль противопоставляется REST (Representational State Transfer) и другим подходам, таким как GraphQL. Основная идея заключается в том, что клиент отправляет запрос на выполнение определённой операции (например, «получить пользователя» или «создать заказ»), а сервер возвращает результат этой операции. Данный стиль ориентирован на действия (глаголы), а не на ресурсы (существительные), что отличает его от REST.

История и происхождение

Концепция удалённого вызова процедур возникла в 1970-х годах в рамках распределённых вычислительных систем. Первые реализации, такие как Xerox Network Systems (XNS) и Sun RPC (1980-е годы), заложили основы для передачи вызовов функций между узлами сети. В 1990-х годах RPC-стиль получил распространение в корпоративных системах через протоколы CORBA (Common Object Request Broker Architecture) и DCOM (Distributed Component Object Model) от Microsoft. Однако эти технологии были сложны в реализации и имели проблемы с совместимостью.

Возрождение RPC-стиля произошло в 2000-х годах с появлением веб-сервисов на основе XML-RPC и SOAP (Simple Object Access Protocol). SOAP, разработанный консорциумом W3C, стал стандартом для корпоративных приложений, но критиковался за избыточность и сложность. В 2010-х годах RPC-стиль вернулся в упрощённой форме — JSON-RPC и gRPC. gRPC, созданный компанией Google в 2015 году, стал популярным выбором для микросервисной архитектуры благодаря высокой производительности и поддержке бинарной сериализации (Protocol Buffers).

Основные принципы

RPC-стиль базируется на следующих концепциях:

• Вызов процедуры как действие: Клиент вызывает именованную функцию на сервере, передавая параметры. Например, getUserById(123) или createOrder(items, address).
• Синхронность или асинхронность: По умолчанию RPC-вызовы синхронны — клиент ждёт ответа, но современные реализации (например, gRPC) поддерживают потоковую передачу и асинхронные вызовы.
• Строгая типизация: В gRPC и других современных реализациях контракты (интерфейсы) определяются с помощью IDL (Interface Definition Language), что обеспечивает проверку типов на этапе компиляции.
• Прозрачность расположения: Идеал RPC — сделать удалённый вызов процедуры неотличимым от локального, что упрощает разработку, но может скрывать проблемы с сетью и задержками.

Виды RPC-стилей

Классический RPC (Sun RPC, DCE/RPC)

Использует бинарные протоколы и часто привязан к конкретным языкам программирования (например, C). Применялся в операционных системах и сетевых файловых системах (NFS).

XML-RPC и SOAP

Основаны на XML. XML-RPC — простой протокол для вызова процедур через HTTP. SOAP — более сложный стандарт с поддержкой безопасности, транзакций и расширений (WS-*). SOAP используется в корпоративных системах (например, в банковских и ERP-системах), но считается громоздким.

JSON-RPC

Лёгкий протокол, использующий JSON для сериализации. Определяет формат запроса: {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}. Ответ содержит результат или объект ошибки. JSON-RPC популярен в веб-приложениях и инструментах автоматизации (например, в Ethereum).

gRPC

Современный RPC-фреймворк от Google, использующий Protocol Buffers (protobuf) для сериализации и HTTP/2 для транспорта. Поддерживает четыре типа вызовов: простой (unary), потоковая передача от сервера, потоковая передача от клиента и двунаправленная потоковая передача. gRPC широко применяется в микросервисах, мобильных приложениях и системах реального времени.

Thrift

Разработан Facebook (в настоящее время компания Meta признана экстремистской и запрещена в РФ) как кроссплатформенный RPC-фреймворк. Использует собственный IDL и поддерживает множество языков (C++, Java, Python, PHP и др.). Thrift популярен в высоконагруженных системах (например, в Cassandra и Hadoop).

Сравнение с REST

RPC-стиль и REST представляют собой два противоположных подхода к проектированию API:

• Модель данных: REST оперирует ресурсами (существительными), RPC — действиями (глаголами). В REST каждый URL представляет ресурс (/users/123), а методы HTTP (GET, POST, PUT, DELETE) определяют действия. В RPC URL или имя метода указывают на операцию (/api/getUser).
• Сложность: REST проще для понимания и кэширования, но требует большего количества эндпоинтов для сложных операций. RPC позволяет объединить несколько действий в один вызов, но может привести к сильной связанности клиента и сервера.
• Производительность: gRPC и Thrift быстрее REST/JSON благодаря бинарной сериализации и сжатию. Однако REST легче отлаживать и тестировать.
• Кэширование: REST поддерживает кэширование на уровне HTTP, что упрощает масштабирование. RPC, особенно gRPC, требует дополнительных механизмов кэширования.

Применение

RPC-стиль используется в следующих областях:

• Микросервисная архитектура: gRPC и Thrift являются стандартными инструментами для общения между микросервисами в высоконагруженных системах (например, в Netflix, Uber, Яндекс).
• Мобильные приложения: gRPC поддерживает стриминг и бинарные протоколы, что снижает нагрузку на сеть и ускоряет работу мобильных клиентов.
• Веб-сервисы: JSON-RPC используется в API криптовалют (Bitcoin, Ethereum) и в системах управления контентом (WordPress XML-RPC).
• Корпоративные системы: SOAP применяется в банковских и государственных системах, где требуется строгая стандартизация и безопасность (например, в системах SWIFT и SAP).
• Встраиваемые системы и IoT: gRPC для встраиваемых устройств (gRPC-Web) позволяет управлять датчиками и исполнительными механизмами через лёгкие RPC-вызовы.

Критика

RPC-стиль подвергается критике по нескольким причинам:

• Проблема прозрачности расположения: Попытка сделать удалённый вызов неотличимым от локального приводит к игнорированию сетевых задержек, частичных отказов и проблем с надёжностью. Это может вызывать неожиданные ошибки в распределённых системах.
• Сильная связанность: RPC-интерфейсы часто жёстко привязаны к реализации сервера. Изменение сигнатуры метода может потребовать обновления всех клиентов.
• Сложность отладки: Бинарные протоколы (gRPC, Thrift) сложнее отлаживать, чем текстовые (JSON, XML), хотя существуют инструменты для визуализации (например, gRPC UI).
• Отсутствие стандартизации: В отличие от REST, где методы HTTP и статус-коды стандартизированы, RPC-стиль не имеет единого стандарта для обработки ошибок и версионирования.

Интересные факты

• Термин «RPC» впервые был введён в 1976 году Брюсом Джеем Нельсоном в его докторской диссертации в Университете Карнеги-Меллон.
• gRPC изначально разрабатывался внутри Google для внутренних нужд и был открыт в 2015 году. Он используется в таких продуктах Google, как Google Cloud Pub/Sub, Google Kubernetes Engine и Google Ads.
• В России RPC-стиль активно применяется в платформах Яндекса (например, в сервисе Яндекс.Такси и в облачной платформе Yandex Cloud) для обеспечения высокой производительности микросервисной архитектуры.
• JSON-RPC используется в протоколе Ethereum для взаимодействия с узлами блокчейна, что позволяет разработчикам создавать децентрализованные приложения (dApps).

Источники

• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Диссертация, Калифорнийский университет в Ирвайне.
• gRPC. (2023). Официальная документация. Google.
• JSON-RPC Working Group. (2013). JSON-RPC 2.0 Specification.
• Thrift. (2022). Apache Thrift Documentation. Apache Software Foundation.
• Нельсон, Б. Дж. (1976). Remote Procedure Call. Докторская диссертация, Университет Карнеги-Меллон.
• SOAP Version 1.2. (2007). W3C Recommendation.