Ответ
gRPC — это высокопроизводительный фреймворк для удалённого вызова процедур (RPC) с открытым исходным кодом, изначально разработанный в Google.
Основные принципы:
- Транспорт: Использует HTTP/2 (мультиплексирование, бинарные фреймы, сжатие заголовков).
- Контракты и сериализация: Интерфейсы и структуры данных определяются в
.proto-файлах с помощью Protocol Buffers (protobuf) — бинарного, эффективного и кроссязыкового формата. - Типы потоков: Поддерживает унарные, серверные, клиентские и двунаправленные потоковые вызовы.
Пример определения сервиса (service.proto):
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc CreateUsers (stream User) returns (CreateUsersResponse); // Поток от клиента
}
message GetUserRequest {
string user_id = 1;
}
message User {
string id = 1;
string name = 2;
string email = 3;
}Преимущества: Низкие задержки, высокая пропускная способность, автоматическая генерация клиентского и серверного кода. Область применения: Микросервисные архитектуры, межсервисное взаимодействие, где важна производительность.
Ответ 18+ 🔞
Да ты посмотри, что эти гугловские умники выдумали! gRPC, блядь. Это ж не просто какая-то там хуйня, а целый фреймворк, чтобы одни сервисы могли с другими на высокой скорости, как угорелые, болтать. Удалённый вызов процедур, ёпта, только не на соплях, а на стероидах.
В чём, сука, соль-перец:
- На чём ездит: Всё это безобразие мчится на HTTP/2. Это тебе не старый одноколейный HTTP/1, где запросы в очередь выстраиваются. Тут всё мультиплексируется, фреймы бинарные, заголовки сжатые — красота, а не транспорт, в рот меня чих-пых!
- Контракты и упаковка: А самое главное — никакой этой ерунды с JSON, где половина данных — это кавычки и запятые. Тут всё строго по-взрослому. Пишешь ты на специальном языке, в файлике
.proto, что и как должно выглядеть. А потом волшебный компилятор Protocol Buffers берёт и на всех языках программирования тебе код генерит! И данные сериализуются в бинарник, компактный и быстрый. Никакого лишнего говна. - Потоки, мать их: И не просто "спросил-ответил". Можно и так, конечно. А можно целый поток данных от клиента на сервер отправить, или от сервера клиенту, или вообще в обе стороны сразу, как в чате! Это называется серверный, клиентский и двунаправленный стриминг. Мощь, блядь.
Вот, смотри, как контракт описывается (service.proto):
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc CreateUsers (stream User) returns (CreateUsersResponse); // Поток от клиента
}
message GetUserRequest {
string user_id = 1;
}
message User {
string id = 1;
string name = 2;
string email = 3;
}Видишь? Красота. Написал раз — и у тебя уже есть готовые структуры на Java, Go, Python, C#... Чего душа пожелает. Серверную и клиентскую заглушки тоже сгенерирует. Сиди и бизнес-логику пиши, а не эту ебучую сериализацию с парсингом.
Итог, блядь: Задержки — низкие, пропускная способность — овердохуищная, код пишется в разы быстрее. Поэтому эту технологию и любят в микросервисных архитектурах, где десятки сервисов друг другу мозги выносят. Там, где производительность на первом месте, а не "ой, давайте на JSON'е сделаем, оно human-readable". Human-readable, блядь... Иди читай, когда у тебя лаг в 100 миллисекунд на каждом чихе.