gRPC в продакшене
1. Аутентификация и авторизация
gRPC изначально построен на HTTP/2, а значит поддерживает все стандартные механизмы шифрования и аутентификации, включая TLS/SSL.
На уровне протокола клиент и сервер могут обмениваться метаданными (headers), которые используются для передачи токенов, ключей или сессионных идентификаторов.
Аутентификация (authentication)
Аутентификация — это подтверждение личности клиента.
В gRPC это реализуется через метаданные (Metadata), которые добавляются к каждому запросу:
На стороне сервера этот токен можно проверить с помощью interceptor (см. ниже).
В корпоративных системах часто используются:
JWT (JSON Web Token) — стандартный формат токена.
mTLS (Mutual TLS) — двустороннее TLS-шифрование, где аутентифицируются обе стороны.
OAuth 2.0 — для интеграции с внешними провайдерами (Google, Auth0 и т.п.).
Авторизация (authorization)
После того как клиент прошёл аутентификацию, нужно проверить, имеет ли он право выполнять определённые действия.
Обычно авторизация реализуется на уровне interceptor’ов или бизнес-логики, где проверяются роли и права пользователя.
2. Interceptors — middleware для gRPC
Interceptors в gRPC выполняют ту же роль, что фильтры в Spring или middleware в Express.js.
Это промежуточные обработчики, которые могут:
логировать запросы и ответы;
измерять метрики;
проверять токены безопасности;
модифицировать контекст вызова;
перехватывать ошибки.
Пример серверного interceptor’а
Регистрируется interceptor при инициализации сервера:
Interceptors можно комбинировать — например, один для логирования, другой для метрик, третий для авторизации.
Это делает gRPC гибким и расширяемым.
#Java #middle #gRPC #proto
1. Аутентификация и авторизация
gRPC изначально построен на HTTP/2, а значит поддерживает все стандартные механизмы шифрования и аутентификации, включая TLS/SSL.
На уровне протокола клиент и сервер могут обмениваться метаданными (headers), которые используются для передачи токенов, ключей или сессионных идентификаторов.
Аутентификация (authentication)
Аутентификация — это подтверждение личности клиента.
В gRPC это реализуется через метаданные (Metadata), которые добавляются к каждому запросу:
// Пример Java-клиента с авторизационным токеном
ManagedChannel channel = ManagedChannelBuilder
.forAddress("localhost", 50051)
.useTransportSecurity()
.build();
CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc
.newBlockingStub(channel)
.withCallCredentials(new CallCredentials() {
@Override
public void applyRequestMetadata(
RequestInfo requestInfo, Executor executor, MetadataApplier applier) {
Metadata headers = new Metadata();
Metadata.Key<String> AUTHORIZATION =
Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER);
headers.put(AUTHORIZATION, "Bearer my-secret-token");
applier.apply(headers);
}
});
На стороне сервера этот токен можно проверить с помощью interceptor (см. ниже).
В корпоративных системах часто используются:
JWT (JSON Web Token) — стандартный формат токена.
mTLS (Mutual TLS) — двустороннее TLS-шифрование, где аутентифицируются обе стороны.
OAuth 2.0 — для интеграции с внешними провайдерами (Google, Auth0 и т.п.).
Авторизация (authorization)
После того как клиент прошёл аутентификацию, нужно проверить, имеет ли он право выполнять определённые действия.
Обычно авторизация реализуется на уровне interceptor’ов или бизнес-логики, где проверяются роли и права пользователя.
2. Interceptors — middleware для gRPC
Interceptors в gRPC выполняют ту же роль, что фильтры в Spring или middleware в Express.js.
Это промежуточные обработчики, которые могут:
логировать запросы и ответы;
измерять метрики;
проверять токены безопасности;
модифицировать контекст вызова;
перехватывать ошибки.
Пример серверного interceptor’а
public class AuthInterceptor implements ServerInterceptor {
@Override
public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(
ServerCall<ReqT, RespT> call,
Metadata headers,
ServerCallHandler<ReqT, RespT> next) {
String token = headers.get(Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER));
if (token == null || !token.equals("Bearer my-secret-token")) {
call.close(Status.UNAUTHENTICATED.withDescription("Invalid token"), headers);
return new ServerCall.Listener<>() {}; // пустой listener
}
return next.startCall(call, headers);
}
}Регистрируется interceptor при инициализации сервера:
Server server = ServerBuilder
.forPort(50051)
.addService(ServerInterceptors.intercept(new CarServiceImpl(), new AuthInterceptor()))
.build()
.start();
Interceptors можно комбинировать — например, один для логирования, другой для метрик, третий для авторизации.
Это делает gRPC гибким и расширяемым.
#Java #middle #gRPC #proto
👍1
3. gRPC Gateway — REST-прокси для совместимости
Хотя gRPC эффективен, не все клиенты умеют с ним работать напрямую (например, браузеры без gRPC-Web).
Чтобы не дублировать API, используется gRPC Gateway — это HTTP-прокси, который преобразует REST-запросы в gRPC-вызовы.
Как это работает
Клиент делает обычный HTTP-запрос (GET, POST, PUT).
Gateway принимает запрос и преобразует его в бинарный gRPC-вызов.
Сервер gRPC обрабатывает его и возвращает ответ.
Gateway обратно конвертирует ответ в JSON.
Файл .proto содержит специальные аннотации:
Так создаётся REST-эндпоинт /v1/cars/{id}, который вызывает gRPC-метод GetCar.
gRPC Gateway позволяет сохранять одну кодовую базу и одну схему, но обслуживать и gRPC-, и REST-клиентов одновременно.
4. Балансировка нагрузки и мониторинг
gRPC поддерживает client-side load balancing, когда клиент сам выбирает, к какому серверу подключаться, используя список адресов.
Это особенно важно для микросервисов, где количество экземпляров сервиса динамически меняется.
Поддерживаются различные политики: round-robin, pick-first, weighted.
В Kubernetes это можно комбинировать с сервис-дискавери (через DNS или Consul).
Для продакшена жизненно важно собирать метрики.
gRPC интегрируется с Prometheus, OpenTelemetry, Zipkin, Jaeger для трассировки и мониторинга.
Через interceptors можно логировать время ответа, коды ошибок и нагрузку:
Трассировка (tracing) позволяет увидеть цепочку вызовов между микросервисами — от клиента до базы данных.
5. Совместимость версий и эволюция схем
Когда сервисы растут, .proto-файлы меняются.
Важно, чтобы новые версии клиента и сервера могли работать вместе без сбоев.
Для этого protobuf предоставляет правила совместимости.
Основные правила миграции
Не менять номера полей.
Каждое поле в message имеет уникальный номер, и именно он используется при сериализации.
Изменить имя поля можно, номер — нельзя.
Резервировать удалённые поля.
Если поле больше не используется, его нужно “зарезервировать”:
Это защищает от случайного переиспользования номеров или имён.
Добавлять новые поля безопасно.
Клиенты старых версий просто игнорируют незнакомые поля, сохраняя обратную совместимость.
Не менять тип данных существующих полей.
Например, int32 нельзя заменить на string.
Версионирование API
Часто версии отражаются в пакетах или namespace:
Так можно постепенно внедрять новые контракты без нарушения старых клиентов.
6. Как всё выглядит в продакшене
Реальная система на gRPC обычно включает:
Сервер с набором interceptor’ов (логирование, метрики, безопасность).
TLS-сертификаты и JWT-аутентификацию.
Балансировку через Kubernetes или сервис-дискавери.
Мониторинг и трассировку через OpenTelemetry.
gRPC Gateway для REST-клиентов.
CI/CD-пайплайн, генерирующий код по .proto и публикующий артефакты для разных языков.
#Java #middle #gRPC #proto
Хотя gRPC эффективен, не все клиенты умеют с ним работать напрямую (например, браузеры без gRPC-Web).
Чтобы не дублировать API, используется gRPC Gateway — это HTTP-прокси, который преобразует REST-запросы в gRPC-вызовы.
Как это работает
Клиент делает обычный HTTP-запрос (GET, POST, PUT).
Gateway принимает запрос и преобразует его в бинарный gRPC-вызов.
Сервер gRPC обрабатывает его и возвращает ответ.
Gateway обратно конвертирует ответ в JSON.
Файл .proto содержит специальные аннотации:
import "google/api/annotations.proto";
service CarService {
rpc GetCar(GetCarRequest) returns (CarResponse) {
option (google.api.http) = {
get: "/v1/cars/{id}"
};
}
}
Так создаётся REST-эндпоинт /v1/cars/{id}, который вызывает gRPC-метод GetCar.
gRPC Gateway позволяет сохранять одну кодовую базу и одну схему, но обслуживать и gRPC-, и REST-клиентов одновременно.
4. Балансировка нагрузки и мониторинг
gRPC поддерживает client-side load balancing, когда клиент сам выбирает, к какому серверу подключаться, используя список адресов.
Это особенно важно для микросервисов, где количество экземпляров сервиса динамически меняется.
Поддерживаются различные политики: round-robin, pick-first, weighted.
В Kubernetes это можно комбинировать с сервис-дискавери (через DNS или Consul).
ManagedChannel channel = ManagedChannelBuilder
.forTarget("dns:///my-grpc-service.default.svc.cluster.local")
.defaultLoadBalancingPolicy("round_robin")
.usePlaintext()
.build();
Для продакшена жизненно важно собирать метрики.
gRPC интегрируется с Prometheus, OpenTelemetry, Zipkin, Jaeger для трассировки и мониторинга.
Через interceptors можно логировать время ответа, коды ошибок и нагрузку:
long start = System.nanoTime();
RespT response = next.startCall(call, headers);
long duration = System.nanoTime() - start;
metrics.recordLatency(duration);
Трассировка (tracing) позволяет увидеть цепочку вызовов между микросервисами — от клиента до базы данных.
5. Совместимость версий и эволюция схем
Когда сервисы растут, .proto-файлы меняются.
Важно, чтобы новые версии клиента и сервера могли работать вместе без сбоев.
Для этого protobuf предоставляет правила совместимости.
Основные правила миграции
Не менять номера полей.
Каждое поле в message имеет уникальный номер, и именно он используется при сериализации.
Изменить имя поля можно, номер — нельзя.
Резервировать удалённые поля.
Если поле больше не используется, его нужно “зарезервировать”:
message Car {
reserved 4, 6 to 8;
reserved "old_model", "legacy_color";
}Это защищает от случайного переиспользования номеров или имён.
Добавлять новые поля безопасно.
Клиенты старых версий просто игнорируют незнакомые поля, сохраняя обратную совместимость.
Не менять тип данных существующих полей.
Например, int32 нельзя заменить на string.
Версионирование API
Часто версии отражаются в пакетах или namespace:
package car.v1;
service CarService { ... }
package car.v2;
service CarService { ... }
Так можно постепенно внедрять новые контракты без нарушения старых клиентов.
6. Как всё выглядит в продакшене
Реальная система на gRPC обычно включает:
Сервер с набором interceptor’ов (логирование, метрики, безопасность).
TLS-сертификаты и JWT-аутентификацию.
Балансировку через Kubernetes или сервис-дискавери.
Мониторинг и трассировку через OpenTelemetry.
gRPC Gateway для REST-клиентов.
CI/CD-пайплайн, генерирующий код по .proto и публикующий артефакты для разных языков.
#Java #middle #gRPC #proto
👍1
Что выведет код?
#Tasks
import java.util.concurrent.ConcurrentHashMap;
public class Task071125 {
public static void main(String[] args) throws InterruptedException {
ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
map.put("count", 0);
Thread t1 = new Thread(() -> {
for (int i = 0; i < 1000; i++) {
map.computeIfPresent("count", (k, v) -> v + 1);
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 1000; i++) {
map.put("count", map.get("count") + 1);
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(map.get("count"));
}
}
#Tasks
👍1
Варианты ответа:
Anonymous Quiz
25%
Будет исключение
0%
Больше 2000
63%
Меньше или равно 2000
13%
Меньше 1000
Вопрос с собеседований
Что делает паттерн Strategy?🤓
Ответ:
Strategy определяет семейство алгоритмов и позволяет подменять их во время выполнения.
Вместо множества if-else выбирается реализация через интерфейс.
Например, разные алгоритмы сортировки или расчёта скидок можно инкапсулировать в отдельные классы.
#собеседование
Что делает паттерн Strategy?
Ответ:
Вместо множества if-else выбирается реализация через интерфейс.
Например, разные алгоритмы сортировки или расчёта скидок можно инкапсулировать в отдельные классы.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1