Что такое gRPC и зачем он нужен

Представьте, что ваши программы — это люди в огромном городе. Им нужно обмениваться информацией: один спрашивает адрес, другой — погоду, третий — заказывает еду. Если они общаются письмами (медленно и объемно), то город встанет в пробке. А если по телефону — быстро, четко и без лишних слов?

Вот gRPC (высокопроизводительный фреймворк для удаленного вызова процедур) — это как суперсовременная телефонная сеть для программ. Он позволяет одной программе вызывать функции в другой, как будто они работают на одном компьютере, но через интернет или сеть.

Зачем изучать gRPC в 2025 году? Потому что мир софта ушел от простых сайтов к сложным системам: миллиарды устройств в интернете вещей, тысячи микросервисов в компаниях вроде Netflix или Uber. Обычные веб-API (как REST) здесь тормозят — gRPC ускоряет всё в 7–10 раз, экономит трафик и упрощает разработку.


Что такое RPC: Простое объяснение концепции удаленного вызова процедур

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

Пример из жизни: Вы в приложении нажимаете "Получить погоду" — ваше мобильное app вызывает функцию на сервере метеослужбы. Сервер считает, возвращает данные. В gRPC это пишется так же просто:

Клиент (ваше app): ответ = сервер.ПолучитьПогоду(город="Москва")
Сервер: выполняет расчет и отдает результат.

Без RPC пришлось бы вручную формировать запросы, парсить ответы — утомительно. gRPC автоматизирует всё: генерирует готовый код, управляет соединением и ошибками. В итоге — код чище, быстрее и надежнее.


Разница gRPC с REST: Почему RPC побеждает в скорости и гибкости

REST (Representational State Transfer — архитектурный стиль для веб-API) — популярный подход, где API строится вокруг эндпоинтов для получения данных. Использует HTTP-методы (GET, POST), текст в формате JSON. Просто читать человеку, но медленно для машин.

Вот ключевые различия:

Формат данных: REST — текст (JSON, большой и медленный), gRPC — бинарный (компактный, в 3–10 раз меньше). JSON "Привет, мир!" — 15 байт, в gRPC — 5 байт.
Скорость: gRPC на HTTP/2 (мультиплексирование — много запросов по одному каналу) в 7 раз быстрее при приеме данных, в 10 раз — при отправке. Идеально для мобильного интернета.
Гибкость общения: REST — только "запрос-ответ". gRPC поддерживает стриминг (поток сообщений): сервер шлет обновления в реальном времени (как чат), клиент загружает файлы порциями, или оба общаются одновременно.
Языки и платформы: REST — универсален, но код пишется вручную. gRPC генерирует код для 10+ языков (Python, Go, Java) из одного описания — никаких несоответствий.
Отладка: REST читаем в браузере, gRPC — бинарный, но есть инструменты вроде gRPCurl (аналог curl).

REST хорош для публичных API (сайты, простые apps). gRPC — для внутренних систем, где важна производительность. В 2025 году компании комбинируют: REST снаружи, gRPC внутри.


#Java #middle #gRPC

Почему 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

Типы RPC в gRPC

Одно из ключевых преимуществ gRPC — это гибкость модели обмена данными.
REST традиционно работает в стиле “один запрос — один ответ”.
gRPC, в отличие от него, поддерживает четыре типа взаимодействия, и каждый из них решает свою задачу.


1. Unary RPC (один запрос — один ответ)

Это самый простой и самый распространённый тип — аналог классического REST-вызова.
Клиент отправляет один запрос, сервер обрабатывает его и возвращает один ответ.

Клиент → (один запрос) → Сервер
Сервер → (один ответ) → Клиент

Пример .proto

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int32 id = 1;
}

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

