Компьютерные сети
RPC: gRPC, Thrift
Google обрабатывает 10 миллиардов RPC вызовов в секунду внутри своей инфраструктуры. gRPC родился из внутренней системы Stubby. Когда JSON/REST недостаточно быстр - RPC спасает.
- **Google** - внутренняя инфраструктура полностью на gRPC (бывший Stubby)
- **Netflix** - gRPC между микросервисами, REST для API
- **Uber** - Thrift для legacy, gRPC для новых сервисов
Предварительные знания
Remote Procedure Call
**RPC (Remote Procedure Call)** - парадигма, где вызов функции на удалённом сервере выглядит как локальный вызов. Ты пишешь `userService.getUser(123)`, а под капотом происходит сериализация, HTTP запрос, десериализация ответа.
Идея RPC появилась в 1980-х (Sun RPC, CORBA). Современные реализации: gRPC (Google), Thrift (Facebook), Twirp (Twitch). Альтернатива - REST API, где ты явно работаешь с HTTP.
**Leaky abstraction:** RPC скрывает сеть, но не её проблемы. Latency, partial failures, retries - всё это остаётся. Локальный вызов занимает наносекунды, RPC - миллисекунды-секунды.
**Компоненты RPC системы:** • **IDL (Interface Definition Language)** - описание API (Protobuf, Thrift IDL) • **Code generator** - генерирует client/server stubs из IDL • **Serialization** - бинарная (Protobuf) или текстовая (JSON) • **Transport** - HTTP/2, TCP, Unix sockets
Какую проблему RPC НЕ решает автоматически?
gRPC
**gRPC** - современный RPC фреймворк от Google. Использует HTTP/2 для транспорта и Protocol Buffers для сериализации. Поддерживает streaming, bidirectional communication, deadline propagation.
**gRPC-Web** - вариант gRPC для браузеров. Браузеры не поддерживают HTTP/2 trailers, поэтому gRPC-Web использует proxy (Envoy) для транслирования.
Какой транспортный протокол использует gRPC?
Protocol Buffers
**Protocol Buffers (Protobuf)** - бинарный формат сериализации от Google. Компактнее JSON в 3-10 раз, быстрее в 20-100 раз. Схема определяется в .proto файлах, код генерируется для любого языка.
**Wire format:** Каждое поле кодируется как (field_number << 3 | wire_type) + value. Это позволяет пропускать неизвестные поля - ключ для backward compatibility.
Почему Protobuf безопасно добавлять новые поля в схему?
Apache Thrift
**Apache Thrift** - RPC фреймворк от Facebook (теперь Apache). Похож на gRPC, но старше и с другими design decisions. Поддерживает множество транспортов (TCP, HTTP, Unix socket) и протоколов сериализации (Binary, Compact, JSON).
**Thrift в Big Data:** Parquet (columnar storage) использует Thrift для metadata. Многие Hadoop tools используют Thrift для IPC. Если работаешь с data engineering - Thrift встретится чаще, чем gRPC.
**Другие RPC системы:** • **Twirp** (Twitch) - gRPC-подобный, но на HTTP/1.1 JSON/Protobuf • **Connect** (Buf) - gRPC-compatible с поддержкой HTTP/1.1 • **Cap'n Proto** - zero-copy serialization, быстрее Protobuf • **FlatBuffers** (Google) - zero-copy для games/embedded
В чём главное отличие Thrift от gRPC?
RPC vs REST
**RPC** - action-oriented: "выполни операцию". **REST** - resource-oriented: "управляй ресурсами через CRUD". Оба подхода валидны, выбор зависит от use case.
**GraphQL** - третий путь. Клиент запрашивает ровно те поля, которые нужны. Решает проблему over-fetching (REST) и N+1 (без batching). Но добавляет сложность на сервере.
**Hybrid подход:** REST/GraphQL для внешних клиентов (браузеры, mobile), gRPC для внутренних сервисов. API Gateway транслирует между протоколами.
gRPC всегда лучше REST для микросервисов
gRPC оптимален для internal services, REST - для public APIs и browser clients
gRPC требует HTTP/2 (не все прокси поддерживают), бинарный формат сложнее дебажить, браузеры не поддерживают нативно. REST проще для интеграции, документации, кеширования. Выбор зависит от контекста
Когда gRPC предпочтительнее REST для microservices?
Итоги
- **RPC** скрывает сетевые вызовы за интерфейсом локальных функций (leaky abstraction)
- **gRPC** - HTTP/2 + Protobuf, streaming, deadline propagation
- **Protobuf** - бинарная сериализация, в 3-10x компактнее JSON, backward compatible
- **Thrift** - альтернатива с гибкими транспортами и сериализациями
- **REST vs RPC** - resource-oriented vs action-oriented; часто hybrid подход
Связанные темы
RPC - один из способов коммуникации в распределённых системах:
- Сети распределённых систем — Partial failures и latency влияют на RPC
- Message Queues — Асинхронная альтернатива синхронному RPC
Вопросы для размышления
- Какие операции в твоём API лучше выразить как RPC, а какие как REST resources?
- Как бы ты обработал backward compatibility при добавлении обязательного поля в Protobuf?
- Какой streaming mode gRPC подходит для real-time notifications?