proto файлы что это
Использование Google Protocol Buffers (protobuf) в Java
Привет, хабровчане. В рамках курса «Java Developer. Professional» подготовили для вас перевод полезного материала.
Недавно вышло третье издание книги «Effective Java» («Java: эффективное программирование»), и мне было интересно, что появилось нового в этой классической книге по Java, так как предыдущее издание охватывало только Java 6. Очевидно, что появились совершенно новые разделы, связанные с Java 7, Java 8 и Java 9, такие как глава 7 «Lambdas and Streams» («Лямбда-выражения и потоки»), раздел 9 «Prefer try-with-resources to try-finally» (в русском издании «2.9. Предпочитайте try-с-ресурсами использованию try-finally») и раздел 55 «Return optionals judiciously» (в русском издании «8.7. Возвращайте Optional с осторожностью»). Но я был слегка удивлен, когда обнаружил новый раздел, не связанный с нововведениями в Java, а обусловленный изменениями в мире разработки программного обеспечения. Именно этот раздел 85 «Prefer alternatives to Java Serialization» (в русском издании «12.1 Предпочитайте альтернативы сериализации Java») и побудил меня написать данную статью об использовании Google Protocol Buffers в Java.
В разделе 85 «Prefer alternatives to Java Serialization» (12.1 «Предпочитайте альтернативы сериализации Java») Джошуа Блох (Josh Bloch) выделяет жирным шрифтом следующие два утверждения, связанные с сериализацией в Java:
«Лучший способ избежать проблем, связанных с сериализацией, — никогда ничего не десериализовать».
«Нет никаких оснований для использования сериализации Java в любой новой системе, которую вы пишете».
После описания в общих чертах проблем с десериализацией в Java и, сделав эти смелые заявления, Блох рекомендует использовать то, что он называет «кроссплатформенным представлением структурированных данных» (чтобы избежать путаницы, связанной с термином «сериализация» при обсуждении Java). Блох говорит, что основными решениями здесь являются JSON (JavaScript Object Notation) и Protocol Buffers (protobuf). Мне показалось интересным упоминание о Protocol Buffers, так как в последнее время я немного читал о них и игрался с ними. В интернете есть довольно много материалов по использованию JSON (даже в Java), в то время как осведомленность о Protocol Buffers среди java-разработчиков гораздо меньше. Поэтому я думаю, что статья об использовании Protocol Buffers в Java будет полезной.
На странице проекта Google Protocol Buffers описывается как «не зависящий от языка и платформы расширяемый механизм для сериализации структурированных данных». Также там есть пояснение: «Как XML, но меньше, быстрее и проще». И хотя одним из преимуществ Protocol Buffers является поддержка различных языков программирования, в этой статье речь пойдет исключительно про использование Protocol Buffers в Java.
album.proto
Несмотря на простоту приведенного выше определения формата протокола, в нем присутствует довольно много информации. В первой строке явно указано, что используется proto3 вместо proto2, используемого по умолчанию, если явно ничего не указано. Две строки, начинающиеся с option, указывают параметры генерации Java-кода (имя генерируемого класса и пакет этого класса) и они нужны только при использовании Java.
Ключевое слово «message» определяет структуру «Album», которую мы хотим представить. В ней есть четыре поля, три из которых строки (string), а одно — целое число (int32). Два из них могут присутствовать в сообщении более одного раза, так как для них указано зарезервированное слово repeated. Обратите внимание, что формат сообщения определяется независимо от Java за исключением двух option, которые определяют детали генерации Java-классов по данной спецификации.
Сгенерированный Java-класс AlbumProtos.java содержит более 1000 строк, и я не буду приводить его здесь, он доступен на GitHub. Среди нескольких интересных моментов относительно сгенерированного кода я хотел бы отметить отсутствие выражений import (вместо них используются полные имена классов с пакетами). Более подробная информация об исходном коде Java, сгенерированном protoc, доступна в руководстве Java Generated Code. Важно отметить, что данный сгенерированный класс AlbumProtos пока никак не связан с моим Java-приложением, и сгенерирован исключительно из текстового файла album.proto, приведенного ранее.
Прежде чем двигаться дальше, нам понадобится простой Java-класс для демонстрации Protocol Buffers. Для этого я буду использовать класс Album, который приведен ниже (код на GitHub).
Album.java
Создадим экземпляр Album с помощью следующего кода:
Чтение массива byte[] обратно в экземпляр Album может быть выполнено следующим образом:
Здесь мы видим, что в обоих экземплярах соответствующие поля одинаковы и эти два экземпляра действительно разные. При использовании Protocol Buffers, действительно, нужно сделать немного больше работы, чем при «почти автоматическом» механизме сериализации Java, когда надо просто наследоваться от интерфейса Serializable, но есть важные преимущества, которые оправдывают затраты. В третьем издании книги Effective Java («Java: эффективное программирование») Джошуа Блох обсуждает уязвимости безопасности, связанные со стандартной десериализацией в Java, и утверждает, что «Нет никаких оснований для использования сериализации Java в любой новой системе, которую вы пишете».
Смотреть открытый вебинар на тему «gRPC для микросервисов или не REST-ом единым».
Темная сторона protobuf
В среде разработчиков часто бытует мнение, что протокол сериализации protobuf и его реализация — это особая, выдающаяся технология, способная решить все реальные и потенциальные проблемы с производительность одним фактом своего применения в проекте. Возможно на такое восприятие влияет простота применения этой технологии и авторитет самой компании Google.
К сожалению, на одном из проектов мне пришлось вплотную столкнуться с некоторыми особенностями, которые никак не упоминаются в рекламной документации, однако сильно влияют на технические характеристики проекта.
Все последующее изложение касается только реализации protobuf на платформе Java. Также в основном описана версия 2.6.1, хотя в уже выпущенной версии 3.0.0 принципиальных изменений я также не увидел.
Также обращаю факт, что статья не претендует на полноту обзора. Про хорошие стороны технологии (например, это мультиязычность и отличная документация) можно почитать на официальном сайте. Эта статья рассказывает только про проблемы и, возможно, позволит принять более взвешенное решение. Одна часть проблем относится к самому формату, другая часть проблем относится к реализации. Также нужно уточнить, что большинство упомянутых тут проблем проявляются при определённых условиях.
maven-проект с уже подключенными зависимостями для самостоятельного исследования можно взять на github.
0. Необходимость препроцессинга
Это наименьшая проблема, даже не хотел включать ее в перечень, но для полноты пусть будет упомянута. Для того чтобы получить java-код необходимо запустить компилятор protoc. Некоторая проблема есть в том, что этот компилятор представляет собой нативное приложение и на каждой из платформ исполняемый файл будет своим, поэтому обойтись простым подключением maven-плагина не получится. Как минимум нужна переменная окружения на машинах разработчиков и на CI-сервере, которая будет указывать на исполняемый файл, и после этого его уже можно запускать из maven/ant сценария.
Как вариант, можно сделать maven-pluging, который держит в ресурсах все бинарники и распаковывает из себя нужный под текущую платформу в временную папку, откуда и запускает его. Не знаю, может такой кто-то уже и сделал.
В общем, невелик грех, поэтому простим.
1. Непрактичный код
К сожалению, для платформы Java генератор protoc производит очень непрактичный код. Вместо того, чтобы сгенерировать чистенькие anemic-контейнеры и отдельно сериализаторы к ним, генератор упихивает все в один большой класс с подклассами. Генерируемые бины нельзя ни внедрить в свою иерархию, ни даже банально заимплементировать интерфейс java.util.Serializable для спихивания бинов на куда-нибудь сторону. В общем они годятся только в качестве узкоспециализированных DTO. Если вас это устраивает — то это и не проблема вовсе, только не заглядывайте внутрь.
2. Излишнее копирование — низкая производительность
Собственно вот тут у меня начались уже совершенно объективные проблемы. Генерируемый код для каждой описываемой сущности (назовем ее «Bean») создает два класса (и один интерфейс, но он не важен в данном контексте). Первый класс — это immutable Bean который представляет собой read-only слепок данных, второй класс — это mutable Bean.Builder, который уже можно править и устанавливать значения.
Зачем так сделано, осталось непонятным. Кто-то говорит, что авторы входят в секту адептов ФП; кто-то утверждает что так они пытались избавится от циклических зависимостей при сериализации (как это им помогло?); кто-то говорит, что protobuf первой версии работал только с mutable-классами, а глупые люди стреляли при этом себе в ноги.
Можно было бы сказать, что на вкус и цвет архитектуры разные, но при таком дизайне для того чтобы получить байтовое представление вам нужно создать Bean.Builder, заполнить его, затем вызвать метод build(). Для того чтобы изменить бин, нужно создать его билдер через метод toBuilder(), изменить значение и затем вызвать build().
И все ничего, только при каждом вызове build() и toBuilder() происходит копирование всех полей из экземпляра одного класса в экземпляр другого класса. Если все что вам нужно — это получить байтовый массив для сериализации или изменить пару полей, то это копирование сильно мешает. Кроме того, в этом методе похоже (я сейчас выясняю) присутствует многолетняя проблема, которая приводит к тому, что копируются даже те поля, значения которых даже не были установлены в билдере.
Вы вряд ли заметите это, если у вас мелкие бины с небольшим количеством полей. Однако мне в наследство досталась целая библиотека, количество полей в отдельных бинах которой достигало трех сотен. Вызов метода build() для такого бина занимает около 50мкс в моем случае, что позволяет обработать не более 20000 бинов в секунду.
Ирония в том, что в моем случае другие тесты показывают, что сохранение подобного бина через Jackson/JSON в два-три раза быстрее (в случае если проинициализированы не все поля и большую часть полей можно не сериализовать).
3. Потеря ссылочности
Если у вас есть графоподобная структура, в которой бины ссылаются друг на друга, то у меня для вас плохая новость — protobuf не подходит для сериализации таких структур. Он сохраняет бины по-значению, не отслеживая факт того, что этот бин уже был сериализован.
Другими словами если у вас есть bean1 и bean2, которые ссылаются друг на друга, то при сериализации-десериализации вы получите bean1, который ссылается на бин bean3; а также bean2, который ссылается на бин bean4.
Уверен, что в подавляющем большинстве случаев такая функциональность не нужна и даже противопоказана в простых DTO. Однако эта проблема проявляется и в более естественных случаях. Например, если вы добавите один и тот же бин в коллекцию 100 раз, он будет сохранен все 100 раз, а не одиножды. Или вы сериализуете список лотов (товаров). Каждый из лотов представляет собой мелкий бин с описанием (количество, цена, дата), а также со ссылкой на развесистое описание продукта. Если сохранять в лоб, то описание продукта будет сериализовано столько раз, сколько существует лотов, даже если все лоты указывают на один и тот же продукт. Решением этой проблемы будет отдельное сохранение продуктов в виде словаря, но это уже дополнительные действия — и при сериализации, и при десереализации.
Описанное поведение является абсолютно ожидаемым и естественным для текстовых форматов типа JSON/XML. Но вот от бинарного формата ожидаешь несколько другого, тем более, что штатная сериализация Java в этом плане работает ровно так, как и ожидается.
4. Компактность под вопросом
Бытует мнение, что protobuf является суперкомпактным форматом. На самом деле компактность сериализации обеспечивается всего несколькими факторами:
Предположим, приложение генерирует такие данные, что в процентном соотношении в байтовом представлении строки занимают 75%, а примитивы занимают 25%. В таком случае, даже если наш алгоритм оптимизации примитивов сократит необходимое для их хранения место до нуля, мы получим экономию всего в 1/4.
В некоторых случаях компактность сериализация является весьма критичной, например для мобильных приложений в условиях плохой/дорогой связи. В таких случаях без дополнительной компрессии поверх protobuf не обойтись, иначе мы будем впустую гонять избыточные данные в строках. Но тогда вдруг выясняется, что аналогичный комплект [JSON+GZIP] при сериализации дает несильно больший размер по сравнению с [PROTOBUF+ZIP]. Конечно, вариант [JSON+GZIP] будет также потреблять больше ресурсов CPU при работе, но в тоже время, он зачастую также является еще и более удобным.
protoc v3
В protobuf третьей версии появился новый режим генерации «Java Nano». Его еще нет в документации, а runtime этого режима еще в стадии alpha, но пользоваться им можно уже сейчас при помощи переключателя «—javanano_out».
В этом режиме генератор создает анемичные бины с публичными полями (без сеттеров и без геттеров) и с простыми методами сериализации. Лишнего копирования нет, поэтому проблема #2 решена. Остальные проблемы остались, более того при наличии циклических ссылок сериализатор выпадает в StackOverflowError.
Принятие решения о сериализации каждого поля производится на основании его текущего значения, а не отдельной битовой маски, что несколько упрощает сами бины.
protostuff
Альтернативная реализация протокола protobuf. В бою не испытывал, но на первый взгляд выглядит очень добротно. Не требует proto-файлов (однако умеет с ними работать, если это необходимо), поэтому решены проблемы #0, #1 и #2. Кроме этого умеет сохранять в свой собственный формат, а также в JSON, XML и YAML. Также интересной является возможность перегонять данные из одного формата в другой потоком, без необходимости полной десериализации в промежуточный бин.
К сожалению, если отдать на сериализацию обычный POJO без схемы, аннотаций и без proto-файлов (так тоже можно), protostuff будет сохранять все поля объекта подряд, в независимости от того были они проинициализированы значением или нет, а это снова сильно бьет по компактности в случае, когда заполнены не все поля. Но насколько я вижу, такое поведение при желании можно подправить, переопределив пару классов.
Здравствуйте, а что такое Protocol Buffers?
Почему мне стоит использовать эту библиотеку вместо встроенных средств?
Так вы утверждаете, что protobuf не уступает бинарной сериализации и к тому же переносим?
namespace Proto.Sample
<
public enum TaskPriority
<
Low,
Medium,
High
>
[ Serializable ] //
[ProtoContract]
public class Task
<
[ProtoMember(1)]
public int Id
[ProtoMember(2)]
public DateTime CreatedAt
[ProtoMember(3)]
public string CreatedBy
[ProtoMember(4)]
public TaskPriority Priority
using System;
using System.Collections. Generic ;
using System.Diagnostics;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using ProtoBuf;
const string file1 = «tasks1.bin» ;
TestBinaryFormatter(tasks, file1, 1000);
TestBinaryFormatter(tasks, file1, 2000);
TestBinaryFormatter(tasks, file1, 3000);
TestBinaryFormatter(tasks, file1, 4000);
TestBinaryFormatter(tasks, file1, 5000);
const string file2 = «tasks2.bin» ;
TestProtoBuf(tasks, file2, 1000);
TestProtoBuf(tasks, file2, 2000);
TestProtoBuf(tasks, file2, 3000);
TestProtoBuf(tasks, file2, 4000);
TestProtoBuf(tasks, file2, 5000);
for ( var i = 0; i var restoredTasks = ( List )formatter.Deserialize(file);
>
for ( var i = 0; i var restoredTasks = Serializer.Deserialize List >(file);
>
The test of binary formatter:
1000 iterations in 423 ms
2000 iterations in 381 ms
3000 iterations in 532 ms
4000 iterations in 660 ms
5000 iterations in 814 ms
The test of protobuf-net:
1000 iterations in 1056 ms
2000 iterations in 76 ms
3000 iterations in 129 ms
4000 iterations in 152 ms
5000 iterations in 202 ms
The comparision of file size:
The size of tasks1.bin is 710 bytes
The size of tasks2.bin is 101 bytes
var model = TypeModel.Create();
model.Add( typeof (Task), true );
var compiledModel = model.Compile(path);
compiledModel.Serialize(file, tasks);
Остальные тесты и результаты можно посмотреть здесь.
Ок. Относительно скорости и сжатия вы меня убедили, но как решается проблема переносимости?
Понимаете, если существуют реализация для нужной вам платформы, вопрос переносимости в большинстве случаев снимается. А реализациии protobuf существует для более чем 20 языков. Полный список можно увидеть здесь. Отмечу только, что для некоторых языков существует более одной реализации. Так что у вас всегда есть выбор.
Структурированный протокол обмена данных Protobuf или JSON во фронтенде?
В новом проекте в нашей команде мы выбрали frontend framework VUE для нового продукта, бэкенд написан на PHP, и уже как 17 лет успешно работает.
Когда код начал разрастаться, нужно было думать над упрощением обмена данных с сервером, об этом я и расскажу.
Про бэкенд
Проект достаточно большой, и функционал очень замороченный, следовательно код написанный на DDD имел определенные структуры данных, они были сложные и объемные для некой универсальности в проекте в целом.
Про фронтенд
4мес. разработки фронта мы использовали JSON в качестве ответа от сервера, мапили в State Vuex в удобном нам формате. Но для отдачи на сервер нам требовалось преобразовывать в обратную сторону, чтобы сервер смог прочитать и замапить свои DTO объекты (может показаться странным, но так надо 🙂 )
Проблемы
Вроде бы ничего, работали с тем что есть, состояние разрасталось до объектов больших размеров. Начали разбивать на еще меньшие модули в каждом из которых были свои состояния, мутации и т.п… API стало меняться вслед новым задачам от менеджеров, и все сложнее стало управлять всем этим, то там замапили не так, то поля изменились…
И тут мы начали думать об универсальных структурах данных на сервере и фронте чтобы исключить ошибки в парсингах, мапингах и т.п.
После некоторых поисков, мы пришли к двум вариантам:
Хватит болтовни, давайте посмотрим как все это выглядит
Как это выглядит на стороне PHP я не буду описывать, там примерно все тоже самое, объекты те же.
Покажу на примере простого клиентского JS и мини сервера на Node.js.
Для начала описываем структуры данных которые нам потребуется. Дока.
Поясню немного про сервис, зачем он нужен, если даже не используется. Сервис описывается только ради документации в нашем случае, что принимает и что отдает, чтобы мы могли подставлять нужные объекты. Он нужен только для gRPC.
Далее скачивается генератор кода на основании структур.
И запускается команда генерации под JS.
После генерации появляется 3 JS файла, в которых уже все приведено к объектам, с функционалом сериализации в буфер и десериализации из буфера.
price_pb.js
product_pb.js
service_pb.js
Далее описываем уже JS код.
В принципе клиент готов.
На сервере заюзаем Express
Что мы имеем в итоге
Я взял lorem ipsum на 10 абзацев, получилось 5.5кб данных с учетом заполненных объектов Price, Product. И погонял данные по Protobuf и JSON (все тоже самое только заполненные JSON схемы, вместо Protobuf объектов)
Распределенные сервисы с применением gRPC
Что такое gRPC?
gRPC может использовать protobuf в качестве языка для определения интерфейсов и в качестве формата для обмена передаваемыми сообщениями. Он поддерживает многие языки программирования, в частности, Java для Android, C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python и Ruby. Инструментарий для разработки программ (SDK) часто поддерживает реализации, специфичные для конкретного языка. Таким образом, на основе gRPC можно быстро реализовывать распределенные системы или микросервисы, написанные на разных языках – в зависимости от предпочтений разработчиков.
Буферы протоколов
В предыдущем примере показано, как protobuf использует сообщения для структурирования данных. В каждом буфере содержится набор пар вида «имя-значение», и такая пара называется «поле». Следовательно, сообщение, записанное в protobuf, можно воспринимать как своеобразный класс или структуру из языков для объектно-ориентированного программирования.
Теперь давайте скомпилируем определение сообщения из protobuf в соответствующие типы, поддерживаемые в вашем любимом языке программирования. Для этой цели можно скачать на релизной странице GitHub компилятор protoc для работы с protobuf. (https://github.com/protocolbuffers/protobuf/releases/)
Следующая команда для языка C# сгенерирует классы, которые затем можно будет использовать через API буфера протоколов для отправки и получения сообщений.
В нашем примере полученный в результате код C# состоит из:
Кроме того, класс Foo предоставляет методы, связанные с сериализацией и десериализацией. Чтобы отправить и получить сообщение, используйте в коде на C# методы, показанные в следующем примере. В данном случае применяется поток памяти, но на его месте может быть и любой другой поток. Обратите внимание на пакет Google.Protobuf из NuGet: он нужен для считывания из потоков и записи в них.
По спецификации gRPC, protobuf также поддерживает определение интерфейсов. protoc поставляется с дополнительным плагином для генерации клиентского и серверного кода. В следующем примере показан небольшой образец определения интерфейса в gRPC.
Класс ‘FooReflection’, содержащий данные о запросе, содержащемся в protobuf, и о сообщении, получаемом в качестве отклика.
В случае генерации серверного кода:
В случае генерации клиентского кода:
Паттерны коммуникации
В вышеприведенном определении сервиса взаимодействие между клиентом и сервером осуществлялось при помощи унарного метода. Но есть и еще множество способов, которыми могут взаимодействовать по gRPC клиент и сервер.
Клиент отправляет запрос на сервер и получает в ответ единственный отклик
Сервер выдает поток вызовов удаленных процедур (RPC)
Клиент отправляет запрос на сервер и получает поток для считывания последовательности сообщений. В рамках определения интерфейса такой порядок объявляется так: до отклика ставится дополнительное ключевое слово stream.
Клиент выдает поток вызовов удаленных процедур (RPC)
Клиент записывает последовательность сообщений и отправляет их на сервер. Завершив запись, клиент дожидается, пока сервер не прочитает все эти сообщения и не вернет ему отклик. В рамках определения интерфейса такой порядок объявляется так: до запроса ставится дополнительное ключевое слово stream.
Двунаправленные потоковые вызовы удаленных процедур
Обе стороны обмениваются последовательными сообщениями, используя для этого потоки чтения и записи. Оба этих потока независимы. В рамках определения интерфейса такой порядок объявляется так: как до запроса, так и до отклика ставится дополнительное ключевое слово stream.
При использовании gRPC связь может быть разорвана клиентом, разорвана сервером, либо разорвана на основе задержек. Клиент и сервер независимо и локально определяются с тем, в каком состоянии вызов. Таким образом, потоковый вызов может удачно пройти на сервере, но неудачно – на клиенте, из-за задержки. В случае отмены любые изменения, внесенные клиентом или сервером, автоматически не откатываются. Соединение разрывается немедленно. Детали поведения, касающиеся обработки соединения и метаданных, зачастую зависят от языка.
Первое серверное и клиентское приложение на C#
Затем Visual Studio создает проект gRPC-сервера, и мы готовы приступить к делу. Изменив определение интерфейса, основанное на protobuf, и реализовав собственную бизнес-логику внутри сгенерированных файлов, можно завершить работу над нашим gRPC-сервером. Но что при этом происходит за кулисами?
Отметим, что Visual Studio создает для реализации сервера файл protobuf вместе с классом. Но и это еще не все. Файл *.csproj явно ссылается на наш protobuf при помощи тега.
Эта запись приказывает Visual Studio трактовать этот файл как ввод для генерации клиента и сервера gRPC. Свойство GrpcServices указывает, какие части должна сгенерировать Visual Studio.
Вторая важная ссылка внутри файла *csproj-file указывает на пакет Grpc.AspNetCore из NuGet.
Благодаря этому пакету, Grpc.Tools также будет доступен в нашем решении. Grpc.Tools обеспечивает поддержку, необходимую для обработки файлов protobuf при помощи компилятора protoc. При такой простейшей настройке связанный файл protobuf компилируется при каждой сборке, либо, когда это инициируется через запись «Run Custom Tool» (Запустить собственный инструмент) из контекстного меню.
gRPC использует HTTP/2 в качестве протокола передачи данных. Соответственно, нужно сконфигурировать Kestrel (веб-сервер, используемый в ASP.NET Core) при помощи appsettings.json или в Program.cs В следующем примере мы сообщаем всем конечным точкам, что в качестве протокола передачи данных нужно использовать HTTP/2.
В качестве альтернативы можно указать множество конечных точек и для каждой задать свою специфическую конфигурацию. Например, такую настройку можно использовать, когда в одном проекте располагаются REST API и gRPC API, и вы при этом хотите, чтобы REST API использовал для передачи данных протокол HTTP/1.
Обратите внимание: для свойства GrpcServices тега
Для gRPC-клиента регистрируется как переходный в рамках механизма внедрения зависимостей, действующего в ASP.NET Core. Таким образом, клиент легко поддается внедрению и может потребляться в типах, создаваемых методом внедрения зависимостей – например, в контроллерах.
Вот и все, что требуется знать, приступая к созданию ваших первых сервера и клиента, работающих по технологии gRPC и написанных на C#. В конце этой статьи оставлена ссылка на рабочий код полнофункционального примера.
Прежде, чем приступить к написанию клиента на Python, необходимо установить зависимости, относящиеся к gRPC, и сгенерировать заглушки Python для нашего файла protobuf. Требуемые шаги проиллюстрированы в следующих командах:
В результате этого процесса получится два файла:
Наконец, давайте рассмотрим примерную реализацию gRPC-клиента на Python. Мы используем сгенерированные gRPC-заглушки и наш сертификат, чтобы создать простейший тестовый клиент, как показано в следующем листинге:
Заключение
В этой статье я показал вам основы gRPC и показал, как эта технология может использоваться с разными языками программирования. Опираясь на этот материал, вы можете создавать собственные сервисы, между которыми наладится очень эффективная коммуникация.
Подробнее эта тема раскрыта в следующих источниках:
На GitHub выложено полнофункциональное рабочее приложение по материалам этой статьи. В нем отражены клиентские и серверные аспекты, касающиеся коммуникации между сервисами, написанными на разных языках программирования.