Сервер (Java)

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
    @Override
    public void getUser(UserRequest request, StreamObserver<UserResponse> responseObserver) {
        UserResponse response = UserResponse.newBuilder()
            .setName("Alice")
            .setAge(30)
            .build();

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

Клиент

UserResponse response = stub.getUser(
    UserRequest.newBuilder().setId(1).build()
);
System.out.println(response.getName());

Где применяется:
CRUD-операции (создание, получение, обновление, удаление).
Любые точечные вызовы, где не требуется поток данных.
По сути: это "REST, но бинарный, типобезопасный и в 10 раз быстрее".


2. Server Streaming RPC (поток ответов от сервера)

В этом типе клиент делает один запрос, а сервер возвращает несколько ответов последовательно — поток сообщений.

Клиент → (один запрос) → Сервер
Сервер → (много ответов в потоке) → Клиент

Сеанс продолжается, пока сервер не закончит отправку данных.

Пример .proto

service OrderService {
  rpc ListOrders (OrdersRequest) returns (stream Order);
}

message OrdersRequest {
  string user = 1;
}

message Order {
  string id = 1;
  string product = 2;
}

Сервер (Java)

public class OrderServiceImpl extends OrderServiceGrpc.OrderServiceImplBase {
    @Override
    public void listOrders(OrdersRequest request, StreamObserver<Order> responseObserver) {
        for (int i = 1; i <= 3; i++) {
            Order order = Order.newBuilder()
                .setId("ORD-" + i)
                .setProduct("Product " + i)
                .build();

            responseObserver.onNext(order);
            try { Thread.sleep(1000); } catch (InterruptedException ignored) {}
        }
        responseObserver.onCompleted();
    }
}

Клиент

stub.listOrders(OrdersRequest.newBuilder().setUser("Bob").build())
    .forEachRemaining(order -> System.out.println(order.getProduct()));

Где применяется:
Поток обновлений или уведомлений.
Стриминг данных (например, список записей, логи, результаты аналитики).
Долгие вычисления, когда сервер постепенно отдаёт результаты.

Пример из реального мира:
Сервер передаёт клиенту “живой” поток котировок акций или данных из IoT-устройств.


#Java #middle #gRPC #proto

3. Client Streaming RPC (поток запросов от клиента)

Теперь наоборот — клиент отправляет поток запросов, а сервер отвечает одним итоговым сообщением.

Клиент → (много запросов) → Сервер
Сервер → (один ответ) → Клиент

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

Пример .proto

service UploadService {
  rpc UploadPhotos (stream PhotoChunk) returns (UploadStatus);
}

message PhotoChunk {
  bytes content = 1;
}

message UploadStatus {
  string message = 1;
}

Сервер (Java)

public class UploadServiceImpl extends UploadServiceGrpc.UploadServiceImplBase {
    @Override
    public StreamObserver<PhotoChunk> uploadPhotos(StreamObserver<UploadStatus> responseObserver) {
        return new StreamObserver<PhotoChunk>() {
            int totalBytes = 0;

            @Override
            public void onNext(PhotoChunk chunk) {
                totalBytes += chunk.getContent().size();
            }

            @Override
            public void onError(Throwable t) {
                System.err.println("Upload failed: " + t.getMessage());
            }

            @Override
            public void onCompleted() {
                UploadStatus status = UploadStatus.newBuilder()
                    .setMessage("Uploaded " + totalBytes + " bytes")
                    .build();
                responseObserver.onNext(status);
                responseObserver.onCompleted();
            }
        };
    }
}

Клиент

StreamObserver<PhotoChunk> requestObserver = asyncStub.uploadPhotos(
    new StreamObserver<UploadStatus>() {
        @Override
        public void onNext(UploadStatus status) {
            System.out.println(status.getMessage());
        }
        @Override
        public void onError(Throwable t) {}
        @Override
        public void onCompleted() {}
    }
);

// Отправляем несколько чанков
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[1000])).build());
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[500])).build());
requestObserver.onCompleted();

Где применяется:
Отправка файлов по частям.
Отчёты, собираемые из нескольких частей.
Потоковое логирование от клиента на сервер.


#Java #middle #gRPC #proto

4. Bidirectional Streaming RPC (двунаправленный поток)

Самый мощный и сложный тип.
Клиент и сервер одновременно отправляют данные потоками.
Они не ждут завершения друг друга — общение идёт асинхронно в обе стороны.

Клиент ⇄ (двунаправленный поток) ⇄ Сервер

Пример .proto

