Реактивное программирование
R2DBC vs JDBC: реактивные базы данных
Исторический контекст: что такое JDBC и почему он доминировал десятилетиями
JDBC — это стандартный API Java для доступа к реляционным базам данных, появившийся ещё в JDK 1.1 (1997 год).
Он позволяет выполнять SQL-запросы, управлять соединениями и обрабатывать результаты через унифицированный интерфейс, независимо от конкретной БД (PostgreSQL, MySQL, Oracle и т.д.).
Ключевые компоненты JDBC:
DriverManager или DataSource: Для получения соединения (Connection).
Statement/PreparedStatement: Для выполнения SQL (executeQuery, executeUpdate).
ResultSet: Для чтения результатов (next(), getString() и т.д.).
Transaction management: commit(), rollback().
Пример простого JDBC-кода:
Это синхронно и блокирующе: executeQuery() "виснет" до ответа от БД, блокируя текущий поток.
В традиционных приложениях (как Spring MVC) это работало: каждый запрос — отдельный поток из пула (например, Tomcat с 200 потоками), и если БД отвечает быстро, проблем нет. Но под высокой нагрузкой или с медленными запросами (сетевые задержки, сложные джойны) пул исчерпывается: потоки "спят" в ожидании IO, CPU простаивает, а новые запросы ждут в очереди, вызывая таймауты и отказы. Это классическая проблема асинхронщины: JDBC не предназначен для non-blocking IO, он полагается на blocking calls операционной системы.
В реактивных приложениях (WebFlux) использование JDBC — антипаттерн: если контроллер возвращает Mono, но внутри — blocking JDBC, весь выигрыш теряется. Поток из event-loop (Netty) блокируется, снижая throughput (пропускную способность). Вот почему нужен новый подход.
Проблемы JDBC в реактивном контексте: почему старый стандарт не справляется
Давайте разберём проблемы JDBC подробно, чтобы понять мотивацию R2DBC:
Блокирующая природа: Все операции (connect, query, fetch) — синхронны. В асинхронном коде это требует обёрток вроде CompletableFuture или offload на отдельный пул (Schedulers.boundedElastic()), но это хак: теряется истинная реактивность, и под нагрузкой пулы переполняются.
Отсутствие backpressure: ResultSet — pull-модель (next() получает данные), но без контроля темпа. Если результат огромный (миллионы строк), буфер переполняется, рискуя OOM (OutOfMemoryError). В реактивном мире (push с backpressure) это несовместимо.
Управление соединениями: JDBC полагается на пулы (HikariCP), но они ориентированы на blocking: соединение "занято" весь запрос. В реактиве нужно multiplexing — одно соединение для многих операций асинхронно.
Транзакции: @Transactional в Spring работает, но в реактиве требует специальной поддержки (reactive transactions), иначе — блокировки.
Масштабируемость: Под 10k+ RPS (requests per second) с БД-запросами JDBC требует огромных пулов потоков (тысячи), что жрёт память (каждый поток ~1MB стека) и контекст-свичинг.
Интеграция с Reactor: Нет native Publisher — результаты не "текут" как Flux, требуя ручной конвертации, что добавляет boilerplate и риски.
В итоге, JDBC — отличный для legacy или низконагруженных приложений, но в микросервисах с WebFlux он "ломает" реактивный стек, возвращая к болям callback-ада и ожиданий.
Введение в R2DBC: реактивный стандарт для реляционных БД
R2DBC — это спецификация (с 2019 года, под эгидой Spring и Pivotal), определяющая API для доступа к реляционным БД в реактивном стиле. Это не замена JDBC, а параллельный стандарт, ориентированный на non-blocking IO.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
R2DBC vs JDBC: реактивные базы данных
Исторический контекст: что такое JDBC и почему он доминировал десятилетиями
JDBC — это стандартный API Java для доступа к реляционным базам данных, появившийся ещё в JDK 1.1 (1997 год).
Он позволяет выполнять SQL-запросы, управлять соединениями и обрабатывать результаты через унифицированный интерфейс, независимо от конкретной БД (PostgreSQL, MySQL, Oracle и т.д.).
Ключевые компоненты JDBC:
DriverManager или DataSource: Для получения соединения (Connection).
Statement/PreparedStatement: Для выполнения SQL (executeQuery, executeUpdate).
ResultSet: Для чтения результатов (next(), getString() и т.д.).
Transaction management: commit(), rollback().
Пример простого JDBC-кода:
import java.sql.*;
public class JdbcExample {
public static void main(String[] args) {
try (Connection conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/db", "user", "pass");
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?")) {
stmt.setLong(1, 1L);
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
System.out.println("User: " + rs.getString("name"));
}
} catch (SQLException e) {
e.printStackTrace();
}
}
}
Это синхронно и блокирующе: executeQuery() "виснет" до ответа от БД, блокируя текущий поток.
В традиционных приложениях (как Spring MVC) это работало: каждый запрос — отдельный поток из пула (например, Tomcat с 200 потоками), и если БД отвечает быстро, проблем нет. Но под высокой нагрузкой или с медленными запросами (сетевые задержки, сложные джойны) пул исчерпывается: потоки "спят" в ожидании IO, CPU простаивает, а новые запросы ждут в очереди, вызывая таймауты и отказы. Это классическая проблема асинхронщины: JDBC не предназначен для non-blocking IO, он полагается на blocking calls операционной системы.
В реактивных приложениях (WebFlux) использование JDBC — антипаттерн: если контроллер возвращает Mono, но внутри — blocking JDBC, весь выигрыш теряется. Поток из event-loop (Netty) блокируется, снижая throughput (пропускную способность). Вот почему нужен новый подход.
Проблемы JDBC в реактивном контексте: почему старый стандарт не справляется
Давайте разберём проблемы JDBC подробно, чтобы понять мотивацию R2DBC:
Блокирующая природа: Все операции (connect, query, fetch) — синхронны. В асинхронном коде это требует обёрток вроде CompletableFuture или offload на отдельный пул (Schedulers.boundedElastic()), но это хак: теряется истинная реактивность, и под нагрузкой пулы переполняются.
Отсутствие backpressure: ResultSet — pull-модель (next() получает данные), но без контроля темпа. Если результат огромный (миллионы строк), буфер переполняется, рискуя OOM (OutOfMemoryError). В реактивном мире (push с backpressure) это несовместимо.
Управление соединениями: JDBC полагается на пулы (HikariCP), но они ориентированы на blocking: соединение "занято" весь запрос. В реактиве нужно multiplexing — одно соединение для многих операций асинхронно.
Транзакции: @Transactional в Spring работает, но в реактиве требует специальной поддержки (reactive transactions), иначе — блокировки.
Масштабируемость: Под 10k+ RPS (requests per second) с БД-запросами JDBC требует огромных пулов потоков (тысячи), что жрёт память (каждый поток ~1MB стека) и контекст-свичинг.
Интеграция с Reactor: Нет native Publisher — результаты не "текут" как Flux, требуя ручной конвертации, что добавляет boilerplate и риски.
В итоге, JDBC — отличный для legacy или низконагруженных приложений, но в микросервисах с WebFlux он "ломает" реактивный стек, возвращая к болям callback-ада и ожиданий.
Введение в R2DBC: реактивный стандарт для реляционных БД
R2DBC — это спецификация (с 2019 года, под эгидой Spring и Pivotal), определяющая API для доступа к реляционным БД в реактивном стиле. Это не замена JDBC, а параллельный стандарт, ориентированный на non-blocking IO.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
👍2
Ключевые идеи:
Publisher-based API: Все операции возвращают Publisher (Mono/Flux из Reactive Streams): Connection как Mono<Connection>, Statement.execute() как Flux<Row>.
Non-blocking от начала до конца: Использует асинхронные драйверы (для PostgreSQL, MySQL и т.д.), где соединения мультиплексируются — одно для многих запросов.
Backpressure встроено: Результаты (Flux<Row>) уважают request(n): если подписчик не готов, БД не шлёт данные, избегая перегрузки.
Транзакции реактивные: Поддержка @Transactional с Mono/Flux.
Интеграция с экосистемой: Spring Data R2DBC — аналог Spring Data JPA, с репозиториями, @Query и CRUD.
Драйверы: r2dbc-postgresql, r2dbc-mysql и т.д. — реализуют спецификацию, используя неблокирующие сокеты (Netty или аналог).
Пример базового R2DBC-кода (без Spring):
Здесь usingWhen — реактивный try-with-resources: создаёт соединение асинхронно, выполняет запрос как Flux<Result>, map извлекает данные. Нет блокировок: если БД медленная, поток свободен.
Spring Data R2DBC: упрощение с репозиториями и аннотациями
Spring Data R2DBC — модуль, который абстрагирует R2DBC, как Spring Data JPA для JDBC.
Добавьте зависимость:
Настройте в application.properties:
Репозитории:
Сущность:
В сервисе/контроллере:
В контроллере:
Это декларативно: repo.findAll() — Flux, который "течёт" из БД без блокировок. Транзакции: @Transactional на методе — reactive, rollback асинхронно.
Расширенный пример: пагинация с ReactiveSortingRepository и Pageable.
Практические советы и подводные камни
Выбор БД: PostgreSQL — лучший для R2DBC (полная поддержка async).
Тестирование: Embedded H2 с r2dbc-h2, ReactiveTest для StepVerifier.
Камень: Нет full ORM (как JPA entities с relations) — используйте ручные joins или Spring Data Projections.
Камень: Транзакции не поддерживают propagation в nested методах fully — будьте осторожны.
Совет: Для hybrid (JDBC + R2DBC) — используйте разные DataSource, но избегайте в одном приложении.
Совет: Мониторьте с Micrometer: метрики на запросы, соединения.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
Publisher-based API: Все операции возвращают Publisher (Mono/Flux из Reactive Streams): Connection как Mono<Connection>, Statement.execute() как Flux<Row>.
Non-blocking от начала до конца: Использует асинхронные драйверы (для PostgreSQL, MySQL и т.д.), где соединения мультиплексируются — одно для многих запросов.
Backpressure встроено: Результаты (Flux<Row>) уважают request(n): если подписчик не готов, БД не шлёт данные, избегая перегрузки.
Транзакции реактивные: Поддержка @Transactional с Mono/Flux.
Интеграция с экосистемой: Spring Data R2DBC — аналог Spring Data JPA, с репозиториями, @Query и CRUD.
Драйверы: r2dbc-postgresql, r2dbc-mysql и т.д. — реализуют спецификацию, используя неблокирующие сокеты (Netty или аналог).
Пример базового R2DBC-кода (без Spring):
import io.r2dbc.spi.ConnectionFactories;
import io.r2dbc.spi.ConnectionFactory;
import reactor.core.publisher.Flux;
public void createConnectionFactory () {
ConnectionFactory factory = ConnectionFactories.get("r2dbc:postgresql://localhost:5432/db?username=user&password=pass");
Flux<String> namesFlux = Flux.usingWhen(
factory.create(), // Асинхронно создать соединение
conn -> conn.createStatement("SELECT name FROM users").execute().flatMap(result -> result.map((row, metadata) -> row.get("name", String.class))),
conn -> conn.close() // Асинхронно закрыть
);
namesFlux.subscribe(System.out::println); // Строки приходят асинхронно
}
Здесь usingWhen — реактивный try-with-resources: создаёт соединение асинхронно, выполняет запрос как Flux<Result>, map извлекает данные. Нет блокировок: если БД медленная, поток свободен.
Spring Data R2DBC: упрощение с репозиториями и аннотациями
Spring Data R2DBC — модуль, который абстрагирует R2DBC, как Spring Data JPA для JDBC.
Добавьте зависимость:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-r2dbc</artifactId>
</dependency>
<dependency>
<groupId>io.r2dbc</groupId>
<artifactId>r2dbc-postgresql</artifactId> <!-- Для PostgreSQL -->
</dependency>
Настройте в application.properties:
spring.r2dbc.url=r2dbc:postgresql://localhost:5432/db
spring.r2dbc.username=user
spring.r2dbc.password=pass
Репозитории:
ReactiveRepository extends ReactiveCrudRepository<Entity, ID>.
Сущность:
@Entity
public class User {
@Id
private Long id;
private String name;
// Getters/setters
}
public interface UserRepository extends ReactiveCrudRepository<User, Long> {
@Query("SELECT * FROM users WHERE name LIKE :name")
Flux<User> findByNameLike(String name);
}
В сервисе/контроллере:
@Service
public class UserService {
private final UserRepository repo;
public UserService(UserRepository repo) {
this.repo = repo;
}
public Flux<User> findAll() {
return repo.findAll(); // Flux асинхронно
}
public Mono<User> save(User user) {
return repo.save(user);
}
}
В контроллере:
@GetMapping("/users")
public Flux<User> getAllUsers() {
return userService.findAll();
}Это декларативно: repo.findAll() — Flux, который "течёт" из БД без блокировок. Транзакции: @Transactional на методе — reactive, rollback асинхронно.
Расширенный пример: пагинация с ReactiveSortingRepository и Pageable.
public interface UserRepository extends ReactiveSortingRepository<User, Long> {}
Flux<User> paged = repo.findAll(Sort.by("name").ascending()).skip(10).take(20); // Простая пагинация
Для complex: используйте @Query с параметрами, или Criteria API.Практические советы и подводные камни
Выбор БД: PostgreSQL — лучший для R2DBC (полная поддержка async).
Тестирование: Embedded H2 с r2dbc-h2, ReactiveTest для StepVerifier.
Камень: Нет full ORM (как JPA entities с relations) — используйте ручные joins или Spring Data Projections.
Камень: Транзакции не поддерживают propagation в nested методах fully — будьте осторожны.
Совет: Для hybrid (JDBC + R2DBC) — используйте разные DataSource, но избегайте в одном приложении.
Совет: Мониторьте с Micrometer: метрики на запросы, соединения.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
👍2
Реактивное программирование
Горячие и холодные Publisher’ы в реактивном программировании
Publisher — это источник данных в Reactive Streams, который "толкает" элементы подписчикам (Subscriber). Но не все Publisher’ы одинаковы по поведению при множественных подписках. Это зависит от того, генерирует ли он данные независимо от подписчиков (горячий) или заново для каждого (холодный).
Холодный Publisher (Cold Publisher): Данные генерируются лениво — только при подписке, и для каждого подписчика отдельно. Это как видео по запросу: каждый зритель получает свою копию потока. Плюс: свежие данные каждый раз. Минус: если источник дорогой (запрос в БД, вычисления), повторяется зря.
Горячий Publisher (Hot Publisher): Данные генерируются независимо от подписчиков — поток "вещает" непрерывно. Подписчики "подключаются" к существующему потоку и получают данные с момента подписки. Это как живой эфир: все слушают одно и то же, но опоздавшие пропускают начало. Плюс: экономия ресурсов (один источник). Минус: данные могут быть "старыми" или пропущенными.
В Project Reactor большинство конструкторов — холодные (just, fromIterable, range), но есть горячие (interval, push). Поведение можно менять операторами (share, cache).
Примеры холодных Publisher’ов: ленивость и независимость
Холодные — default в Reactor: подписка запускает генерацию заново.
Пример с Mono (одиночный элемент, но принцип тот же):
С Flux:
Примеры горячих Publisher’ов: общий поток и вещание
Горячие — генерируют данные один раз, подписчики "присоединяются".
Пример с Flux.push (горячий по дизайну):
Другой горячий:
#Java #middle #Reactor #WebFlux #Mono #Flux
Горячие и холодные Publisher’ы в реактивном программировании
Publisher — это источник данных в Reactive Streams, который "толкает" элементы подписчикам (Subscriber). Но не все Publisher’ы одинаковы по поведению при множественных подписках. Это зависит от того, генерирует ли он данные независимо от подписчиков (горячий) или заново для каждого (холодный).
Холодный Publisher (Cold Publisher): Данные генерируются лениво — только при подписке, и для каждого подписчика отдельно. Это как видео по запросу: каждый зритель получает свою копию потока. Плюс: свежие данные каждый раз. Минус: если источник дорогой (запрос в БД, вычисления), повторяется зря.
Горячий Publisher (Hot Publisher): Данные генерируются независимо от подписчиков — поток "вещает" непрерывно. Подписчики "подключаются" к существующему потоку и получают данные с момента подписки. Это как живой эфир: все слушают одно и то же, но опоздавшие пропускают начало. Плюс: экономия ресурсов (один источник). Минус: данные могут быть "старыми" или пропущенными.
В Project Reactor большинство конструкторов — холодные (just, fromIterable, range), но есть горячие (interval, push). Поведение можно менять операторами (share, cache).
Примеры холодных Publisher’ов: ленивость и независимость
Холодные — default в Reactor: подписка запускает генерацию заново.
Пример с Mono (одиночный элемент, но принцип тот же):
Mono<String> coldMono = Mono.fromCallable(() -> {
System.out.println("Генерация данных...");
return "Данные";
});
coldMono.subscribe(System.out::println); // Вывод: "Генерация данных..." и "Данные"
coldMono.subscribe(System.out::println); // Снова: "Генерация данных..." и "Данные"
Каждый subscribe() вызывает fromCallable заново — данные свежие, но если это запрос в API, будет два вызова.С Flux:
Flux<Integer> coldFlux = Flux.range(1, 3).doOnSubscribe(sub -> System.out.println("Новая подписка!"));
coldFlux.subscribe(val -> System.out.println("Подписчик 1: " + val));
coldFlux.subscribe(val -> System.out.println("Подписчик 2: " + val));
// Вывод: "Новая подписка!" + 1,2,3 для первого; "Новая подписка!" + 1,2,3 для второго
Каждый подписчик получает полный поток независимо. Полезно для idempotent операций (без side-effects), как чтение статичных данных.
Асинхронный пример: coldFlux = Flux.interval(Duration.ofSeconds(1)).take(3); // Каждый subscribe() запускает свой таймер.Примеры горячих Publisher’ов: общий поток и вещание
Горячие — генерируют данные один раз, подписчики "присоединяются".
Пример с Flux.push (горячий по дизайну):
ConnectableFlux<Integer> hotFlux = Flux.push(sink -> {
// Симулируем внешний источник
new Thread(() -> {
for (int i = 1; i <= 3; i++) {
try { Thread.sleep(1000); } catch (InterruptedException e) {}
sink.next(i);
}
sink.complete();
}).start();
});
hotFlux.subscribe(val -> System.out.println("Подписчик 1: " + val));
Thread.sleep(1500); // Ждём, чтобы пропустить начало
hotFlux.subscribe(val -> System.out.println("Подписчик 2: " + val));
hotFlux.connect(); // Запуск горячего
// Вывод примерно: Подписчик 1: 1 (1с), 2 (2с), 3 (3с); Подписчик 2: 2 (присоединился после 1), 3
Второй пропустил 1 — поток общий. Connect() — триггер для ConnectableFlux (обёртка для горячих).Другой горячий:
Flux.interval(Duration.ofSeconds(1)) — бесконечный таймер, вещает независимо.
Оператор share(): Делает холодный горячим.
Flux<Integer> shared = coldFlux.share();
shared.subscribe(...); // Запускает
shared.subscribe(...); // Присоединяется к существующему
#Java #middle #Reactor #WebFlux #Mono #Flux
👍2
Переключение типов: операторы для контроля
Из холодного в горячий: share() (для Flux), cache() (кэширует элементы для повторов), publish() (ConnectableFlux с backpressure).
Пример cache:
coldMono.cache() — первый subscribe генерирует, последующие — из кэша.
Из горячего в холодный: Редко нужно, но replay() на ConnectableFlux кэширует историю для новых подписчиков.
Сценарии:
Холодный: Запросы к БД (каждый клиент — свежие данные).
Горячий: Мониторинг (один сенсор — всем подписчикам), стриминг событий (Kafka topic).
Практические советы и подводные камни
Диагностика: doOnSubscribe(() -> log("Subscribe")) — увидите, сколько раз запускается.
Камень: Холодный с side-effects (мутации) — непредсказуемо при множественных подписках; используйте defer() для ленивости.
Камень: Горячий бесконечный без take() — утечки; добавьте refCount() на publish() для авто-отписки при 0 подписчиках.
Совет: В WebFlux — Flux из БД (R2DBC, пост 17) холодный по умолчанию; share() для кэширования результатов.
Тестирование: StepVerifier с .publish() для симуляции горячих.
#Java #middle #Reactor #WebFlux #Mono #Flux
Из холодного в горячий: share() (для Flux), cache() (кэширует элементы для повторов), publish() (ConnectableFlux с backpressure).
Пример cache:
coldMono.cache() — первый subscribe генерирует, последующие — из кэша.
Из горячего в холодный: Редко нужно, но replay() на ConnectableFlux кэширует историю для новых подписчиков.
Сценарии:
Холодный: Запросы к БД (каждый клиент — свежие данные).
Горячий: Мониторинг (один сенсор — всем подписчикам), стриминг событий (Kafka topic).
Практические советы и подводные камни
Диагностика: doOnSubscribe(() -> log("Subscribe")) — увидите, сколько раз запускается.
Камень: Холодный с side-effects (мутации) — непредсказуемо при множественных подписках; используйте defer() для ленивости.
Камень: Горячий бесконечный без take() — утечки; добавьте refCount() на publish() для авто-отписки при 0 подписчиках.
Совет: В WebFlux — Flux из БД (R2DBC, пост 17) холодный по умолчанию; share() для кэширования результатов.
Тестирование: StepVerifier с .publish() для симуляции горячих.
#Java #middle #Reactor #WebFlux #Mono #Flux
👍3
Что такое gRPC и зачем он нужен
Представьте, что ваши программы — это люди в огромном городе. Им нужно обмениваться информацией: один спрашивает адрес, другой — погоду, третий — заказывает еду. Если они общаются письмами (медленно и объемно), то город встанет в пробке. А если по телефону — быстро, четко и без лишних слов?
Вот gRPC (высокопроизводительный фреймворк для удаленного вызова процедур) — это как суперсовременная телефонная сеть для программ. Он позволяет одной программе вызывать функции в другой, как будто они работают на одном компьютере, но через интернет или сеть.
Зачем изучать gRPC в 2025 году? Потому что мир софта ушел от простых сайтов к сложным системам: миллиарды устройств в интернете вещей, тысячи микросервисов в компаниях вроде Netflix или Uber. Обычные веб-API (как REST) здесь тормозят — gRPC ускоряет всё в 7–10 раз, экономит трафик и упрощает разработку.
Что такое RPC: Простое объяснение концепции удаленного вызова процедур
Удаленный вызов процедур (RPC — Remote Procedure Call) — это идея, где программа А "звонит" программе Б и говорит: "Выполни эту функцию и верни результат". Всё выглядит как обычный вызов локальной функции: передаешь данные, ждешь ответ — и готово. Никаких сложностей с сетью на уровне кода.
Пример из жизни: Вы в приложении нажимаете "Получить погоду" — ваше мобильное app вызывает функцию на сервере метеослужбы. Сервер считает, возвращает данные. В gRPC это пишется так же просто:
Без 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
Представьте, что ваши программы — это люди в огромном городе. Им нужно обмениваться информацией: один спрашивает адрес, другой — погоду, третий — заказывает еду. Если они общаются письмами (медленно и объемно), то город встанет в пробке. А если по телефону — быстро, четко и без лишних слов?
Вот 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
👍2👎1
Почему 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
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
👍3
Архитектура 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 — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.
Пример:
После генерации protoc создаёт классы:
Реализация сервера:
Клиент:
#Java #middle #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
👍2
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 файл и генерирует исходный код для нужного языка.
Например:
gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.
Таким образом, 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 — это бинарный формат сериализации данных, разработанный 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
👍2
Protocol Buffers: сердце gRPC
Если gRPC — это двигатель взаимодействия сервисов, то Protocol Buffers (protobuf) — это его сердце.
Именно protobuf определяет, как описываются данные, как они сериализуются, и как из одной схемы генерируются типобезопасные классы для разных языков.
Чтобы по-настоящему понимать gRPC, нужно уверенно работать с .proto-файлами.
1. Что такое .proto файл
.proto — это файл описания структуры данных и интерфейсов (API).
Он играет сразу три роли:
Документирует контракт между клиентом и сервером (описывает, какие методы и какие данные доступны).
Генерирует код для разных языков с помощью protoc (компилятора Protocol Buffers).
Определяет схему сериализации — то, как объекты превращаются в байты и обратно.
Фактически .proto — это единый источник правды для вашего API.
2. Базовая структура .proto файла
Пример простого файла:
3. Ключевые элементы .proto
3.1. syntax
Первая строка файла:
Обязательно указывает версию синтаксиса.
На практике используется только proto3, потому что она проще, строже типизирована и лучше поддерживается в gRPC.
3.2. package
Задает логическое пространство имён, чтобы избежать конфликтов:
В Java и других языках это превращается в пакеты/модули.
3.3. option
Позволяет задавать настройки генерации кода, например:
Без этого весь код попадёт в один файл, что неудобно для больших схем.
3.4. message — описание структуры данных
message — это аналог класса в объектно-ориентированных языках.
Каждое поле внутри него — это свойство (переменная), которое сериализуется в бинарный поток.
Пример:
3.5. enum — перечисление значений
enum — это список допустимых констант.
Значение 0 обязательно — это значение по умолчанию.
При сериализации хранится не текстовое имя ("ACTIVE"), а его числовое значение (0), что делает protobuf компактным.
3.6. service — описание API
service определяет набор удалённых методов, которые сервер предоставляет клиенту.
Это аналог интерфейса в Java:
Каждый rpc определяет:
имя метода (BuyCar),
входной тип (CarRequest),
выходной тип (CarResponse).
4. Типы данных в Protocol Buffers
Protobuf поддерживает ограниченный, но универсальный набор типов.
Некоторые часто используемые:
string - Текст
bool - Логическое значение
int32, int64 - Целые числа
float, double - Числа с плавающей точкой
bytes - Массив байтов
repeated - Массив
map<key, value> - Словарь
Пример:
#Java #middle #gRPC #proto
Если 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
👍2
5. Нумерация полей — почему это критично
Каждое поле имеет свой уникальный номер — это его идентификатор в бинарном потоке.
Если поменять номера, клиент и сервер перестанут понимать друг друга.
Например, если у старой версии клиента year = 2, а у новой year = 3, при сериализации они будут читать разные данные.
6. Почему важно резервировать поля
Когда вы удаляете или переименовываете поле, нельзя просто убрать строку — нужно зарезервировать номер и имя.
Пример:
Это предотвращает случайное переиспользование старого номера под другое поле, что может привести к неправильной интерпретации данных.
7. Эволюция и миграция схем (Schema Evolution)
Protobuf специально спроектирован так, чтобы позволять обновлять схемы без поломки совместимости.
Главное — соблюдать несколько правил.
Что можно делать безопасно:
Добавлять новые поля с новыми номерами.
Удалять поля (с их резервированием).
Изменять имя поля (номер должен остаться прежним).
Изменять порядок полей — не влияет на сериализацию.
Что делать нельзя:
Менять тип поля (например, int32 → string).
Менять номер поля.
Удалять поле без reserved.
Пример миграции
Старая версия:
Новая версия:
Старый клиент, который не знает про email, просто проигнорирует это поле.
А новый клиент не столкнётся с конфликтом, потому что старый 2 зарезервирован.
8. Компиляция .proto файла и генерация кода
protoc — компилятор, который читает .proto и создаёт Java-классы.
Пример команды:
Результат:
Для каждого message создаются классы с Builder-паттерном.
Для service создаются классы CarServiceGrpc, CarServiceImplBase, CarServiceStub.
9. Пример полного цикла
Файл car.proto:
Сгенерированный код в Java (упрощённо):
Серверная реализация:
#Java #middle #gRPC #proto
Каждое поле имеет свой уникальный номер — это его идентификатор в бинарном потоке.
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
👍3