Почему Google создал gRPC: От внутренних нужд к мировому стандарту

Google — гигант с миллионами микросервисов (маленькие программы, работающие вместе). С 2001 года они использовали внутренний фреймворк Stubby для их связи. Но Stubby был закрытым, и партнерам (Android, YouTube API) приходилось писать свои библиотеки.

В 2015 году Google открыл gRPC: эволюцию Stubby на HTTP/2 и Protocol Buffers (protobuf — бинарный формат для данных).

Цели:
Объединить сервисы в дата-центрах и на устройствах.
Поддержка стриминга для реал-тайма.
Автоматическая генерация кода — один .proto-файл для всех языков.

К 2025 году gRPC — проект CNCF (Cloud Native Computing Foundation), используется в Google Cloud, Netflix (стриминг видео), Uber (поездки в реальном времени), Cisco. За 10 лет обработал триллионы вызовов — доказанная надежность.


Где применяется gRPC: От микросервисов до умных устройств

gRPC — король сценариев с высокой нагрузкой:
Микросервисы: Тысячи маленьких сервисов в Kubernetes (оркестратор контейнеров). Netflix использует для рекомендаций фильмов — миллиарды запросов в секунду без задержек. Внутренняя связь: сервис оплаты "звонит" сервису доставки.
Интернет вещей (IoT): Миллиарды устройств (умные лампочки, датчики). gRPC соединяет их с облаком: низкий трафик, стриминг данных (температура в реальном времени). Пример: умный дом от Google Nest.
Внутренние API: В компаниях — связь backend'ов. Uber: расчет маршрутов между сервисами. Банки: обработка транзакций. Не для клиентов (там REST), а внутри — для скорости.

В 2025: gRPC в AI (TensorFlow), играх (реал-тайм мультиплеер), авто (Tesla — связь машин с облаком).


#Java #middle #gRPC

Архитектура gRPC: как всё работает под капотом

gRPC — это современный фреймворк удалённого вызова процедур (RPC, Remote Procedure Call), разработанный Google. Он позволяет приложениям общаться друг с другом как будто они вызывают локальные функции, хотя на самом деле взаимодействие идёт по сети. Чтобы понять, почему gRPC так эффективен, нужно разобрать его архитектуру и то, что происходит «под капотом».

1. Концепция gRPC: RPC-модель нового поколения

RPC (Remote Procedure Call) — это подход, при котором одна программа может вызвать функцию, которая физически исполняется на другом сервере.
В классической модели RPC разработчик просто вызывает метод, а инфраструктура берёт на себя всё — упаковку данных, передачу по сети и распаковку на другой стороне.

gRPC реализует эту идею, но в современном, высокопроизводительном виде — поверх HTTP/2 и с использованием Protocol Buffers для сериализации.

2. Основные участники архитектуры

Клиент (Client)
Это программа, которая инициирует вызов удалённого метода. Она не знает деталей того, как сервер устроен внутри.
Клиент работает с client stub — это локальный объект, который выглядит как обычный класс с методами, но при вызове каждого метода на самом деле выполняется сетевое обращение к серверу.

Сервер (Server)
Это приложение, которое реализует интерфейс, описанный в .proto файле. Сервер принимает запросы от клиентов, обрабатывает их и отправляет ответы.


Client Stub и Server Stub

Что такое Stub
Stub — это «заглушка», или точнее — сгенерированный код, который связывает ваш код с gRPC-инфраструктурой.

Client Stub (клиентская заглушка) — это класс, который содержит методы, соответствующие сервисам, определённым в .proto.
Когда вы вызываете метод stub.buyCar(request), gRPC автоматически:

Сериализует объект request в бинарный формат.

Отправляет его по сети через HTTP/2.

Получает ответ, десериализует и возвращает его как обычный объект Java.

Server Stub — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.

Пример:

// .proto файл
syntax = "proto3";

service CarService {
  rpc BuyCar (CarRequest) returns (CarResponse);
}

message CarRequest {
  string model = 1;
  int32 budget = 2;
}

message CarResponse {
  string status = 1;
}

После генерации protoc создаёт классы:

CarServiceGrpc.CarServiceImplBase — Server Stub

CarServiceGrpc.CarServiceBlockingStub и CarServiceGrpc.CarServiceFutureStub — Client Stubs

Реализация сервера:

