Как насчет тестирования gRPC?

В этой статье я постараюсь развеять миф о том, что тестировать gRPC сложно и не интересно. Пойдем!

gRPC (удаленные вызовы процедур) — это система удаленного вызова процедур (RPC) с открытым исходным кодом, изначально разработанная в Google в 2015 году. В качестве транспорта используется HTTP/2, а в качестве языка описания интерфейса — протокольные буферы.

По сути, использование RPC — это взаимодействие между микросервисами и построение связи с сервером.

Основные различия между gRPC и REST.

Скорость соединения и поддержка потоков — для меня это главные плюсы.

Между gRPC API и REST есть несколько различий.

Как вариант архитектуры RPC, gRPC был создан Google для ускорения передачи данных между микросервисами и другими системами, которым необходимо взаимодействовать друг с другом. По сравнению с REST API, RPC API уникален в следующем:

• Построен на HTTP 2 вместо HTTP 1.1.

• Protobuf вместо JSON

• Создание собственного кода вместо использования сторонних инструментов, таких как Swagger

• Более длинная реализация, чем REST

• Передача сообщений в 7-10(!) раз быстрее

Глоссарий

• proto file — это формат сообщения, в котором я описываю все методы и сервисы, которые предоставляет этот сервис. Технические характеристики.

• канал — это соединение. по аналогии с host.

• заглушка клиент с методами ответа, просто заглушка.

• Reflection — это функция gRPC, которая позволяет получить список методов или служб для работы на удаленном компьютере. Иногда вы также можете запросить пример сообщения.

БлумRPC. Хорошо для начала.

Перейдем к тестированию. Основным инструментом для тестирования gRPC для меня является BloomRpc. Это достаточно просто и понятно.

Во-первых, вам нужно импортировать прото-файл в bloomRpc. Для этого нажмите на плюсик.

Затем выберите нужный прото-файл и добавьте его. После этого в левом меню появится наш прото файл, в котором есть метод и сервисы.

Нажав на зеленую кнопку запуска, вы фактически отправите запрос. Это просто.

Собственно, на этом основной функционал приложения заканчивается. Больше всего мне кажется, что здесь отсутствует рефлексия. Вы можете попробовать это с помощью приложения от бессонницы. Но об этом мы поговорим позже в следующих статьях.

Отличный способ загрузки.

Я также хочу поделиться довольно быстрым методом нагрузочного тестирования gRPC.

Всегда полезно проверить его на пропускную способность при запуске нового сервиса.

Ведь так мы можем избежать так называемых узких мест нашего сервиса.

В идеале, конечно, хотелось бы, чтобы наши сервисы выдерживали требуемые от них нагрузки и пропускная способность действительно нас удовлетворяла.

Но практика показывает, что так бывает не всегда, и проверка нагрузки с помощью этого инструмента сэкономит вам время и деньги компании.

ГГц

Начнем нагрузочное тестирование gRPC с консольного приложения GHz.

Прямая цитата с сайта GHz:

ghz – это утилита командной строки и пакет Go для нагрузочного тестирования и сравнительного анализа сервисов gRPC. Он предназначен для локального тестирования и отладки сервисов, а также в автоматизированных средах непрерывной интеграции для регрессионного тестирования производительности.

Кроме того, ядро ​​инструмента командной строки реализовано в виде пакета библиотеки Go, который также можно использовать для программной реализации тестов производительности.

Разберем каждый шаг.

Для вызова используется специальная команда - ghz

Шаг 1.

```json

--прото ./мой.прото \

--proto Файл протокольного буфера .proto

Шаг 2.

```java

--call helloworld.my.SayHello \

Полное имя метода в формате «package.Service/method» или «package.Service.Method».

Шаг 3.

```json

-d '{"имя":"Руслан"}' \

-d Данные вызова в строковом формате JSON. Если значение равно '@', то содержимое запроса считывается со стандартного ввода.

Шаг 4.

Укажите адрес. Запуск.

Общее

Пример запроса базового теста на нагрузку выглядит так. Этого будет вполне достаточно для плановой проверки.

```json

ГГц --прото ./мой.прото \

--call helloworld.my.SayHello \

-d '{"имя":"Руслан"}' \

0.0.0.0:3000

После выполнения такой команды будет возвращен ответ. В кате вы можете посмотреть подробные результаты нагрузочного тестирования на нашем протосервисе.

Я также рекомендую вам настроить графику для вашего сервиса, чтобы вы могли сравнить нагрузку от инструмента и производительность вашего сервиса.

Спасибо за ваше время, вот и все.