service ChatService {
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message ChatMessage {
  string user = 1;
  string text = 2;
}

Сервер (Java)

public class ChatServiceImpl extends ChatServiceGrpc.ChatServiceImplBase {
    @Override
    public StreamObserver<ChatMessage> chat(StreamObserver<ChatMessage> responseObserver) {
        return new StreamObserver<ChatMessage>() {
            @Override
            public void onNext(ChatMessage message) {
                // Эхо-сообщение обратно клиенту
                ChatMessage reply = ChatMessage.newBuilder()
                    .setUser("Server")
                    .setText("Echo: " + message.getText())
                    .build();
                responseObserver.onNext(reply);
            }

            @Override
            public void onError(Throwable t) {
                System.err.println("Error: " + t.getMessage());
            }

            @Override
            public void onCompleted() {
                responseObserver.onCompleted();
            }
        };
    }
}

Клиент

StreamObserver<ChatMessage> requestObserver = asyncStub.chat(
    new StreamObserver<ChatMessage>() {
        @Override
        public void onNext(ChatMessage value) {
            System.out.println(value.getUser() + ": " + value.getText());
        }
        @Override
        public void onError(Throwable t) {}
        @Override
        public void onCompleted() {}
    }
);

requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("Hello!").build());
requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("How are you?").build());
requestObserver.onCompleted();

Где применяется:
Чаты и видеоконференции.
Онлайн-игры и взаимодействие в реальном времени.
Телеметрия, двунаправленные датчики, IoT.
Главная особенность: оба канала открыты, и клиент, и сервер могут посылать данные независимо друг от друга.


5. Под капотом

Все типы RPC работают поверх HTTP/2, где каждый поток — это отдельный канал в рамках одного TCP-соединения.
gRPC использует этот механизм для организации стримов.
По сути, StreamObserver в Java — это высокоуровневая абстракция над HTTP/2-стримом, обеспечивающая асинхронность и реактивное взаимодействие.


#Java #middle #gRPC #proto

gRPC в продакшене

1. Аутентификация и авторизация

gRPC изначально построен на HTTP/2, а значит поддерживает все стандартные механизмы шифрования и аутентификации, включая TLS/SSL.
На уровне протокола клиент и сервер могут обмениваться метаданными (headers), которые используются для передачи токенов, ключей или сессионных идентификаторов.

Аутентификация (authentication)

Аутентификация — это подтверждение личности клиента.

В gRPC это реализуется через метаданные (Metadata), которые добавляются к каждому запросу:

// Пример Java-клиента с авторизационным токеном
ManagedChannel channel = ManagedChannelBuilder
        .forAddress("localhost", 50051)
        .useTransportSecurity()
        .build();

CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc
        .newBlockingStub(channel)
        .withCallCredentials(new CallCredentials() {
            @Override
            public void applyRequestMetadata(
                    RequestInfo requestInfo, Executor executor, MetadataApplier applier) {
                Metadata headers = new Metadata();
                Metadata.Key<String> AUTHORIZATION =
                        Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER);
                headers.put(AUTHORIZATION, "Bearer my-secret-token");
                applier.apply(headers);
            }
        });

На стороне сервера этот токен можно проверить с помощью interceptor (см. ниже).

В корпоративных системах часто используются:
JWT (JSON Web Token) — стандартный формат токена.
mTLS (Mutual TLS) — двустороннее TLS-шифрование, где аутентифицируются обе стороны.
OAuth 2.0 — для интеграции с внешними провайдерами (Google, Auth0 и т.п.).

Авторизация (authorization)

После того как клиент прошёл аутентификацию, нужно проверить, имеет ли он право выполнять определённые действия.
Обычно авторизация реализуется на уровне interceptor’ов или бизнес-логики, где проверяются роли и права пользователя.


2. Interceptors — middleware для gRPC

Interceptors в gRPC выполняют ту же роль, что фильтры в Spring или middleware в Express.js.

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

Пример серверного interceptor’а

public class AuthInterceptor implements ServerInterceptor {
    @Override
    public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(
            ServerCall<ReqT, RespT> call,
            Metadata headers,
            ServerCallHandler<ReqT, RespT> next) {

        String token = headers.get(Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER));
        if (token == null || !token.equals("Bearer my-secret-token")) {
            call.close(Status.UNAUTHENTICATED.withDescription("Invalid token"), headers);
            return new ServerCall.Listener<>() {}; // пустой listener
        }

        return next.startCall(call, headers);
    }
}

Регистрируется interceptor при инициализации сервера:

