Когда нужно применять gRPC?

Когда нужно применять gRPC

gRPC (gRPC Remote Procedure Call) — это современный фреймворк для взаимодействия между сервисами. Расскажу когда его использовать и как его тестировать.

Что такое gRPC

gRPC — это RPC фреймворк на базе Protocol Buffers (protobuf) и HTTP/2. Вместо JSON он использует binary formат для более быстрого серилизации.

Основные характеристики:

• Использует HTTP/2 (мультиплексирование)
• Binary serialization (Protocol Buffers)
• Быстрее чем REST API
• Поддерживает streaming (client-to-server, server-to-client, bidirectional)
• Strongly typed (schema-driven)

Когда ИСПОЛЬЗОВАТЬ gRPC

1. Микросервисная архитектура (Micro-services Communication)

gRPC идеален для общения между сервисами.

Почему:

• Сервисы часто общаются друг с другом
• REST API добавляет overhead
• gRPC в 7-10 раз быстрее
• Protocol Buffers обеспечивают контракт

Пример:

Order Service → Payment Service (gRPC call)
Order Service → Inventory Service (gRPC call)
Order Service → Notification Service (gRPC call)

2. Real-time приложения

Когда нужны streaming и low latency.

Примеры:

• Чаты и мессенджеры (bidirectional streaming)
• Видеоконференции
• Online gaming
• Финансовые системы (котировки в реальном времени)
• IoT системы

Streaming типы:

1. Unary: обычный запрос-ответ (как REST)
2. Server streaming: сервер отправляет поток данных
3. Client streaming: клиент отправляет поток данных
4. Bidirectional streaming: оба отправляют потоки

3. Высоконагруженные системы

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

Почему gRPC лучше:

• Binary формат < JSON (меньше трафика)
• HTTP/2 multiplexing (одно соединение, много запросов)
• Быстрая сериализация
• Меньше CPU и памяти

Пример: При 10,000 запросов в секунду REST может потребовать 10 серверов, gRPC — 2-3 сервера.

4. Внутренняя коммуникация (не публичный API)

gRPC требует protobuf schema, поэтому хорош для внутренних систем.

Не подходит для:

• Публичный API для браузера (HTTP/2 Server Push не везде поддерживается)
• CRUD операции без потоков
• Простые интеграции

Когда НЕ использовать gRPC

1. Публичное REST API

Браузер не может напрямую вызвать gRPC. Нужен gateway (grpc-gateway).

2. Простые CRUD операции

REST с JSON проще для простых случаев.

3. Прототипирование

Разработка медленнее (нужно писать .proto файлы). REST быстрее для MVP.

4. Интеграция со сторонними системами

Если партнёр поддерживает только REST.

gRPC vs REST vs GraphQL

Тестирование gRPC

Инструменты для тестирования:

1. grpcurl (как curl для gRPC)

# Список сервисов
grpcurl -plaintext localhost:50051 list

# Вызов метода
grpcurl -plaintext \
  -d '{"user_id": 123}' \
  localhost:50051 \
  my.package.UserService/GetUser

2. Postman

• Поддерживает gRPC (версия 10+)
• GUI для тестирования
• Сохранение сценариев

3. Python grpcio

import grpc
from my_proto import user_pb2, user_pb2_grpc

channel = grpc.secure_channel('localhost:50051', ...)
stub = user_pb2_grpc.UserServiceStub(channel)

request = user_pb2.GetUserRequest(user_id=123)
response = stub.GetUser(request)
print(response.name)

4. Go testing

conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
if err != nil {
    t.Fatalf("Failed to dial: %v", err)
}

client := pb.NewUserServiceClient(conn)
resp, err := client.GetUser(context.Background(), &pb.GetUserRequest{UserId: 123})
assert.NoError(t, err)
assert.Equal(t, "John", resp.Name)

5. Load testing (k6)

import grpc from 'k6/net/grpc';

const client = new grpc.Client();
client.connect('localhost:50051', { plaintext: true });

export default function() {
  const response = client.invoke('my.package.UserService/GetUser', 
    {user_id: Math.floor(Math.random() * 1000)}
  );
  check(response, {
    'status is OK': (r) => r.status === grpc.StatusOK,
  });
}

Тестовые сценарии для gRPC

1. Unary RPC

Тест: Получение пользователя
Request: {user_id: 123}
Expected: {name: "John", email: "john@example.com"}

2. Server Streaming

Тест: Получить список товаров (streaming)
Request: {category: "electronics"}
Expected: Получить поток товаров (10, 20, 50 штук)

3. Client Streaming

Тест: Загрузить логи
Request: Отправить 100 логов в потоке
Expected: Server вернёт подтверждение

4. Bidirectional Streaming

Тест: Chat
Client отправляет сообщение → Server отправляет ответ
Оба могут отправлять независимо

5. Error Handling

Тест: Несуществующий пользователь
Request: {user_id: 999999}
Expected: Status NotFound (код 5)
Expected: Message: "User not found"

Практический пример

Proto файл (schema):

syntax = "proto3";

package user.v1;

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

message GetUserRequest {
  int32 user_id = 1;
}

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

message ListUsersRequest {
  int32 limit = 1;
}

Тест на Python:

import grpc
import pytest
from user_pb2 import GetUserRequest, User
from user_pb2_grpc import UserServiceStub

@pytest.fixture
def grpc_stub():
    channel = grpc.insecure_channel('localhost:50051')
    return UserServiceStub(channel)

def test_get_user(grpc_stub):
    request = GetUserRequest(user_id=1)
    response = grpc_stub.GetUser(request)
    
    assert response.id == 1
    assert response.name == "Alice"
    assert response.email == "alice@example.com"

def test_user_not_found(grpc_stub):
    request = GetUserRequest(user_id=99999)
    
    with pytest.raises(grpc.RpcError) as exc_info:
        grpc_stub.GetUser(request)
    
    assert exc_info.value.code() == grpc.StatusCode.NOT_FOUND

Мой опыт с gRPC

Использовал в:

• Микросервисной архитектуре (5+ сервисов общаются через gRPC)
• Real-time уведомлениях (server streaming)
• High-load системах (10K RPS)

Преимущества которые видел:

• Скорость в 5-10 раз выше чем REST
• Type-safety благодаря protobuf
• Меньше багов на граничах сервисов

Сложности:

• Сложнее дебаггировать (binary format)
• Требует schema-first подход
• Меньше инструментов мониторинга

Вывод

gRPC идеален для:

• Микросервисного взаимодействия
• Real-time приложений
• High-load систем
• Streaming-heavy операций

Но для простых CRUD REST API или публичных API остаётся лучшим выбором.