Вопрос с собеседований
Чем отличается Factory от Builder?🤓
Ответ:
Factory отвечает за создание объекта определённого типа без явного вызова конструктора.
Builder — за пошаговое создание сложного объекта с множеством параметров.
Factory — «что создать», Builder — «как создать».
#собеседование
Чем отличается Factory от Builder?
Ответ:
Factory
Builder — за пошаговое создание сложного объекта с множеством параметров.
Factory — «что создать», Builder — «как создать».
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2 1
История IT-технологий сегодня — 07 ноября
ℹ️ Кто родился в этот день
Барбара Лисков (англ. Liskov, урождённая Барбара Джейн Губерман, англ. Barbara Jane Huberman; род. 7 ноября 1939, Лос-Анджелес) — американский учёный-информатик, лауреат премии Тьюринга, автор принципа замещения Лисков (Liskov substitution principle) и одного из первых языков CLU; значительный вклад в организацию дисциплины программирования.
🌐 Знаковые события
2002 — Microsoft запустила Tablet PC – первую коммерческую платформу для планшетных компьютеров с поддержкой стилуса, работающую на Windows XP Tablet PC Edition, что стало важным шагом в развитии мобильных вычислений.
#Biography #Birth_Date #Events #07Ноября
Барбара Лисков (англ. Liskov, урождённая Барбара Джейн Губерман, англ. Barbara Jane Huberman; род. 7 ноября 1939, Лос-Анджелес) — американский учёный-информатик, лауреат премии Тьюринга, автор принципа замещения Лисков (Liskov substitution principle) и одного из первых языков CLU; значительный вклад в организацию дисциплины программирования.
2002 — Microsoft запустила Tablet PC – первую коммерческую платформу для планшетных компьютеров с поддержкой стилуса, работающую на Windows XP Tablet PC Edition, что стало важным шагом в развитии мобильных вычислений.
#Biography #Birth_Date #Events #07Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы вкладываете деньги? Инвестируете?
Anonymous Poll
16%
Да! И давно)
16%
Не скажу. Это тайна...
26%
Нет, но хотел бы начать, но пока не с чего))
42%
Нет и я не верю в эту белиберду
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
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