Server server = ServerBuilder
        .forPort(50051)
        .addService(ServerInterceptors.intercept(new CarServiceImpl(), new AuthInterceptor()))
        .build()
        .start();

Interceptors можно комбинировать — например, один для логирования, другой для метрик, третий для авторизации.
Это делает gRPC гибким и расширяемым.


#Java #middle #gRPC #proto

3. gRPC Gateway — REST-прокси для совместимости

Хотя gRPC эффективен, не все клиенты умеют с ним работать напрямую (например, браузеры без gRPC-Web).
Чтобы не дублировать API, используется gRPC Gateway — это HTTP-прокси, который преобразует REST-запросы в gRPC-вызовы.

Как это работает
Клиент делает обычный HTTP-запрос (GET, POST, PUT).
Gateway принимает запрос и преобразует его в бинарный gRPC-вызов.
Сервер gRPC обрабатывает его и возвращает ответ.
Gateway обратно конвертирует ответ в JSON.

Файл .proto содержит специальные аннотации:

import "google/api/annotations.proto";

service CarService {
  rpc GetCar(GetCarRequest) returns (CarResponse) {
    option (google.api.http) = {
      get: "/v1/cars/{id}"
    };
  }
}

Так создаётся REST-эндпоинт /v1/cars/{id}, который вызывает gRPC-метод GetCar.

gRPC Gateway позволяет сохранять одну кодовую базу и одну схему, но обслуживать и gRPC-, и REST-клиентов одновременно.


4. Балансировка нагрузки и мониторинг

gRPC поддерживает client-side load balancing, когда клиент сам выбирает, к какому серверу подключаться, используя список адресов.
Это особенно важно для микросервисов, где количество экземпляров сервиса динамически меняется.

Поддерживаются различные политики: round-robin, pick-first, weighted.
В Kubernetes это можно комбинировать с сервис-дискавери (через DNS или Consul).

ManagedChannel channel = ManagedChannelBuilder
        .forTarget("dns:///my-grpc-service.default.svc.cluster.local")
        .defaultLoadBalancingPolicy("round_robin")
        .usePlaintext()
        .build();

Для продакшена жизненно важно собирать метрики.
gRPC интегрируется с Prometheus, OpenTelemetry, Zipkin, Jaeger для трассировки и мониторинга.

Через interceptors можно логировать время ответа, коды ошибок и нагрузку:

long start = System.nanoTime();
RespT response = next.startCall(call, headers);
long duration = System.nanoTime() - start;
metrics.recordLatency(duration);

Трассировка (tracing) позволяет увидеть цепочку вызовов между микросервисами — от клиента до базы данных.


5. Совместимость версий и эволюция схем

Когда сервисы растут, .proto-файлы меняются.
Важно, чтобы новые версии клиента и сервера могли работать вместе без сбоев.
Для этого protobuf предоставляет правила совместимости.

Основные правила миграции

Не менять номера полей.
Каждое поле в message имеет уникальный номер, и именно он используется при сериализации.
Изменить имя поля можно, номер — нельзя.

Резервировать удалённые поля.
Если поле больше не используется, его нужно “зарезервировать”:

message Car {
  reserved 4, 6 to 8;
  reserved "old_model", "legacy_color";
}

Это защищает от случайного переиспользования номеров или имён.

Добавлять новые поля безопасно.
Клиенты старых версий просто игнорируют незнакомые поля, сохраняя обратную совместимость.

Не менять тип данных существующих полей.
Например, int32 нельзя заменить на string.

Версионирование API

Часто версии отражаются в пакетах или namespace:

package car.v1;
service CarService { ... }

package car.v2;
service CarService { ... }

Так можно постепенно внедрять новые контракты без нарушения старых клиентов.


6. Как всё выглядит в продакшене

Реальная система на gRPC обычно включает:
Сервер с набором interceptor’ов (логирование, метрики, безопасность).
TLS-сертификаты и JWT-аутентификацию.
Балансировку через Kubernetes или сервис-дискавери.
Мониторинг и трассировку через OpenTelemetry.
gRPC Gateway для REST-клиентов.
CI/CD-пайплайн, генерирующий код по .proto и публикующий артефакты для разных языков.


#Java #middle #gRPC #proto