public class CarServiceImpl extends CarServiceGrpc.CarServiceImplBase {
    @Override
    public void buyCar(CarRequest request, StreamObserver<CarResponse> responseObserver) {
        String result = "You bought: " + request.getModel();
        CarResponse response = CarResponse.newBuilder()
            .setStatus(result)
            .build();

        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

Клиент:

ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
        .usePlaintext()
        .build();

CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc.newBlockingStub(channel);

CarRequest request = CarRequest.newBuilder()
        .setModel("Tesla Model 3")
        .setBudget(50000)
        .build();

CarResponse response = stub.buyCar(request);
System.out.println(response.getStatus());

#Java #middle #gRPC

3. Роль Protocol Buffers (protobuf)

Protocol Buffers — это бинарный формат сериализации данных, разработанный Google. Он выполняет две функции:

Описание структуры данных (через .proto файл).
Это аналог схемы JSON или XML, но строгий и типизированный.

Сериализация и десериализация (преобразование объектов в компактную бинарную форму и обратно).

Пример .proto файла не только описывает сообщения, но и определяет сервис (то есть API интерфейс).

Почему protobuf — ключевой элемент:
Он компактен: бинарный формат в несколько раз меньше JSON.
Он типобезопасен: при компиляции проверяются типы.
Он быстр: сериализация и десериализация работают на уровне байтов, без парсинга текста.

4. Как происходит сериализация и десериализация

Сериализация — это процесс превращения объекта в поток байтов для передачи по сети.
Десериализация — обратный процесс.

В gRPC:
Клиент вызывает метод stub.method(request).
request сериализуется с помощью Protocol Buffers в бинарный поток.
Поток отправляется через HTTP/2.
Сервер принимает поток, десериализует его обратно в объект CarRequest.
После обработки сервер сериализует ответ (CarResponse) и отправляет обратно.

Важно: gRPC сам управляет сериализацией. Вам не нужно ничего кодировать вручную — всё делает сгенерированный stub.

5. Что делает protoc и зачем нужны плагины

protoc — это компилятор Protocol Buffers. Он принимает .proto файл и генерирует исходный код для нужного языка.

Например:

protoc --java_out=./build/generated proto/car.proto

gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.

protoc --plugin=protoc-gen-grpc-java=path/to/protoc-gen-grpc-java \
       --grpc-java_out=./build/generated \
       --java_out=./build/generated \
       proto/car.proto

Таким образом, protoc создаёт:
Классы-сообщения (CarRequest, CarResponse)
gRPC классы (CarServiceGrpc, Stub и ImplBase)

Для каждого языка есть свой плагин:
--grpc-java_out для Java
--grpc-python_out для Python
--grpc-go_out для Go
и т. д.

Это и есть причина, почему gRPC мультиплатформенный — интерфейс описывается один раз в .proto, а код для всех языков генерируется автоматически.

6. Почему gRPC быстрее REST

gRPC построен поверх HTTP/2, а REST — чаще всего поверх HTTP/1.1. Разница принципиальна.

Ключевые причины производительности:
HTTP/2 поддерживает мультиплексирование — можно отправлять несколько запросов в одном соединении без блокировки.
Сжатие заголовков (HPACK) уменьшает накладные расходы.
Бинарная сериализация (protobuf) — меньше данных, быстрее парсинг.
Постоянное соединение — нет затрат на открытие/закрытие TCP для каждого запроса.
Streaming — можно передавать поток данных, а не ждать полного ответа (например, поток логов или большого файла).

7. Суммарно: что происходит при вызове метода в gRPC

Пошагово:
Клиент вызывает метод stub.someMethod(request).
Stub сериализует объект через protobuf.
Сериализованные данные упаковываются в HTTP/2 фрейм и отправляются на сервер.
Сервер принимает фрейм, десериализует данные.
Вызвается метод реализации (ImplBase).
Сервер формирует ответ, сериализует через protobuf.
Ответ отправляется обратно по тому же соединению.
Клиент получает и десериализует ответ.

Для разработчика — это выглядит как обычный вызов функции.
Под капотом же происходит оптимизированное сетевое взаимодействие с минимальными потерями.


#Java #middle #gRPC

Protocol Buffers: сердце gRPC

Если gRPC — это двигатель взаимодействия сервисов, то Protocol Buffers (protobuf) — это его сердце.
Именно protobuf определяет, как описываются данные, как они сериализуются, и как из одной схемы генерируются типобезопасные классы для разных языков.

Чтобы по-настоящему понимать gRPC, нужно уверенно работать с .proto-файлами.

1. Что такое .proto файл

.proto — это файл описания структуры данных и интерфейсов (API).

Он играет сразу три роли:
Документирует контракт между клиентом и сервером (описывает, какие методы и какие данные доступны).
Генерирует код для разных языков с помощью protoc (компилятора Protocol Buffers).
Определяет схему сериализации — то, как объекты превращаются в байты и обратно.
Фактически .proto — это единый источник правды для вашего API.


2. Базовая структура .proto файла

Пример простого файла:

syntax = "proto3";

package car;

option java_multiple_files = true;
option java_package = "com.example.car";
option java_outer_classname = "CarProto";

// Определение сообщений
message Car {
  string model = 1;
  int32 year = 2;
  CarStatus status = 3;
}

// Перечисление (enum)
enum CarStatus {
  ACTIVE = 0;
  INACTIVE = 1;
}

// Определение сервиса
service CarService {
  rpc BuyCar (CarRequest) returns (CarResponse);
}

message CarRequest {
  string model = 1;
}

message CarResponse {
  string confirmation = 1;
}

3. Ключевые элементы .proto

3.1. syntax

Первая строка файла:

syntax = "proto3";

Обязательно указывает версию синтаксиса.
На практике используется только proto3, потому что она проще, строже типизирована и лучше поддерживается в gRPC.

3.2. package

Задает логическое пространство имён, чтобы избежать конфликтов:

package car;

В Java и других языках это превращается в пакеты/модули.

3.3. option

Позволяет задавать настройки генерации кода, например:

option java_package = "com.example.car";
option java_multiple_files = true;
option java_outer_classname = "CarProto";

Без этого весь код попадёт в один файл, что неудобно для больших схем.

3.4. message — описание структуры данных

message — это аналог класса в объектно-ориентированных языках.
Каждое поле внутри него — это свойство (переменная), которое сериализуется в бинарный поток.

Пример:

message User {
  string name = 1;
  int32 age = 2;
  repeated string hobbies = 3;
}


string name = 1; — поле с типом string и номером 1.

int32 age = 2; — целочисленное поле.

repeated string hobbies = 3; — массив строк.

Важно: номер поля (= 1, = 2, = 3) — это не просто индекс. Это ключ в бинарной сериализации, который должен быть уникален и неизменен.

3.5. enum — перечисление значений

enum — это список допустимых констант.

enum CarStatus {
  ACTIVE = 0;
  INACTIVE = 1;
  SOLD = 2;
}

Значение 0 обязательно — это значение по умолчанию.

При сериализации хранится не текстовое имя ("ACTIVE"), а его числовое значение (0), что делает protobuf компактным.

3.6. service — описание API

service определяет набор удалённых методов, которые сервер предоставляет клиенту.

Это аналог интерфейса в Java:

service CarService {
  rpc BuyCar (CarRequest) returns (CarResponse);
  rpc ListCars (Empty) returns (CarList);
}

Каждый rpc определяет:
имя метода (BuyCar),
входной тип (CarRequest),
выходной тип (CarResponse).

4. Типы данных в Protocol Buffers

Protobuf поддерживает ограниченный, но универсальный набор типов.

Некоторые часто используемые:

string - Текст
bool - Логическое значение
int32, int64 - Целые числа
float, double - Числа с плавающей точкой
bytes - Массив байтов
repeated - Массив
map<key, value> - Словарь

Пример:

message Garage {
  map<string, Car> cars = 1;
}

#Java #middle #gRPC #proto

5. Нумерация полей — почему это критично

Каждое поле имеет свой уникальный номер — это его идентификатор в бинарном потоке.

message Car {
  string model = 1;
  int32 year = 2;
}

Если поменять номера, клиент и сервер перестанут понимать друг друга.
Например, если у старой версии клиента year = 2, а у новой year = 3, при сериализации они будут читать разные данные.


6. Почему важно резервировать поля

Когда вы удаляете или переименовываете поле, нельзя просто убрать строку — нужно зарезервировать номер и имя.

Пример:

message Car {
  string model = 1;
  reserved 2;             // резервируем номер
  reserved "status_old";  // резервируем имя
}

Это предотвращает случайное переиспользование старого номера под другое поле, что может привести к неправильной интерпретации данных.


7. Эволюция и миграция схем (Schema Evolution)

Protobuf специально спроектирован так, чтобы позволять обновлять схемы без поломки совместимости.
Главное — соблюдать несколько правил.

Что можно делать безопасно:
Добавлять новые поля с новыми номерами.
Удалять поля (с их резервированием).
Изменять имя поля (номер должен остаться прежним).
Изменять порядок полей — не влияет на сериализацию.

Что делать нельзя:
Менять тип поля (например, int32 → string).
Менять номер поля.
Удалять поле без reserved.

Пример миграции

Старая версия:

message User {
  string name = 1;
  int32 age = 2;
}

Новая версия:

message User {
  string name = 1;
  reserved 2;
  string email = 3;
}

Старый клиент, который не знает про email, просто проигнорирует это поле.
А новый клиент не столкнётся с конфликтом, потому что старый 2 зарезервирован.


8. Компиляция .proto файла и генерация кода

protoc — компилятор, который читает .proto и создаёт Java-классы.

Пример команды:

protoc \
  --java_out=./build/generated \
  --grpc-java_out=./build/generated \
  proto/car.proto

Результат:
Для каждого message создаются классы с Builder-паттерном.
Для service создаются классы CarServiceGrpc, CarServiceImplBase, CarServiceStub.


9. Пример полного цикла

Файл car.proto:

syntax = "proto3";

service CarService {
  rpc BuyCar (CarRequest) returns (CarResponse);
}

message CarRequest {
  string model = 1;
  int32 budget = 2;
}

message CarResponse {
  string message = 1;
}

Сгенерированный код в Java (упрощённо):

// Отправитель (клиент)
CarRequest request = CarRequest.newBuilder()
    .setModel("BMW")
    .setBudget(20000)
    .build();

CarResponse response = stub.buyCar(request);
System.out.println(response.getMessage());

Серверная реализация:

public class CarServiceImpl extends CarServiceGrpc.CarServiceImplBase {
    @Override
    public void buyCar(CarRequest request, StreamObserver<CarResponse> responseObserver) {
        String msg = "Car purchased: " + request.getModel();
        CarResponse response = CarResponse.newBuilder().setMessage(msg).build();

        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

#Java #middle #gRPC #proto