Міжсервісна взаємодія на основі протоколу gRPC

Еволюція міжсервісної комунікації: від REST до RPC

Архітектурні обмеження REST API у розподілених системах

REST (Representational State Transfer) є домінуючим архітектурним стилем для побудови вебсервісів протягом останніх двох десятиліть. REST-архітектура базується на кількох фундаментальних принципах: ресурсна орієнтація, використання стандартних HTTP-методів (GET, POST, PUT, DELETE), відсутність стану на сервері (stateless) та єдиний інтерфейс (uniform interface). Ці принципи забезпечили REST величезну популярність завдяки простоті розуміння, легкості інтеграції та універсальності.

Проте при побудові великих розподілених систем, що складаються з десятків або сотень мікросервісів, REST-підхід виявляє кілька суттєвих обмежень, які стають критичними для продуктивності та зручності розробки.

Обмеження 1: Текстовий формат серіалізації та накладні витрати JSON.

Майже всі REST API використовують JSON як формат обміну даними. JSON є текстовим форматом, що робить його легкочитаним для людини та простим у налагодженні. Однак серіалізація та десеріалізація JSON є обчислювально витратною операцією. Парсинг JSON вимагає лексичного аналізу, побудови дерева об'єктів у пам'яті та приведення типів. Для високонавантажених систем, де окремий сервіс обробляє десятки тисяч запитів на секунду, ці витрати можуть становити 15–25% процесорного часу.

Крім того, JSON не має вбудованої схеми (schema). Структура даних визначається лише документацією (OpenAPI/Swagger) або прикладами, що призводить до проблем сумісності версій. Якщо сервер додає нове поле або змінює тип існуючого поля, старі клієнти можуть некоректно інтерпретувати відповідь або взагалі відхилити її.

Обмеження 2: Відсутність строгих контрактів між клієнтом та сервером.

REST API зазвичай документуються за допомогою специфікацій OpenAPI (Swagger), які описують ендпоінти, параметри, типи відповідей та коди помилок. Проте ці специфікації є описовими, а не обов'язковими до виконання (descriptive, not prescriptive). Немає гарантії, що сервер дійсно відповідає специфікації, або що клієнт коректно обробляє всі можливі відповіді. Помилки невідповідності виявляються лише під час виконання (runtime), часто вже у продакшн-середовищі.

Кодогенерація клієнтських бібліотек зі специфікації OpenAPI існує (наприклад, інструменти openapi-generator, swagger-codegen), але згенерований код часто є громіздким, важким у підтримці та не завжди коректно відображає реальну поведінку API. Розробники змушені вручну перевіряти відповідність коду специфікації або писати інтеграційні тести для кожного ендпоінту.

Обмеження 3: Неефективність HTTP/1.1 для міжсервісної комунікації.

Більшість REST API працюють поверх протоколу HTTP/1.1, який має кілька вбудованих обмежень. По-перше, HTTP/1.1 не підтримує мультиплексування запитів (request multiplexing). Якщо клієнт хоче виконати кілька паралельних запитів до одного сервера, він повинен відкрити кілька TCP-з'єднань (зазвичай браузери обмежують це значення до 6 з'єднань на домен). Кожне нове з'єднання вимагає виконання TCP-рукостискання (3-Way Handshake), що додає 1–2 додаткові мережеві обміни та затримку у 50–200 мілісекунд залежно від географічної відстані.

По-друге, HTTP/1.1 передає заголовки у текстовому форматі без стиснення. Типовий HTTP-запит містить сотні байтів заголовків (Host, User-Agent, Accept, Authorization, Content-Type тощо), які повторюються у кожному запиті. Для коротких запитів (наприклад, отримання статусу завдання) розмір заголовків може перевищувати розмір корисного навантаження у 3–5 разів.

По-третє, HTTP/1.1 є напівдуплексним протоколом (half-duplex): клієнт надсилає запит, чекає на відповідь, і лише після цього може надіслати наступний запит у тому ж з'єднанні. Це призводить до ефекту Head-of-Line Blocking, коли повільний запит блокує всі наступні запити у черзі.

Обмеження 4: Відсутність нативної підтримки потокових операцій.

REST є моделлю «запит-відповідь», де кожен запит очікує єдину завершену відповідь. Проте багато реальних сценаріїв вимагають потокової передачі даних (streaming). Наприклад:

• Завантаження великого списку об'єктів (мільйони записів) частинами, не завантажуючи весь набір у пам'ять.
• Відстеження прогресу довготривалої операції (експорт даних, обробка відео).
• Отримання оновлень у реальному часі (фінансові котирування, телеметрія IoT-пристроїв).

Для реалізації цих сценаріїв у REST доводиться використовувати обхідні шляхи: пагінацію (клієнт виконує серію запитів GET /items?page=1, GET /items?page=2...), довге опитування (long polling) або відкривати окремі WebSocket-з'єднання поза REST API. Усі ці підходи додають архітектурну складність та зменшують ефективність системи.

Концепція віддаленого виклику процедур (RPC)

Remote Procedure Call (RPC) — це парадигма комп'ютерної комунікації, що дозволяє програмі викликати функцію або процедуру, яка виконується на іншій машині (або в іншому процесі), так, ніби це локальний виклик. Основна ідея RPC полягає у тому, щоб абстрагувати деталі мережевої взаємодії та надати розробнику зручний інтерфейс, що не відрізняється від звичайних викликів функцій.

Розглянемо різницю між REST та RPC на прикладі простої операції створення користувача.

REST-підхід:

// Клієнтський код
type User struct {
    Name  string `json:"name"`
    Email string `json:"email"`
}

func createUserREST(apiURL string, user User) error {
    payload, _ := json.Marshal(user)
    
    resp, err := http.Post(
        apiURL+"/api/v1/users",
        "application/json",
        bytes.NewReader(payload),
    )
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    
    if resp.StatusCode != http.StatusCreated {
        body, _ := io.ReadAll(resp.Body)
        return fmt.Errorf("API error %d: %s", resp.StatusCode, body)
    }
    
    return nil
}

Клієнтський код повинен вручну серіалізувати об'єкт у JSON, сконструювати HTTP-запит, перевірити статус-код відповіді, обробити помилки та десеріалізувати тіло відповіді. Усі ці деталі є деталями реалізації транспортного рівня, які не мають відношення до бізнес-логіки.

RPC-підхід (концептуально):

// Клієнтський код
client := userservice.NewClient("user-service.local:50051")

err := client.CreateUser(ctx, &User{
    Name:  "Alice Johnson",
    Email: "alice@example.com",
})
if err != nil {
    return err
}

Клієнт викликає метод CreateUser як звичайну функцію. Усі деталі серіалізації, мережевої передачі, обробки помилок та десеріалізації приховані всередині згенерованого клієнтського коду (stub). З точки зору розробника, виклик виглядає локальним.

Історична еволюція RPC-технологій

Концепція RPC не є новою — її витоки сягають 1970-х років. Розглянемо ключові віхи еволюції RPC-систем, щоб зрозуміти, які проблеми вирішує сучасний gRPC.

1. Sun RPC / ONC RPC (1980-ті роки).

Один із перших стандартизованих RPC-фреймворків, розроблений компанією Sun Microsystems. Використовувався у розподілених файлових системах (NFS — Network File System). Контракти описувалися мовою XDR (External Data Representation), що визначала формат серіалізації. Sun RPC був обмежений мовою C та платформою Unix, що унеможливлювало міжплатформну інтеграцію.

2. CORBA (Common Object Request Broker Architecture, 1990-ті роки).

Амбітний стандарт, розроблений консорціумом OMG (Object Management Group), що мав на меті забезпечити RPC-комунікацію між об'єктами, написаними різними мовами програмування (C++, Java, Ada). Контракти описувалися мовою IDL (Interface Definition Language). CORBA був надзвичайно складним у налаштуванні та підтримці, що призвело до його поступового відмирання на початку 2000-х років.

3. XML-RPC та SOAP (2000-ті роки).

XML-RPC запропонував простий текстовий формат виклику процедур через HTTP, використовуючи XML для серіалізації параметрів та результатів. SOAP (Simple Object Access Protocol) розширив XML-RPC, додавши підтримку складних типів даних, безпеки (WS-Security), транзакцій (WS-Transaction) та надійної доставки. SOAP став стандартом у корпоративному світі (банки, телекомунікації, державні системи), але його складність та багатослівність XML призвели до появи альтернатив.

4. JSON-RPC (середина 2000-х років).

Спрощена версія XML-RPC, що використовує JSON замість XML. JSON-RPC набув популярності у веброзробці завдяки легкості інтеграції з JavaScript, але не отримав широкого визнання у сфері міжсервісної комунікації через відсутність стандартизації та промислових реалізацій.

5. Apache Thrift та Avro (2007–2009).

Проєкти з відкритим вихідним кодом, розроблені компаніями Facebook (Thrift) та LinkedIn (Avro у складі Hadoop). Обидва фреймворки використовують бінарну серіалізацію та генерацію коду для різних мов програмування. Thrift набув популярності у розподілених системах, але його складність та фрагментація реалізацій обмежували прийняття.

6. gRPC (2015, Google).

Сучасний RPC-фреймворк, розроблений компанією Google на основі внутрішньої системи Stubby, що обслуговує мільярди запитів на секунду у інфраструктурі Google. gRPC поєднує кращі риси попередніх технологій:

• Бінарну серіалізацію Protocol Buffers для максимальної продуктивності.
• HTTP/2 як транспортний протокол для мультиплексування, стиснення заголовків та двостороннього потокового обміну.
• Кодогенерацію для десятків мов програмування (Go, Java, C++, Python, C#, JavaScript, Rust тощо).
• Вбудовану підтримку потокових операцій (Server Streaming, Client Streaming, Bidirectional Streaming).
• Розширену екосистему інструментів для балансування навантаження, моніторингу, трейсингу та service mesh інтеграції (Istio, Linkerd).

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam timeline {
    BackgroundColor #E2E8F0
}

scale 1.2

|Епоха мейнфреймів|
:1970–1980
Sun RPC / ONC RPC;
note right #FEF3C7
  - Мова C, Unix
  - XDR серіалізація
  - NFS, RPC Compiler
end note

|Об'єктно-орієнтована ера|
:1990–2000
CORBA / DCOM;
note right #FECACA
  - Надзвичайна складність
  - IDL, ORB, Name Service
  - Міжмовна інтеграція
end note

|Епоха веб-сервісів|
:2000–2010
XML-RPC → SOAP;
note right #DBEAFE
  - XML серіалізація
  - WS-* стандарти
  - Корпоративні системи
end note

:2007–2009
Apache Thrift, Avro;
note right #DCFCE7
  - Бінарна серіалізація
  - Facebook, LinkedIn
  - Hadoop екосистема
end note

|Епоха мікросервісів|
:2015–теперішній час
**gRPC + Protobuf**;
note right #D4F4DD
  - HTTP/2 транспорт
  - Потокові виклики
  - Service Mesh ready
  - Кросплатформенність
end note

@enduml

Protocol Buffers: мова опису контрактів та бінарна серіалізація

Філософія та архітектура Protocol Buffers

Protocol Buffers (скорочено Protobuf) — це мова опису структур даних (Interface Definition Language, IDL) та формат бінарної серіалізації, розроблений компанією Google. Protobuf вирішує дві фундаментальні задачі:

1. Декларативне визначення контрактів між клієнтом та сервером у формі файлів .proto, які є джерелом істини (single source of truth) для структури даних.
2. Високоефективна бінарна серіалізація, що забезпечує компактне представлення даних у мережі та швидку серіалізацію/десеріалізацію.

На відміну від JSON або XML, де структура даних визначається неявно через приклади або документацію, Protobuf вимагає явного опису схеми (schema). Ця схема компілюється за допомогою утиліти protoc (Protocol Buffers Compiler) у вихідний код обраної мови програмування (Go, Java, C++, Python тощо). Згенерований код містить структури даних, методи серіалізації та валідації, що гарантує повну сумісність між клієнтом та сервером на етапі компіляції (compile-time type safety).

Синтаксис файлів .proto: базові конструкції

Файли Protocol Buffers мають розширення .proto та використовують декларативний синтаксис для опису повідомлень (messages), перелічень (enums) та сервісів (services). Розглянемо базові конструкції на прикладі системи управління користувачами.

// user.proto
syntax = "proto3";

package userservice;

option go_package = "github.com/example/userservice/pb";

// Повідомлення User описує структуру даних користувача
message User {
  // Кожне поле має унікальний числовий ідентифікатор (field number)
  int64 id = 1;
  string name = 2;
  string email = 3;
  UserStatus status = 4;
  int64 created_at = 5;
}

// Перелічення можливих статусів користувача
enum UserStatus {
  USER_STATUS_UNSPECIFIED = 0;  // Нульове значення обов'язкове у proto3
  USER_STATUS_ACTIVE = 1;
  USER_STATUS_SUSPENDED = 2;
  USER_STATUS_DELETED = 3;
}

// Запит на створення користувача
message CreateUserRequest {
  string name = 1;
  string email = 2;
}

// Відповідь на створення користувача
message CreateUserResponse {
  User user = 1;
}

// Запит на отримання користувача за ідентифікатором
message GetUserRequest {
  int64 id = 1;
}

// Відповідь з даними користувача
message GetUserResponse {
  User user = 1;
}

Покрокове пояснення синтаксису:

Рядок 2: syntax = "proto3";

Вказує версію синтаксису Protocol Buffers. Версія proto3 є поточною стабільною версією, що спрощує синтаксис порівняно з proto2 (видалені обов'язкові поля required, спрощена обробка значень за замовчуванням). Усі нові проєкти повинні використовувати proto3.

Рядок 4: package userservice;

Визначає простір імен для згенерованого коду. У Go це буде перетворено на назву пакета, у Java — на Java package, у C++ — на namespace. Це запобігає колізіям імен при імпорті кількох .proto файлів.

Рядок 6: option go_package = "...";

Вказує повний шлях імпорту для згенерованого Go-коду. Це критично важливо для коректної роботи Go Modules. Значення має відповідати структурі вашого репозиторію.

Рядки 9–16: Повідомлення message User

Описує структуру даних користувача. Кожне поле має:

• Тип даних: int64, string, UserStatus (власний enum), тощо.
• Ім'я поля: id, name, email — використовується у згенерованому коді.
• Числовий ідентифікатор (field number): = 1, = 2, = 3 — унікальний номер, що ідентифікує поле у бінарному форматі. Критично важливо: після публікації схеми ці номери не можна змінювати, оскільки це порушить сумісність зі старими клієнтами.

Рядки 19–24: Перелічення enum UserStatus

Визначає набір іменованих констант. Обов'язкова вимога proto3: перше значення enum повинно мати номер 0 та зазвичай називається *_UNSPECIFIED, що представляє невстановлене значення.

Рядки 27–39: Повідомлення запитів та відповідей

Для кожної операції RPC визначаються окремі типи запитів та відповідей. Це забезпечує можливість розширення API у майбутньому без порушення зворотної сумісності. Наприклад, якщо пізніше потрібно додати параметр фільтрації до GetUserRequest, можна додати нове поле без впливу на існуючих клієнтів.

Скалярні типи даних у Protocol Buffers

Protocol Buffers підтримує багатий набір скалярних типів даних, що відображаються на відповідні типи у різних мовах програмування. Розглянемо найпоширеніші типи та їх еквіваленти у Go.

Складні типи даних: вкладені повідомлення, списки та мапи

Protocol Buffers підтримує композицію складних структур даних через вкладені повідомлення, повторювані поля (repeated) та асоціативні масиви (map).

syntax = "proto3";

package ecommerce;

// Адреса доставки
message Address {
  string street = 1;
  string city = 2;
  string postal_code = 3;
  string country = 4;
}

// Товар у кошику
message CartItem {
  int64 product_id = 1;
  string product_name = 2;
  int32 quantity = 3;
  double unit_price = 4;
}

// Замовлення
message Order {
  int64 order_id = 1;
  int64 user_id = 2;
  
  // Вкладене повідомлення
  Address shipping_address = 3;
  
  // Список товарів (repeated field)
  repeated CartItem items = 4;
  
  // Мапа додаткових метаданих (ключ-значення)
  map<string, string> metadata = 5;
  
  // Часова мітка створення (Unix timestamp у секундах)
  int64 created_at = 6;
  
  // Загальна сума замовлення
  double total_amount = 7;
}

Repeated fields (повторювані поля):

Поле з модифікатором repeated представляє упорядкований список значень змінної довжини. У Go це відображається на зріз ([]CartItem). Порядок елементів зберігається при серіалізації.

Map fields (асоціативні масиви):

Синтаксис map<KeyType, ValueType> визначає асоціативний масив. Тип ключа може бути будь-яким скалярним типом крім float, double та bytes. Тип значення може бути будь-яким, включно з вкладеними повідомленнями. У Go відображається на map[string]string або відповідний тип.

Компіляція .proto файлів та генерація коду

Файли .proto є джерелом для генерації коду на різних мовах програмування. Для компіляції використовується утиліта protoc (Protocol Buffers Compiler) разом із мовно-специфічними плагінами.

// go.mod
module github.com/example/userservice

go 1.21

require (
    google.golang.org/grpc v1.60.0
    google.golang.org/protobuf v1.32.0
)

Встановлення необхідних інструментів для Go:

# Встановлення компілятора protoc
brew install protobuf

# Перевірка версії (має бути >= 3.15)
protoc --version

# Встановлення плагінів для Go
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# Додавання $GOPATH/bin до PATH (якщо ще не додано)
export PATH="$PATH:$(go env GOPATH)/bin"

# Встановлення protoc
sudo apt update
sudo apt install -y protobuf-compiler

# Встановлення Go плагінів
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# Встановлення плагінів через Go
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# Завантаження бінарного protoc з офіційного релізу
# https://github.com/protocolbuffers/protobuf/releases

Структура проєкту з gRPC:

userservice/
├── proto/
│   └── user.proto          # Опис контрактів
├── pb/                     # Згенерований код (gitignore)
│   ├── user.pb.go         # Protobuf структури
│   └── user_grpc.pb.go    # gRPC сервіси та клієнти
├── server/
│   └── main.go            # Реалізація gRPC-сервера
├── client/
│   └── main.go            # Клієнтський код
├── go.mod
└── Makefile               # Автоматизація компіляції

Команда компіляції .proto файлу:

protoc \
  --go_out=. \
  --go_opt=paths=source_relative \
  --go-grpc_out=. \
  --go-grpc_opt=paths=source_relative \
  proto/user.proto

Пояснення параметрів:

• --go_out=. — директорія для згенерованих Protobuf-структур (файли *.pb.go).
• --go_opt=paths=source_relative — генерувати файли відносно розташування .proto файлів (зберігає структуру каталогів).
• --go-grpc_out=. — директорія для згенерованих gRPC-інтерфейсів та клієнтів (файли *_grpc.pb.go).
• --go-grpc_opt=paths=source_relative — аналогічно до --go_opt.
• proto/user.proto — вхідний файл контракту.

Автоматизація через Makefile:

.PHONY: proto clean

proto:
    @echo "Generating Protocol Buffers code..."
    protoc \
        --go_out=. \
        --go_opt=paths=source_relative \
        --go-grpc_out=. \
        --go-grpc_opt=paths=source_relative \
        proto/*.proto
    @echo "Code generation completed."

clean:
    @echo "Cleaning generated files..."
    rm -f pb/*.pb.go

Після виконання команди make proto будуть згенеровані два файли:

1. pb/user.pb.go — містить структури Go для всіх повідомлень, enum-типів та методи серіалізації/десеріалізації.

2. pb/user_grpc.pb.go — містить інтерфейси серверних сервісів, клієнтські стаби та допоміжні функції для реєстрації обробників.

Транспортний рівень gRPC: HTTP/2 та його переваги

Фундаментальні обмеження HTTP/1.1

Щоб зрозуміти революційність HTTP/2 у контексті gRPC, необхідно чітко усвідомлювати фундаментальні обмеження HTTP/1.1, що роблять його неефективним для інтенсивної міжсервісної комунікації.

Проблема 1: Head-of-Line Blocking (блокування черги запитів).

HTTP/1.1 дозволяє лише один активний запит на одне TCP-з'єднання у будь-який момент часу. Навіть якщо використовується режим Connection: keep-alive, що дозволяє повторно використовувати з'єднання для кількох послідовних запитів, ці запити виконуються строго послідовно. Клієнт повинен чекати на завершення відповіді на перший запит перед надсиланням другого.

Якщо перший запит обробляється повільно (наприклад, виконання складного запиту до бази даних займає 500 мс), усі наступні запити чекають у черзі, навіть якщо вони могли б бути виконані миттєво. Для паралельного виконання кількох запитів клієнт повинен відкрити кілька TCP-з'єднань, що призводить до збільшення споживання пам'яті, дескрипторів файлів та повільного старту TCP (TCP Slow Start).

Проблема 2: Надмірні накладні витрати на заголовки.

Кожен HTTP/1.1 запит містить текстові заголовки, які повторюються практично без змін:

GET /api/v1/users/42 HTTP/1.1
Host: api.example.com
User-Agent: Go-http-client/1.1
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept-Encoding: gzip, deflate
Connection: keep-alive

Для короткого запиту (наприклад, перевірка статусу завдання) розмір заголовків може становити 400–800 байтів, тоді як корисне навантаження відповіді — лише 50 байтів. Ефективна пропускна здатність складає лише 5–10% від переданих даних.

Проблема 3: Відсутність пріоритизації запитів.

У HTTP/1.1 немає вбудованого механізму вказати серверу, які запити є критично важливими та повинні обробл

ятися першими. Усі запити обробляються у порядку надходження. Якщо клієнт надіслав запит на завантаження великого файлу (низький пріоритет) одразу після запиту на отримання даних користувача (високий пріоритет), обидва запити конкурують за ресурси без диференціації важливості.

HTTP/2: мультиплексування та бінарний протокол

Протокол HTTP/2 (RFC 7540, затверджений у 2015 році) був розроблений для вирішення всіх перелічених проблем HTTP/1.1. HTTP/2 є бінарним протоколом, що працює поверх одного TCP-з'єднання та забезпечує повне мультиплексування запитів без блокування.

Ключові інновації HTTP/2:

1. Мультиплексування потоків (Stream Multiplexing).

HTTP/2 розбиває кожен запит та відповідь на послідовність фреймів (frames), що передаються через логічні потоки (streams). Кожен потік має унікальний ідентифікатор, і фрейми різних потоків можуть передаватися паралельно через одне TCP-з'єднання.

Це означає, що клієнт може надіслати 100 запитів одночасно через одне з'єднання, і сервер може обробляти їх паралельно, надсилаючи відповіді по мірі готовності. Повільний запит не блокує швидкі запити — вони виконуються незалежно.

2. Бінарне кодування фреймів.

На відміну від текстових заголовків HTTP/1.1, HTTP/2 використовує компактне бінарне представлення метаданих. Кожен фрейм має фіксований заголовок довжиною 9 байтів:

+-----------------------------------------------+
|                 Length (24 біти)              |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31 біт)                  |
+=+=============================================================+
|                   Frame Payload (0...16384 байтів)           |
+---------------------------------------------------------------+

Типи фреймів включають DATA (корисне навантаження), HEADERS (заголовки), PRIORITY (пріоритет потоку), RST_STREAM (скасування потоку), SETTINGS (налаштування з'єднання), PING (перевірка живості), GOAWAY (плавне закриття з'єднання).

3. Стиснення заголовків HPACK.

HTTP/2 використовує алгоритм HPACK (RFC 7541) для стиснення заголовків із збереженням стану. HPACK будує динамічну таблицю повторюваних заголовків та передає лише індекси замість повних значень. Для типового REST API це зменшує розмір заголовків на 85–95%.

Приклад: перший запит надсилає повний заголовок Authorization: Bearer <token> (200 байтів). Наступні запити надсилають лише індекс 62, що посилається на попереднє значення (1 байт замість 200).

4. Пріоритизація потоків (Stream Prioritization).

HTTP/2 дозволяє клієнту вказати пріоритет кожного потоку через дерево залежностей (dependency tree) та вагові коефіцієнти (weight). Сервер може використовувати цю інформацію для оптимального розподілу пропускної здатності між потоками.

5. Server Push (серверна ініціатива).

Механізм, що дозволяє серверу надсилати ресурси клієнту до того, як клієнт їх запитав. Наприклад, при запиті HTML-сторінки сервер може одразу надіслати CSS та JavaScript файли. Ця функція рідко використовується у gRPC, але є доступною для спеціальних сценаріїв.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

rectangle "HTTP/1.1: Послідовна обробка" #FECACA {
  collections "Клієнт" as C1
  database "Сервер" as S1
  
  C1 -[#FF6B6B]> S1 : Request 1 (350 ms)
  S1 -[#FF6B6B]> C1 : Response 1
  
  C1 -[#FFA94D]> S1 : Request 2 (50 ms) - чекає!
  S1 -[#FFA94D]> C1 : Response 2
  
  C1 -[#4ECDC4]> S1 : Request 3 (100 ms) - чекає!
  S1 -[#4ECDC4]> C1 : Response 3
  
  note bottom of C1 #FEF3C7
    Загальний час: 350 + 50 + 100 = **500 мс**
    (послідовне виконання)
  end note
}

rectangle "HTTP/2: Мультиплексування" #DCFCE7 {
  collections "Клієнт" as C2
  database "Сервер" as S2
  
  C2 -[#FF6B6B]> S2 : Stream 1 (350 ms)
  C2 -[#FFA94D]> S2 : Stream 2 (50 ms)
  C2 -[#4ECDC4]> S2 : Stream 3 (100 ms)
  
  S2 -[#FFA94D]> C2 : Response Stream 2 (50 ms)
  S2 -[#4ECDC4]> C2 : Response Stream 3 (100 ms)
  S2 -[#FF6B6B]> C2 : Response Stream 1 (350 ms)
  
  note bottom of C2 #D4F4DD
    Загальний час: max(350, 50, 100) = **350 мс**
    (паралельне виконання через один TCP-з'єднання)
  end note
}

@enduml

Чому gRPC обрав HTTP/2

Вибір HTTP/2 як транспортного протоколу для gRPC не був випадковим. HTTP/2 надає всі необхідні примітиви для високопродуктивної RPC-комунікації:

Переваг 1: Ефективність мережевого обміну.

Мультиплексування дозволяє gRPC виконувати тисячі паралельних викликів через одне з'єднання без витрат на встановлення нових TCP-сокетів. Стиснення заголовків HPACK зменшує накладні витрати на метадані до 1–2% від загального трафіку.

Перевага 2: Нативна підтримка потокових операцій.

HTTP/2 потоки ідеально підходять для реалізації потокових RPC (streaming RPC), де клієнт або сервер надсилають послідовність повідомлень у рамках одного виклику. Це критично важливо для сценаріїв типу:

• Завантаження великих списків даних частинами.
• Потокова обробка файлів або відео.
• Двосторонній обмін повідомленнями у реальному часі (чати, телеметрія).

Перевага 3: Стандартизація та сумісність з інфраструктурою.

HTTP/2 є стандартом IETF (RFC 7540), що означає широку підтримку у проксі-серверах, балансувальниках навантаження (Nginx, HAProxy, Envoy), service mesh системах (Istio, Linkerd) та хмарних платформах. gRPC-трафік може проходити через існуючу HTTP-інфраструктуру без спеціальних налаштувань.

Перевага 4: Підтримка TLS та безпеки.

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

Визначення gRPC-сервісів у Protocol Buffers

Синтаксис опису RPC-методів

Після визначення структур даних (повідомлень) необхідно описати інтерфейс сервісу — набір методів, які клієнт може викликати віддалено. У Protocol Buffers це робиться за допомогою ключового слова service.

Розширимо попередній приклад user.proto, додавши повноцінний gRPC-сервіс управління користувачами:

syntax = "proto3";

package userservice;

option go_package = "github.com/example/userservice/pb";

// ... (повідомлення User, UserStatus, CreateUserRequest тощо)

// Сервіс управління користувачами
service UserService {
  // Unary RPC: створення нового користувача
  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
  
  // Unary RPC: отримання користувача за ідентифікатором
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
  
  // Unary RPC: оновлення даних користувача
  rpc UpdateUser(UpdateUserRequest) returns (UpdateUserResponse);
  
  // Unary RPC: видалення користувача
  rpc DeleteUser(DeleteUserRequest) returns (DeleteUserResponse);
  
  // Server Streaming RPC: отримання списку всіх користувачів потоком
  rpc ListUsers(ListUsersRequest) returns (stream User);
  
  // Client Streaming RPC: пакетне створення користувачів
  rpc BatchCreateUsers(stream CreateUserRequest) returns (BatchCreateUsersResponse);
  
  // Bidirectional Streaming RPC: двосторонній чат підтримки
  rpc SupportChat(stream ChatMessage) returns (stream ChatMessage);
}

// Додаткові повідомлення для нових методів

message UpdateUserRequest {
  int64 id = 1;
  string name = 2;
  string email = 3;
}

message UpdateUserResponse {
  User user = 1;
}

message DeleteUserRequest {
  int64 id = 1;
}

message DeleteUserResponse {
  bool success = 1;
}

message ListUsersRequest {
  int32 page_size = 1;
  string filter = 2;
}

message BatchCreateUsersResponse {
  int32 created_count = 1;
  repeated User users = 2;
}

message ChatMessage {
  int64 user_id = 1;
  string message = 2;
  int64 timestamp = 3;
}

Аналіз синтаксису service:

Рядки 10–30: Визначення сервісу UserService із семи RPC-методів. Кожен метод має:

• Ім'я методу: CreateUser, GetUser тощо.
• Тип запиту: CreateUserRequest, GetUserRequest.
• Тип відповіді: CreateUserResponse, GetUserResponse.
• Модифікатор stream: вказує на потокову передачу (може бути перед типом запиту, типом відповіді або обома).

Unary RPC (рядки 12–21): Найпростіший тип виклику «один запит — одна відповідь». Аналогічний до звичайного виклику функції.

Server Streaming RPC (рядок 24): Клієнт надсилає один запит, сервер відправляє потік повідомлень. Використовується для передачі великих списків даних, логів або прогресу виконання.

Client Streaming RPC (рядок 27): Клієнт надсилає потік повідомлень, сервер відправляє одну відповідь після завершення потоку. Використовується для завантаження файлів, пакетного імпорту даних.

Bidirectional Streaming RPC (рядок 30): Обидві сторони надсилають потоки повідомлень незалежно один від одного. Використовується для чатів, відеоконференцій, синхронізації даних у реальному часі.

Чотири типи RPC-викликів у gRPC

gRPC підтримує чотири фундаментальні патерни комунікації, кожен із яких оптимізований для специфічних сценаріїв використання.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam sequence {
  ArrowColor #1E293B
  ActorBorderColor #1E293B
  LifeLineBorderColor #CBD5E1
  LifeLineBackgroundColor #F8FAFC
  
  ParticipantBorderColor #1E293B
  ParticipantBackgroundColor #E2E8F0
}

title Типи gRPC RPC-викликів

== Unary RPC (Один запит → Одна відповідь) ==

participant "Client" as C1 #DBEAFE
participant "Server" as S1 #DCFCE7

C1 -> S1 : CreateUser(request)
activate S1
S1 --> C1 : CreateUserResponse
deactivate S1

note over C1, S1 #FEF3C7
  Аналогічно до звичайного HTTP POST запиту.
  Використання: CRUD операції, автентифікація.
end note

== Server Streaming RPC (Один запит → Потік відповідей) ==

participant "Client" as C2 #DBEAFE
participant "Server" as S2 #DCFCE7

C2 -> S2 : ListUsers(request)
activate S2
S2 --> C2 : User #1
S2 --> C2 : User #2
S2 --> C2 : User #3
S2 --> C2 : ... (stream continues)
S2 --> C2 : User #N
deactivate S2

note over C2, S2 #FEF3C7
  Сервер надсилає послідовність повідомлень.
  Використання: вибірка великих списків,
  логи реального часу, метрики.
end note

== Client Streaming RPC (Потік запитів → Одна відповідь) ==

participant "Client" as C3 #DBEAFE
participant "Server" as S3 #DCFCE7

activate S3
C3 -> S3 : CreateUserRequest #1
C3 -> S3 : CreateUserRequest #2
C3 -> S3 : CreateUserRequest #3
C3 -> S3 : ... (stream continues)
C3 -> S3 : CreateUserRequest #N
S3 --> C3 : BatchCreateUsersResponse
deactivate S3

note over C3, S3 #FEF3C7
  Клієнт надсилає потік даних,
  сервер обробляє та повертає результат.
  Використання: завантаження файлів,
  пакетний імпорт, агрегація метрик.
end note

== Bidirectional Streaming RPC (Потік ↔ Потік) ==

participant "Client" as C4 #DBEAFE
participant "Server" as S4 #DCFCE7

activate S4
activate C4
C4 -> S4 : ChatMessage #1
S4 --> C4 : ChatMessage (відповідь 1)
C4 -> S4 : ChatMessage #2
C4 -> S4 : ChatMessage #3
S4 --> C4 : ChatMessage (відповідь 2)
S4 --> C4 : ChatMessage (відповідь 3)
deactivate C4
deactivate S4

note over C4, S4 #FEF3C7
  Обидві сторони надсилають повідомлення
  незалежно та асинхронно.
  Використання: чати, відеоконференції,
  онлайн-ігри, синхронізація даних.
end note

@enduml

1. Unary RPC: класична модель «запит-відповідь»

Unary RPC є найпростішим типом виклику та аналогічний до звичайного REST API запиту. Клієнт надсилає один запит та чекає на одну відповідь. Цей патерн покриває 80–90% типових операцій у системах: створення, читання, оновлення, видалення записів (CRUD), автентифікація, валідація даних.

Приклад використання: Реєстрація нового користувача, отримання профілю, оновлення налаштувань, виконання бізнес-транзакції.

2. Server Streaming RPC: сервер надсилає потік даних

Клієнт надсилає один запит, після чого сервер починає надсилати послідовність повідомлень через відкритий потік. Клієнт читає повідомлення по одному до закриття потоку сервером. Цей патерн дозволяє ефективно передавати великі обсяги даних без завантаження всього набору у пам'ять.

Приклад використання:

• Вибірка мільйонів записів із бази даних частинами (уникнення Out-of-Memory помилок).
• Потокова передача логів системи у реальному часі.
• Передача фінансових котирувань або телеметрії IoT-пристроїв.
• Експорт звітів або резервних копій великих обсягів.

3. Client Streaming RPC: клієнт надсилає потік даних

Клієнт надсилає послідовність повідомлень серверу через відкритий потік. Сервер обробляє всі повідомлення та повертає одну відповідь після завершення потоку клієнтом. Цей патерн оптимізований для сценаріїв, де клієнт генерує дані динамічно або читає їх із великого джерела (файл, база даних).

Приклад використання:

• Завантаження великих файлів на сервер частинами (resumable upload).
• Пакетний імпорт тисяч записів у базу даних.
• Збір метрик або логів із клієнтського застосунку та агрегація на сервері.
• Відправка аудіо/відео фреймів для обробки (розпізнавання мови, аналіз відео).

4. Bidirectional Streaming RPC: повнодуплексний обмін даними

Обидві сторони (клієнт та сервер) відкривають потоки та надсилають повідомлення незалежно один від одного. Потоки є асинхронними — сервер може відповідати на повідомлення клієнта у довільному порядку або генерувати власні події без прив'язки до вхідних повідомлень.

Приклад використання:

• Чати та месенджери (двосторонній обмін текстовими повідомленнями).
• Відеоконференції (обмін аудіо/відео фреймами).
• Онлайн-ігри (синхронізація стану гри між клієнтом та сервером).
• Розподілені обчислення (клієнт надсилає завдання, сервер повертає результати по мірі готовності).

Реалізація gRPC-сервера у Go

Структура серверного застосунку

Після компіляції .proto файлів отримуємо згенерований інтерфейс сервісу, який потрібно реалізувати у Go-коді. Розглянемо повну реалізацію серверної частини для UserService.

Крок 1: Визначення структури сервера

// server/user_service.go
package main

import (
    "context"
    "errors"
    "log"
    "sync"
    
    pb "github.com/example/userservice/pb"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

// UserServer реалізує інтерфейс pb.UserServiceServer
type UserServer struct {
    pb.UnimplementedUserServiceServer  // Вбудовування для прямої сумісності
    
    mu    sync.RWMutex
    users map[int64]*pb.User  // In-memory сховище для демонстрації
    nextID int64
}

// NewUserServer створює новий екземпляр сервера
func NewUserServer() *UserServer {
    return &UserServer{
        users: make(map[int64]*pb.User),
        nextID: 1,
    }
}

Пояснення:

Рядок 17: Вбудовування pb.UnimplementedUserServiceServer є обов'язковою практикою у сучасних версіях gRPC. Ця структура містить заглушки (stubs) для всіх методів сервісу, що дозволяє компілювати код навіть якщо ви ще не реалізували всі методи. Без цього вбудовування компілятор видасть помилку «not all methods implemented».

Рядки 19–21: Використовуємо sync.RWMutex для потокобезпечного доступу до map, оскільки gRPC обробляє кожен виклик у окремій горутині. У продакшн-системі замість in-memory мапи використовується база даних (PostgreSQL, MongoDB).

Крок 2: Реалізація Unary RPC методу CreateUser

// CreateUser реалізує Unary RPC для створення користувача
func (s *UserServer) CreateUser(
    ctx context.Context,
    req *pb.CreateUserRequest,
) (*pb.CreateUserResponse, error) {
    // Валідація вхідних даних
    if req.GetName() == "" {
        return nil, status.Error(codes.InvalidArgument, "name is required")
    }
    if req.GetEmail() == "" {
        return nil, status.Error(codes.InvalidArgument, "email is required")
    }
    
    // Перевірка таймауту контексту
    select {
    case <-ctx.Done():
        return nil, status.Error(codes.DeadlineExceeded, "request timeout")
    default:
    }
    
    // Створення нового користувача
    s.mu.Lock()
    defer s.mu.Unlock()
    
    user := &pb.User{
        Id:        s.nextID,
        Name:      req.GetName(),
        Email:     req.GetEmail(),
        Status:    pb.UserStatus_USER_STATUS_ACTIVE,
        CreatedAt: 0, // У реальній системі: time.Now().Unix()
    }
    
    s.users[s.nextID] = user
    s.nextID++
    
    log.Printf("Created user: id=%d, name=%s", user.Id, user.Name)
    
    return &pb.CreateUserResponse{User: user}, nil
}

Ключові аспекти реалізації:

Рядки 7–12: Валідація вхідних параметрів є критичною для запобігання некоректному стану системи. gRPC використовує пакет google.golang.org/grpc/status для повернення стандартизованих помилок із кодами (аналогічно до HTTP статус-кодів).

Рядки 15–19: Перевірка контексту ctx.Done() дозволяє коректно обробляти ситуації, коли клієнт скасував запит або спливтаймаут. Якщо контекст закрито, подальша обробка марна — краще негайно повернути помилку.

Рядки 22–34: Захоплення м'ютексу для атомарної модифікації мапи. У реальній системі тут буде виклик userRepository.Create(ctx, user), що виконає INSERT запит до PostgreSQL.

Рядок 38: Повертаємо успішну відповідь. gRPC автоматично серіалізує структуру CreateUserResponse у бінарний формат Protobuf та відправляє клієнту через HTTP/2.

Крок 3: Реалізація Server Streaming RPC методу ListUsers

// ListUsers реалізує Server Streaming RPC для відправки списку користувачів
func (s *UserServer) ListUsers(
    req *pb.ListUsersRequest,
    stream pb.UserService_ListUsersServer,
) error {
    s.mu.RLock()
    defer s.mu.RUnlock()
    
    log.Printf("Streaming users list to client, total: %d", len(s.users))
    
    // Ітеруємось по всіх користувачах та надсилаємо по одному
    for id, user := range s.users {
        // Перевірка, чи клієнт не розірвав з'єднання
        if err := stream.Context().Err(); err != nil {
            log.Printf("Client disconnected: %v", err)
            return status.Error(codes.Canceled, "client disconnected")
        }
        
        // Надсилаємо користувача через потік
        if err := stream.Send(user); err != nil {
            log.Printf("Failed to send user id=%d: %v", id, err)
            return status.Errorf(codes.Internal, "stream error: %v", err)
        }
        
        log.Printf("Sent user: id=%d, name=%s", user.Id, user.Name)
    }
    
    log.Println("Completed streaming users list")
    return nil  // Повернення nil закриває потік успішно
}

Відмінності від Unary RPC:

Рядок 4: Замість повернення відповіді через return, метод отримує об'єкт stream, що реалізує інтерфейс pb.UserService_ListUsersServer. Цей інтерфейс має метод Send(*pb.User) для відправки кожного повідомлення.

Рядки 14–17: Критично важливо перевіряти stream.Context().Err() перед кожним надсиланням. Якщо клієнт закрив з'єднання або спливтаймаут, подальші виклики Send() завершаться помилкою.

Рядки 20–23: Метод stream.Send(user) серіалізує повідомлення та надсилає його клієнту через HTTP/2 DATA фрейм. Клієнт може починати обробку повідомлення ще до завершення ітерації на сервері.

Рядок 29: Повернення nil сигналізує успішне завершення потоку. gRPC автоматично відправляє клієнту HTTP/2 END_STREAM фрейм.

Крок 4: Запуск gRPC-сервера

// server/main.go
package main

import (
    "log"
    "net"
    
    pb "github.com/example/userservice/pb"
    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
)

func main() {
    // Створюємо TCP-слухач на порту 50051
    listener, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("Failed to listen: %v", err)
    }
    
    // Створюємо gRPC-сервер
    grpcServer := grpc.NewServer(
        grpc.MaxRecvMsgSize(10 * 1024 * 1024),  // Максимальний розмір вхідного повідомлення: 10 МБ
        grpc.MaxSendMsgSize(10 * 1024 * 1024),  // Максимальний розмір вихідного повідомлення: 10 МБ
    )
    
    // Реєструємо наш сервіс
    userService := NewUserServer()
    pb.RegisterUserServiceServer(grpcServer, userService)
    
    // Увімкнення gRPC Reflection для інструментів типу grpcurl
    reflection.Register(grpcServer)
    
    log.Println("gRPC server listening on :50051")
    
    // Блокуючий виклик: приймаємо з'єднання
    if err := grpcServer.Serve(listener); err != nil {
        log.Fatalf("Failed to serve: %v", err)
    }
}

Пояснення:

Рядки 21–24: Створення gRPC-сервера із налаштуваннями максимального розміру повідомлень. За замовчуванням ліміт складає 4 МБ, що може бути недостатньо для файлів або великих списків.

Рядок 28: Функція pb.RegisterUserServiceServer згенерована компілятором protoc та реєструє наш UserServer як обробник для всіх RPC-методів UserService.

Рядок 31: gRPC Reflection — це стандартний механізм, що дозволяє клієнтським інструментам (наприклад, grpcurl, Postman, BloomRPC) автоматично виявляти доступні сервіси та методи без доступу до .proto файлів. Обов'язково вмикайте у development-середовищі.

Рядок 36: Метод Serve() є блокуючим та приймає вхідні з'єднання у нескінченному циклі, делегуючи кожне з'єднання окремій горутині.

Реалізація gRPC-клієнта у Go

Базова клієнтська комунікація

Згенерований код містить клієнтський stub (заглушку), що інкапсулює всю логіку серіалізації, мережевої комунікації та десеріалізації. Розробнику достатньо викликати методи stub-об'єкта як звичайні локальні функції.

// client/main.go
package main

import (
    "context"
    "io"
    "log"
    "time"
    
    pb "github.com/example/userservice/pb"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
)

func main() {
    // Встановлення з'єднання з gRPC-сервером
    conn, err := grpc.Dial(
        "localhost:50051",
        grpc.WithTransportCredentials(insecure.NewCredentials()),  // Без TLS (тільки для розробки!)
        grpc.WithBlock(),  // Блокувати до успішного з'єднання
    )
    if err != nil {
        log.Fatalf("Failed to connect: %v", err)
    }
    defer conn.Close()
    
    // Створення клієнтського stub
    client := pb.NewUserServiceClient(conn)
    
    // Виконуємо виклики RPC-методів
    demoUnaryRPC(client)
    demoServerStreamingRPC(client)
}

// Демонстрація Unary RPC виклику
func demoUnaryRPC(client pb.UserServiceClient) {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    
    log.Println("=== Unary RPC: CreateUser ===")
    
    resp, err := client.CreateUser(ctx, &pb.CreateUserRequest{
        Name:  "Alice Johnson",
        Email: "alice@example.com",
    })
    if err != nil {
        log.Fatalf("CreateUser failed: %v", err)
    }
    
    log.Printf("Created user: id=%d, name=%s, email=%s\n",
        resp.User.GetId(),
        resp.User.GetName(),
        resp.User.GetEmail())
}

// Демонстрація Server Streaming RPC виклику
func demoServerStreamingRPC(client pb.UserServiceClient) {
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    
    log.Println("\n=== Server Streaming RPC: ListUsers ===")
    
    stream, err := client.ListUsers(ctx, &pb.ListUsersRequest{
        PageSize: 100,
        Filter:   "",
    })
    if err != nil {
        log.Fatalf("ListUsers failed: %v", err)
    }
    
    // Читаємо повідомлення з потоку до закриття
    for {
        user, err := stream.Recv()
        if err == io.EOF {
            // Сервер закрив потік — це нормальне завершення
            log.Println("Stream closed by server")
            break
        }
        if err != nil {
            log.Fatalf("Failed to receive: %v", err)
        }
        
        log.Printf("Received user: id=%d, name=%s", user.GetId(), user.GetName())
    }
}

Аналіз клієнтського коду:

Рядки 17–20: Метод grpc.Dial() встановлює з'єднання з сервером. Опція grpc.WithTransportCredentials(insecure.NewCredentials()) вимикає TLS — це безпечно лише для локальної розробки. У продакшн-середовищі обов'язково використовуйте TLS-сертифікати.

Рядок 19: grpc.WithBlock() робить Dial() блокуючим до успішного встановлення з'єднання. Без цієї опції Dial() повертається негайно, а з'єднання встановлюється асинхронно у фоні. Це корисно для швидкого старту, але ускладнює обробку помилок конфігурації.

Рядок 28: Функція pb.NewUserServiceClient(conn) створює клієнтський stub, що реалізує інтерфейс pb.UserServiceClient зі всіма методами сервісу.

Рядки 37–38: Завжди створюйте контекст із таймаутом для gRPC-викликів. Без таймауту клієнт може чекати нескінченно, якщо сервер завис або мережа нестабільна. Типові таймаути: 1–5 секунд для простих запитів, 30–60 секунд для складних обчислень.

Рядки 42–45: Виклик client.CreateUser() виглядає як звичайний виклик локальної функції. gRPC автоматично:

1. Серіалізує CreateUserRequest у Protobuf.
2. Надсилає HTTP/2 HEADERS та DATA фрейми через з'єднання.
3. Чекає на відповідь від сервера.
4. Десеріалізує відповідь у структуру CreateUserResponse.

Рядки 64–68: Виклик Server Streaming RPC методу повертає не результат, а об'єкт потоку (stream), що реалізує інтерфейс pb.UserService_ListUsersClient.

Рядки 71–82: Читаємо повідомлення з потоку у циклі через метод stream.Recv(). Коли сервер закриває потік, Recv() повертає помилку io.EOF, що є сигналом нормального завершення (а не справжньої помилки).

Обробка помилок та статус-коди gRPC

gRPC використовує власну систему статус-кодів, визначених у пакеті google.golang.org/grpc/codes. Ці коди аналогічні до HTTP статус-кодів, але оптимізовані для RPC-комунікації.

Таблиця основних gRPC статус-кодів:

Приклад обробки статус-кодів на клієнті:

import (
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

func createUserWithErrorHandling(client pb.UserServiceClient, name, email string) {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    
    resp, err := client.CreateUser(ctx, &pb.CreateUserRequest{
        Name:  name,
        Email: email,
    })
    
    if err != nil {
        // Перетворюємо помилку на gRPC статус
        st, ok := status.FromError(err)
        if !ok {
            // Не gRPC помилка (наприклад, мережева помилка)
            log.Fatalf("Non-gRPC error: %v", err)
        }
        
        // Обробляємо різні типи помилок
        switch st.Code() {
        case codes.InvalidArgument:
            log.Printf("Validation error: %s", st.Message())
        case codes.AlreadyExists:
            log.Printf("User already exists: %s", st.Message())
        case codes.DeadlineExceeded:
            log.Println("Request timeout, retry later")
        case codes.Unavailable:
            log.Println("Service unavailable, retry with backoff")
        default:
            log.Printf("RPC failed: code=%s, message=%s", st.Code(), st.Message())
        }
        return
    }
    
    log.Printf("Success: user created with id=%d", resp.User.GetId())
}

gRPC Інтерцептори: middleware для RPC-викликів

Концепція інтерцепторів

Інтерцептори (interceptors) у gRPC аналогічні до middleware у вебфреймворках (Gin, Chi) — це функції, що перехоплюють RPC-виклики до їх виконання (Unary) або під час обробки потоку (Streaming). Інтерцептори дозволяють додавати наскрізну функціональність без модифікації бізнес-логіки кожного методу:

• Автентифікація та авторизація (перевірка JWT токенів).
• Логування запитів та відповідей.
• Збір метрик (тривалість виклику, кількість помилок).
• Трейсинг (розподілене відстеження запитів через мікросервіси).
• Rate Limiting (обмеження частоти запитів).
• Валідація вхідних даних.

gRPC розрізняє два типи інтерцепторів:

1. Unary Interceptor — обробляє Unary RPC виклики (один запит → одна відповідь).
2. Stream Interceptor — обробляє Streaming RPC виклики (потокові операції).

Реалізація Unary Interceptor для логування

Unary Interceptor має сигнатуру функції, що обгортає виклик RPC-методу:

// server/interceptors/logging.go
package interceptors

import (
    "context"
    "log"
    "time"
    
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

// UnaryLoggingInterceptor логує всі Unary RPC виклики
func UnaryLoggingInterceptor(
    ctx context.Context,
    req interface{},
    info *grpc.UnaryServerInfo,
    handler grpc.UnaryHandler,
) (interface{}, error) {
    start := time.Now()
    
    log.Printf("[gRPC] → Method: %s", info.FullMethod)
    
    // Викликаємо оригінальний обробник
    resp, err := handler(ctx, req)
    
    // Логуємо результат
    duration := time.Since(start)
    
    if err != nil {
        st, _ := status.FromError(err)
        log.Printf("[gRPC] ← Method: %s, Status: %s, Duration: %v, Error: %s",
            info.FullMethod,
            st.Code(),
            duration,
            st.Message())
    } else {
        log.Printf("[gRPC] ← Method: %s, Status: OK, Duration: %v",
            info.FullMethod,
            duration)
    }
    
    return resp, err
}

Пояснення:

Параметр ctx context.Context: Контекст запиту, що містить метадані, таймаути та сигнали скасування.

Параметр req interface{}: Десеріалізований запит (наприклад, *pb.CreateUserRequest). Використовується тип interface{}, оскільки інтерцептор є універсальним для всіх методів.

Параметр info *grpc.UnaryServerInfo: Містить метаінформацію про виклик: FullMethod (повна назва методу, наприклад /userservice.UserService/CreateUser), Server (покажчик на gRPC-сервер).

Параметр handler grpc.UnaryHandler: Функція, що викликає оригінальний обробник RPC-методу. Виклик handler(ctx, req) передає керування бізнес-логіці (CreateUser, GetUser тощо).

Рядок 26: Викликаємо оригінальний обробник та зберігаємо результат та помилку. Це дозволяє вимірювати час виконання методу.

Рядки 31–41: Логуємо результат виклику: успішний (статус OK) або з помилкою (статус-код та повідомлення).

Реалізація Unary Interceptor для автентифікації JWT

Інтерцептор автентифікації перевіряє наявність та валідність JWT токена у метаданих запиту перед викликом бізнес-логіки.

// server/interceptors/auth.go
package interceptors

import (
    "context"
    "strings"
    
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/metadata"
    "google.golang.org/grpc/status"
)

// UnaryAuthInterceptor перевіряє JWT токен у метаданих
func UnaryAuthInterceptor(
    ctx context.Context,
    req interface{},
    info *grpc.UnaryServerInfo,
    handler grpc.UnaryHandler,
) (interface{}, error) {
    // Список публічних методів, що не вимагають автентифікації
    publicMethods := map[string]bool{
        "/userservice.UserService/CreateUser": true,  // Реєстрація публічна
    }
    
    // Якщо метод публічний, пропускаємо перевірку
    if publicMethods[info.FullMethod] {
        return handler(ctx, req)
    }
    
    // Отримуємо метадані з контексту
    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return nil, status.Error(codes.Unauthenticated, "missing metadata")
    }
    
    // Шукаємо заголовок Authorization
    authHeaders := md.Get("authorization")
    if len(authHeaders) == 0 {
        return nil, status.Error(codes.Unauthenticated, "missing authorization header")
    }
    
    // Формат: "Bearer <token>"
    token := strings.TrimPrefix(authHeaders[0], "Bearer ")
    if token == authHeaders[0] {
        return nil, status.Error(codes.Unauthenticated, "invalid authorization format")
    }
    
    // Валідація JWT токена (спрощена версія)
    userID, err := validateJWT(token)
    if err != nil {
        return nil, status.Error(codes.Unauthenticated, "invalid token")
    }
    
    // Додаємо userID до контексту для використання у обробниках
    ctx = context.WithValue(ctx, "user_id", userID)
    
    // Викликаємо оригінальний обробник із збагаченим контекстом
    return handler(ctx, req)
}

// validateJWT перевіряє JWT токен та повертає user ID (заглушка)
func validateJWT(token string) (int64, error) {
    // У реальній системі тут має бути перевірка підпису JWT,
    // терміну дії та витягування claims
    if token == "valid_token_123" {
        return 42, nil
    }
    return 0, status.Error(codes.Unauthenticated, "invalid token")
}

Ключові моменти:

Рядки 22–29: Визначаємо список публічних методів, що доступні без автентифікації (реєстрація, вхід). Для захищених методів (GetUser, UpdateUser, DeleteUser) виконується перевірка токена.

Рядки 32–35: Метадані gRPC передаються через контекст у вигляді map string → []string. Функція metadata.FromIncomingContext() витягує метадані із запиту.

Рядки 38–48: Шукаємо заголовок authorization та перевіряємо, що він має формат Bearer <token>. Це стандартний формат для передачі токенів (RFC 6750).

Рядки 51–54: Викликаємо функцію валідації JWT (у реальній системі використовується бібліотека github.com/golang-jwt/jwt), що перевіряє підпис, термін дії та витягує user_id із токена.

Рядок 57: Додаємо user_id до контексту, що дозволяє обробникам RPC-методів отримати ідентифікатор автентифікованого користувача без повторної перевірки токена.

go get -u github.com/golang-jwt/jwt/v5

import (
    "time"
    "github.com/golang-jwt/jwt/v5"
)

type Claims struct {
    UserID int64 `json:"user_id"`
    jwt.RegisteredClaims
}

func generateJWT(userID int64, secret []byte) (string, error) {
    claims := Claims{
        UserID: userID,
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(24 * time.Hour)),
            IssuedAt:  jwt.NewNumericDate(time.Now()),
            Issuer:    "userservice",
        },
    }
    
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    return token.SignedString(secret)
}

func validateJWT(tokenString string, secret []byte) (*Claims, error) {
    token, err := jwt.ParseWithClaims(
        tokenString,
        &Claims{},
        func(token *jwt.Token) (interface{}, error) {
            // Перевірка алгоритму підпису
            if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
                return nil, fmt.Errorf("unexpected signing method")
            }
            return secret, nil
        },
    )
    
    if err != nil {
        return nil, err
    }
    
    if claims, ok := token.Claims.(*Claims); ok && token.Valid {
        return claims, nil
    }
    
    return nil, fmt.Errorf("invalid token")
}

func UnaryAuthInterceptor(secret []byte) grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        // ... отримання токена з метаданих
        
        claims, err := validateJWT(token, secret)
        if err != nil {
            return nil, status.Error(codes.Unauthenticated, "invalid token")
        }
        
        ctx = context.WithValue(ctx, "user_id", claims.UserID)
        return handler(ctx, req)
    }
}

import (
    "crypto/tls"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func main() {
    // Завантажуємо сертифікат та ключ
    cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
    if err != nil {
        log.Fatal(err)
    }
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        MinVersion:   tls.VersionTLS13,  // Вимагаємо TLS 1.3
    }
    
    creds := credentials.NewTLS(tlsConfig)
    server := grpc.NewServer(grpc.Creds(creds))
    // ... реєстрація сервісів
}

func main() {
    // Завантажуємо CA сертифікат для перевірки сервера
    caCert, err := os.ReadFile("ca.crt")
    if err != nil {
        log.Fatal(err)
    }
    
    certPool := x509.NewCertPool()
    certPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        RootCAs:    certPool,
        MinVersion: tls.VersionTLS13,
    }
    
    creds := credentials.NewTLS(tlsConfig)
    
    conn, err := grpc.Dial(
        "localhost:50051",
        grpc.WithTransportCredentials(creds),
    )
    // ... використання клієнта
}

tlsConfig := &tls.Config{
    Certificates: []tls.Certificate{serverCert},
    ClientAuth:   tls.RequireAndVerifyClientCert,
    ClientCAs:    clientCAPool,
    MinVersion:   tls.VersionTLS13,
}

Реєстрація інтерцепторів на сервері

Інтерцептори реєструються під час створення gRPC-сервера через опції grpc.ServerOption:

// server/main.go
package main

import (
    "log"
    "net"
    
    pb "github.com/example/userservice/pb"
    "github.com/example/userservice/server/interceptors"
    "google.golang.org/grpc"
)

func main() {
    listener, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("Failed to listen: %v", err)
    }
    
    // Створюємо gRPC-сервер із ланцюжком інтерцепторів
    grpcServer := grpc.NewServer(
        grpc.ChainUnaryInterceptor(
            interceptors.UnaryLoggingInterceptor,   // Першим логування
            interceptors.UnaryAuthInterceptor,      // Потім автентифікація
        ),
        // Для Stream інтерцепторів використовується ChainStreamInterceptor
    )
    
    // Реєстрація сервісу
    userService := NewUserServer()
    pb.RegisterUserServiceServer(grpcServer, userService)
    
    log.Println("gRPC server with interceptors listening on :50051")
    
    if err := grpcServer.Serve(listener); err != nil {
        log.Fatalf("Failed to serve: %v", err)
    }
}

Рядки 21–24: Функція grpc.ChainUnaryInterceptor() дозволяє зареєструвати кілька інтерцепторів у вигляді ланцюжка. Порядок виклику: зверху вниз на вході та знизу вгору на виході. У нашому випадку:

1. Запит потрапляє у UnaryLoggingInterceptor → логуємо початок.
2. Передаємо у UnaryAuthInterceptor → перевіряємо токен.
3. Якщо автентифікація успішна, викликаємо handler (бізнес-логіка).
4. Відповідь повертається через UnaryAuthInterceptor (нічого не робить).
5. Відповідь повертається через UnaryLoggingInterceptor → логуємо результат.

import (
    grpc_middleware "github.com/grpc-ecosystem/go-grpc-middleware/v2"
    grpc_recovery "github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery"
    grpc_logging "github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/logging"
)

server := grpc.NewServer(
    grpc.ChainUnaryInterceptor(
        grpc_recovery.UnaryServerInterceptor(),
        grpc_logging.UnaryServerInterceptor(logger),
    ),
)

# macOS
brew install grpcurl

# Go Install
go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest

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

# Виклик методу
grpcurl -plaintext \
  -d '{"name": "Alice"}' \
  localhost:50051 \
  userservice.UserService/CreateUser

import "google.golang.org/grpc/test/bufconn"

const bufSize = 1024 * 1024

var lis *bufconn.Listener

func init() {
    lis = bufconn.Listen(bufSize)
    s := grpc.NewServer()
    pb.RegisterUserServiceServer(s, &server{})
    go s.Serve(lis)
}

func bufDialer(context.Context, string) (net.Conn, error) {
    return lis.Dial()
}

// У тестах
conn, _ := grpc.DialContext(
    ctx,
    "bufnet",
    grpc.WithContextDialer(bufDialer),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

Тестування та налагодження gRPC-сервісів

Модульне тестування RPC-методів

Оскільки RPC-обробники є звичайними Go-функціями, їх можна тестувати без запуску повноцінного gRPC-сервера, використовуючи мок-об'єкти.

// server/user_service_test.go
package main

import (
    "context"
    "testing"
    
    pb "github.com/example/userservice/pb"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

func TestCreateUser_Success(t *testing.T) {
    server := NewUserServer()
    
    req := &pb.CreateUserRequest{
        Name:  "Alice",
        Email: "alice@test.com",
    }
    
    resp, err := server.CreateUser(context.Background(), req)
    
    if err != nil {
        t.Fatalf("Expected no error, got %v", err)
    }
    
    if resp.User.GetName() != "Alice" {
        t.Errorf("Expected name 'Alice', got '%s'", resp.User.GetName())
    }
    
    if resp.User.GetId() == 0 {
        t.Error("Expected non-zero user ID")
    }
}

func TestCreateUser_InvalidArgument(t *testing.T) {
    server := NewUserServer()
    
    // Запит без обов'язкового поля name
    req := &pb.CreateUserRequest{
        Email: "test@example.com",
    }
    
    _, err := server.CreateUser(context.Background(), req)
    
    if err == nil {
        t.Fatal("Expected error for empty name, got nil")
    }
    
    st, ok := status.FromError(err)
    if !ok {
        t.Fatal("Expected gRPC status error")
    }
    
    if st.Code() != codes.InvalidArgument {
        t.Errorf("Expected InvalidArgument code, got %s", st.Code())
    }
}

Інтеграційне тестування через реальний gRPC-сервер

Для тестування повного циклу запит-відповідь, включно з інтерцепторами та серіалізацією, необхідно запустити тестовий gRPC-сервер.

// server/integration_test.go
package main

import (
    "context"
    "net"
    "testing"
    "time"
    
    pb "github.com/example/userservice/pb"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
    "google.golang.org/grpc/test/bufconn"
)

const bufSize = 1024 * 1024

var lis *bufconn.Listener

func init() {
    // Створюємо in-memory listener для тестування
    lis = bufconn.Listen(bufSize)
    
    s := grpc.NewServer()
    pb.RegisterUserServiceServer(s, NewUserServer())
    
    go func() {
        if err := s.Serve(lis); err != nil {
            panic(err)
        }
    }()
}

func bufDialer(context.Context, string) (net.Conn, error) {
    return lis.Dial()
}

func TestIntegration_CreateAndGetUser(t *testing.T) {
    ctx := context.Background()
    
    // Підключаємось до тестового сервера
    conn, err := grpc.DialContext(
        ctx,
        "bufnet",
        grpc.WithContextDialer(bufDialer),
        grpc.WithTransportCredentials(insecure.NewCredentials()),
    )
    if err != nil {
        t.Fatalf("Failed to dial bufnet: %v", err)
    }
    defer conn.Close()
    
    client := pb.NewUserServiceClient(conn)
    
    // Створюємо користувача
    createResp, err := client.CreateUser(ctx, &pb.CreateUserRequest{
        Name:  "Bob",
        Email: "bob@test.com",
    })
    if err != nil {
        t.Fatalf("CreateUser failed: %v", err)
    }
    
    userID := createResp.User.GetId()
    
    // Отримуємо створеного користувача
    getResp, err := client.GetUser(ctx, &pb.GetUserRequest{
        Id: userID,
    })
    if err != nil {
        t.Fatalf("GetUser failed: %v", err)
    }
    
    if getResp.User.GetName() != "Bob" {
        t.Errorf("Expected name 'Bob', got '%s'", getResp.User.GetName())
    }
}

Рядки 19–31: Використовуємо bufconn.Listener — спеціальний in-memory listener, що дозволяє тестувати gRPC без відкриття реальних TCP-портів. Це робить тести швидшими та ізольованими.

Налагодження через grpcurl

grpcurl — це інструмент командного рядка для ручного тестування gRPC-сервісів (аналог curl для HTTP). Працює через gRPC Reflection API.

brew install grpcurl

go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest

Приклади використання:

# Список доступних сервісів
grpcurl -plaintext localhost:50051 list

# Список методів конкретного сервісу
grpcurl -plaintext localhost:50051 list userservice.UserService

# Опис методу (типи запиту та відповіді)
grpcurl -plaintext localhost:50051 describe userservice.UserService.CreateUser

# Виклик Unary RPC методу
grpcurl -plaintext \
  -d '{"name": "Charlie", "email": "charlie@example.com"}' \
  localhost:50051 \
  userservice.UserService/CreateUser

# Виклик із метаданими (JWT токен)
grpcurl -plaintext \
  -H "Authorization: Bearer valid_token_123" \
  -d '{"id": 1}' \
  localhost:50051 \
  userservice.UserService/GetUser

Опція -plaintext: Вимикає TLS (для локальної розробки). У продакшні використовуйте -insecure або надайте TLS-сертифікати через -cert та -key.

Додаткові інструменти для роботи з gRPC

# macOS
brew install bufbuild/buf/buf

# Go Install
go install github.com/bufbuild/buf/cmd/buf@latest

version: v1
breaking:
  use:
    - FILE
lint:
  use:
    - DEFAULT

# macOS
brew install evans

# Go Install
go install github.com/ktr0731/evans@latest

# Інтерактивний режим
evans --host localhost --port 50051 -r repl

# CLI режим
evans --host localhost --port 50051 cli call userservice.UserService.CreateUser

Порівняння REST vs gRPC: коли використовувати кожен підхід

Порівняльна таблиця характеристик

Рекомендації щодо вибору технології

Використовуйте REST, якщо:

1. Публічне API для сторонніх інтеграторів. REST є універсальним стандартом, що підтримується всіма мовами програмування та інструментами. Документація OpenAPI/Swagger дозволяє розробникам легко зрозуміти API.
2. Клієнти — вебдодатки у браузері. Fetch API та XMLHttpRequest нативно підтримують HTTP/JSON. gRPC вимагає використання grpc-web із проксі-сервером (Envoy).
3. Простота налагодження та читабельність. JSON-відповіді можна переглядати у браузері, логах, інструментах моніторингу без спеціальних декодерів.
4. Швидкість розробки критична. REST дозволяє швидко створювати прототипи без налаштування компіляції .proto та кодогенерації.
5. Сумісність зі старою інфраструктурою. Багато корпоративних проксі-серверів, брандмауерів та CDN оптимізовані для HTTP/1.1 та можуть некоректно обробляти HTTP/2 або блокувати бінарні протоколи.

Використовуйте gRPC, якщо:

1. Міжсервісна комунікація у мікросервісній архітектурі. gRPC забезпечує високу продуктивність, строгі контракти та автоматичну кодогенерацію для polyglot систем (Go ↔ Java ↔ Python ↔ C#).
2. Критична продуктивність та низька затримка. Бінарна серіалізація Protobuf у 3–10 разів швидша за JSON. HTTP/2 мультиплексування зменшує накладні витрати на встановлення з'єднань.
3. Потокова передача даних. gRPC нативно підтримує Server Streaming, Client Streaming та Bidirectional Streaming без необхідності використання окремих протоколів (SSE, WebSocket).
4. Строга типізація та версіювання. Protocol Buffers забезпечують прямую та зворотну сумісність (forward/backward compatibility) через field numbers. Зміни схеми автоматично перевіряються на етапі компіляції.
5. Полімовна кодогенерація. Якщо у вас є клієнти на різних мовах (мобільний додаток на Kotlin, десктоп на C#, бекенд на Go), gRPC автоматично генерує типобезпечні клієнтські бібліотеки для всіх платформ.

Розширені теми gRPC

Балансування навантаження та Service Discovery

У продакшн-середовищі gRPC-сервіси зазвичай розгортаються у кількох екземплярах для забезпечення високої доступності та масштабованості. Клієнти повинні розподіляти запити між екземплярами через балансування навантаження (load balancing).

Два підходи до балансування навантаження у gRPC:

1. Проксі-балансування (Proxy Load Balancing).

Клієнт підключається до централізованого балансувальника навантаження (Nginx, HAProxy, Envoy), який розподіляє з'єднання між бекенд-серверами. Це найпростіший підхід, але додає додатковий мережевий перехід (network hop) та точку відмови.

Client → [Load Balancer] → {gRPC Server 1, gRPC Server 2, gRPC Server 3}

2. Клієнтське балансування (Client-side Load Balancing).

gRPC-клієнт безпосередньо знає про всі доступні сервери та самостійно розподіляє запити між ними. Це вимагає інтеграції з системою Service Discovery (Consul, etcd, Kubernetes DNS).

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/balancer/roundrobin"
    "google.golang.org/grpc/resolver"
)

func main() {
    // Підключення із клієнтським балансуванням round-robin
    conn, err := grpc.Dial(
        "dns:///userservice.default.svc.cluster.local:50051",
        grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),
        grpc.WithTransportCredentials(insecure.NewCredentials()),
    )
    
    // gRPC автоматично виявляє всі IP-адреси за DNS-записом
    // та розподіляє запити між ними
}

Deadline propagation та таймаути

У розподілених системах критично важливо встановлювати таймаути для кожного запиту, щоб запобігти витоку ресурсів у випадку зависання downstream-сервісів. gRPC підтримує розповсюдження deadline (deadline propagation) — автоматичну передачу залишкового часу запиту через ланцюжок викликів.

func main() {
    conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure())
    client := pb.NewUserServiceClient(conn)
    
    // Встановлюємо deadline 5 секунд від поточного моменту
    ctx, cancel := context.WithDeadline(
        context.Background(),
        time.Now().Add(5*time.Second),
    )
    defer cancel()
    
    // Якщо UserService викликає інший gRPC-сервіс (OrderService),
    // він автоматично передає залишковий час (наприклад, 4.5 с)
    resp, err := client.CreateUser(ctx, &pb.CreateUserRequest{...})
    
    if err != nil {
        st, _ := status.FromError(err)
        if st.Code() == codes.DeadlineExceeded {
            log.Println("Request timed out")
        }
    }
}

Best practices для таймаутів:

• Встановлюйте розумні таймаути на основі SLA системи (зазвичай 1–10 секунд для синхронних операцій).
• Використовуйте context.WithTimeout() замість context.WithDeadline() для відносних таймаутів.
• Логуйте всі помилки DeadlineExceeded та аналізуйте їх для оптимізації продуктивності.

Mutual TLS (mTLS) для міжсервісної автентифікації

У нульових довіри (zero trust) архітектурах кожен сервіс повинен автентифікувати себе перед іншими сервісами через взаємну TLS (mutual TLS, mTLS). Це означає, що як клієнт, так і сервер надають сертифікати для перевірки ідентичності.

Налаштування mTLS на gRPC-сервері:

import (
    "crypto/tls"
    "crypto/x509"
    "os"
    
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func main() {
    // Завантажуємо сертифікат та ключ сервера
    serverCert, err := tls.LoadX509KeyPair("certs/server.crt", "certs/server.key")
    if err != nil {
        log.Fatalf("Failed to load server cert: %v", err)
    }
    
    // Завантажуємо CA сертифікат для перевірки клієнтів
    caCert, err := os.ReadFile("certs/ca.crt")
    if err != nil {
        log.Fatalf("Failed to load CA cert: %v", err)
    }
    
    certPool := x509.NewCertPool()
    certPool.AppendCertsFromPEM(caCert)
    
    // Налаштовуємо TLS із вимогою верифікації клієнтського сертифіката
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{serverCert},
        ClientAuth:   tls.RequireAndVerifyClientCert,  // Вимагаємо mTLS
        ClientCAs:    certPool,
    }
    
    creds := credentials.NewTLS(tlsConfig)
    
    grpcServer := grpc.NewServer(grpc.Creds(creds))
    // ... реєстрація сервісів
}

Налаштування mTLS на gRPC-клієнті:

func main() {
    // Завантажуємо клієнтський сертифікат та ключ
    clientCert, err := tls.LoadX509KeyPair("certs/client.crt", "certs/client.key")
    if err != nil {
        log.Fatalf("Failed to load client cert: %v", err)
    }
    
    // Завантажуємо CA для перевірки серверного сертифіката
    caCert, err := os.ReadFile("certs/ca.crt")
    if err != nil {
        log.Fatalf("Failed to load CA cert: %v", err)
    }
    
    certPool := x509.NewCertPool()
    certPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{clientCert},
        RootCAs:      certPool,
    }
    
    creds := credentials.NewTLS(tlsConfig)
    
    conn, err := grpc.Dial(
        "localhost:50051",
        grpc.WithTransportCredentials(creds),
    )
    // ... використання клієнта
}

Service Mesh: автоматизація мережевої інфраструктури для мікросервісів

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 50051 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route:
                  cluster: grpc_cluster
                  timeout: 5s
          http_filters:
          - name: envoy.filters.http.router

  clusters:
  - name: grpc_cluster
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    load_assignment:
      cluster_name: grpc_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: userservice, port_value: 50051 }

Linkerd

• Сайт: linkerd.io
• Легкий та швидкий service mesh
• Написаний на Rust (високапродуктивний data plane)
• Простіше встановлення та експлуатація
• Менше можливостей, ніж Istio

Consul Connect

• Сайт: consul.io/docs/connect
• Service mesh від HashiCorp
• Мультихмарний (AWS, Azure, GCP, on-premises)
• Інтеграція з Consul service discovery

::

┌──────────────────────────────────────┐
│   Control Plane (Управління)         │
│  - Виписування сертифікатів          │
│  - Конфігурація політик               │
│  - Збір метрик та трейсів            │
└─────────────┬────────────────────────┘
              │
    ┌─────────┴─────────┬──────────────┐
    │                   │              │
┌───▼────┐         ┌───▼────┐    ┌───▼────┐
│Service A│        │Service B│    │Service C│
│ ┌────┐  │        │ ┌────┐  │    │ ┌────┐  │
│ │App │  │        │ │App │  │    │ │App │  │
│ └─┬──┘  │        │ └─┬──┘  │    │ └─┬──┘  │
│ ┌─▼────┐│        │ ┌─▼────┐│    │ ┌─▼────┐│
│ │Sidecar◄───mTLS───►Sidecar◄─mTLS─►Sidecar││
│ │(Envoy)││        │ │(Envoy)││    │ │(Envoy)││
│ └──────┘│        │ └──────┘│    │ └──────┘│
└─────────┘        └─────────┘    └─────────┘

::

Моніторинг та спостережуваність gRPC-сервісів

go get github.com/grpc-ecosystem/go-grpc-prometheus
go get github.com/prometheus/client_golang/prometheus/promhttp

import (
    grpc_prometheus "github.com/grpc-ecosystem/go-grpc-prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
    "google.golang.org/grpc"
)

func main() {
    // Створюємо gRPC сервер з Prometheus інтерцептором
    server := grpc.NewServer(
        grpc.ChainUnaryInterceptor(
            grpc_prometheus.UnaryServerInterceptor,
        ),
        grpc.ChainStreamInterceptor(
            grpc_prometheus.StreamServerInterceptor,
        ),
    )
    
    // Реєструємо сервіси
    pb.RegisterUserServiceServer(server, &userService{})
    
    // Ініціалізуємо метрики
    grpc_prometheus.Register(server)
    
    // Експортуємо метрики через HTTP endpoint
    http.Handle("/metrics", promhttp.Handler())
    go http.ListenAndServe(":9090", nil)
    
    // Запускаємо gRPC сервер
    server.Serve(listener)
}

conn, err := grpc.Dial(
    "localhost:50051",
    grpc.WithUnaryInterceptor(
        grpc_prometheus.UnaryClientInterceptor,
    ),
    grpc.WithStreamInterceptor(
        grpc_prometheus.StreamClientInterceptor,
    ),
)

# RPS (Requests Per Second)
rate(grpc_server_handled_total[1m])

# Success rate
sum(rate(grpc_server_handled_total{grpc_code="OK"}[5m])) / 
sum(rate(grpc_server_handled_total[5m]))

# 99th percentile latency
histogram_quantile(0.99, 
  rate(grpc_server_handling_seconds_bucket[5m])
)

# Error rate by method
sum by (grpc_method) (
  rate(grpc_server_handled_total{grpc_code!="OK"}[5m])
)

go get go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc
go get go.opentelemetry.io/otel
go get go.opentelemetry.io/otel/exporters/jaeger

import (
    "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
    "go.opentelemetry.io/otel"
)

func main() {
    // Ініціалізація OpenTelemetry tracer
    tp := initTracer()
    defer tp.Shutdown(context.Background())
    
    // gRPC сервер з трейсингом
    server := grpc.NewServer(
        grpc.StatsHandler(otelgrpc.NewServerHandler()),
    )
    
    // gRPC клієнт з трейсингом
    conn, _ := grpc.Dial(
        "localhost:50051",
        grpc.WithStatsHandler(otelgrpc.NewClientHandler()),
    )
}

func initTracer() *sdktrace.TracerProvider {
    exporter, _ := jaeger.New(jaeger.WithCollectorEndpoint(
        jaeger.WithEndpoint("http://localhost:14268/api/traces"),
    ))
    
    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(exporter),
        sdktrace.WithResource(resource.NewWithAttributes(
            semconv.SchemaURL,
            semconv.ServiceName("userservice"),
        )),
    )
    
    otel.SetTracerProvider(tp)
    return tp
}