Bloomrpc что это

Протокол взаимодействия с TINKOFF INVEST API

Вся работа с TINKOFF INVEST API происходит по протоколу gRPC, документацию которого можно найти по ссылке: https://grpc.io/docs/.

Одной из ключевых особенностей протокола следует назвать Bidirectional-stream — это особый режим работы, при котором открывается одно стрим-соединение, отправлять сообщения в которое могут оба участника взаимодействия. Это позволяет более гибко и оперативно реализовать работу. Например, bidirectional-stream сервиса котировок в одном и том же соединении принимает сообщения об изменении статуса подписки и предоставляет различные виды биржевой информации (стаканы, свечи, поток обезличенных сделок и т.д.). Подробнее о данном режиме работы можно ознакомиться в документации протокола.

Авторизация в TINKOFF INVEST API

Для успешной работы с TINKOFF INVEST API требуется передавать токен доступа в metadata каждого запроса.

Формат заголовка: Authorization: Bearer [токен доступа]

Например: Authorization: Bearer t.QtEo8ahkNFX4RTpbqp0u4z4GDZq27HzUp6AotJASBx7_DVqmqZMHfM2Cy7JmUjS80boI9eVg

Адреса сервиса TINKOFF INVEST API

Все вызовы продового сервиса выполняются по адресу invest-public-api.tinkoff.ru:443 .

Все вызовы сервиса песочницы выполняются по адресу sandbox-invest-public-api.tinkoff.ru:443 .

Различия работы контуров описаны на странице.

tracking-id запросов

Во все ответы unary-методов TINKOFF INVEST API добавляется заголовок x-tracking-id. Это уникальный uuid-идентификатор запроса, который необходим технической поддержке для разбора различных инцидентов. При обращении в службу технической поддержки обязательно указывайте tracking-id запроса, это ускорит решение вашего вопроса.

Для сообщений управления статусом подписки в рамках stream-соединений tracking-id передаётся явно в виде выходного параметра.

Полный текст ошибки

В случае ошибки при исполнении методов в TINKOFF INVEST API в ответ добавляется заголовок message. В данном заголовке приходит полный текст описания ошибки.

В Kreya вы можете посмотреть текст ошибки на вкладке Header, в поле message.

Appname запросов

TINKOFF INVEST API позволяет в запросах добавлять служебный заголовок x-app-name, который нужен для сбора статистики по используемым инструментам. Если вы разработчик SDK, рекомендуется использовать app-name формата . . Например, user.tinkoffSDK.

Рекомендации по тестированию методов TINKOFF INVEST API

Для тестирования работы TINKOFF INVEST API можно использовать любой доступный grpc-клиент. Ниже приведены краткие инструкции по настройке двух наиболее популярных из них, а также ссылка на гайд по настройке встроенного gRPS клиента IntelliJ от энтузиаста.

Kreya

Данный бесплатный gRPC-клиент предоставляет довольно широкий набор функциональности и возможностей. Скачать его можно с официального сайта kreya.app.

1. После установки и запуска приложения перейдите в меню Project — Importers.
2. Нажмите New importer. Укажите название источника данных и его тип (gRPC proto files).
3. Нажмите Add proto directory и укажите папку со скаченными proto-контрактами сервиса TINKOFF INVEST API. Вы также можете нажать Add proto files и выбрать ручным способом все proto-файлы из папки. Скачать актуальную версию контрактов можно по ссылке на официальном GitHub: TINKOFF INVEST API.
4. Сохраните изменения и нажмите Back.
5. В левом окне нажмите на появившуюся папку Tinkoff. Укажите Endpoint сервиса: https://invest-public-api.tinkoff.ru:443. Остальные настройки укажите в соответствии со скриншотом. Обратите внимание на блок Metadata, в нём требуется указать заголовок Authorization, в значении которого передаётся строка «Bearer «. Подробнее о том, как получить токен можно узнать по ссылке: Токен доступа
6. Теперь вы можете выполнять запросы к сервису.

Kreya позволяет увидеть служебные заголовки ответа сервера:

• x-ratelimit-limit — показывает текущий лимит пользователя по данному методу.
• x-ratelimit-remaining — количество оставшихся запросов данного типа в минуту.
• x-ratelimit-reset — время в секундах до обнуления счётчика запросов.

Важно!! Если вы получили ошибку «The referenced gRPC method is not imported.», убедитесь, что вы очистили проект в Kreya от прошлых загруженных контрактов. Также всегда проверяйте путь до папки с загружаемыми контрактами, полное наличие всех proto-файлов и их соответствие актуальной версии на официальном GitHub: TINKOFF INVEST API. Изменение proto-файлов повлечет за собой ошибку их прочтения у gRPS-клиентов.

BloomRPC

Скачать данный клиент можно по ссылке: bloomrpc releases.

Интерфейс утилиты достаточно прост, для старта работы требуется указать домен сервиса и импортировать все proto-файлы.

1. Импортируйте скаченные proto-контракты сервиса. Скачать актуальную версию контрактов можно по ссылке на официальном GitHub: TINKOFF INVEST API.
2. Укажите адрес сервера invest-public-api.tinkoff.ru:443 и заполните поле metadata значением (подставьте своё значение токена доступа).

< "Authorization": "Bearer t.QtEo8ahkNFX4RTpbqp0u4z4GDZq27HzUp6AotJASBx7_DVqmqZMHfM2Cy7JmUjS80boI9eVg" > 3. При выполнении запросов следует обязательно указывать тип TLS-подключения: 4. Теперь вы можете выполнять запросы к сервису.

BloomRPC не позволяет увидеть заголовки ответа сервера, поэтому команда TINKOFF INVEST API рекомендует использовать Kreya.

Как насчет тестирования 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.

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

Шаг 2.

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

Шаг 3.

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

Шаг 4.

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

Общее

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

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

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

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

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

Ошибка при тестировании сервиса через bloomRPC

Есть задеплоенный сервис
Он отлично функционирует и локально и на сервере
Локально если я запускаю сервис и хожу к нему через bloomRPC проблем не возникает. Все отрабатывает как надо.
Однако когда я пытаюсь подключиться к сервису, который уже выкачен — возникает ошибка :

Доступ к серверу получается через vpn. Его я включил через openvpn3. Раньше такой ошибки не возникало.

Отслеживать
задан 14 июл 2021 в 9:49
120 1 1 серебряный знак 11 11 бронзовых знаков

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Вероятность 99% что ваша проблема будет заключена с тем, что порт закрыт. В моем случае при деплое в k8s не пробрасывался 82 порт наружу из-за обновленных чартов.

Отслеживать
ответ дан 15 июл 2021 в 11:33
120 1 1 серебряный знак 11 11 бронзовых знаков

• testng
• микросервисы
• grpc

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

gRPC сервер с нуля

Я буду использовать maven для сборки проекта. Это важное уточнение, потому как будущая генерация .proto файлов будет отличаться для gradle например.

Для написания простого приложения на gRPC мы можем использовать всего одну зависимость:

 io.github.lognet grpc-spring-boot-starter 4.5.4 

Отличный Spring Boot стартер для старта нашего gRPC сервера.

После загрузки зависимостей, нам потребуется написать .proto файлы. В proto хранятся описания сервисов и ДТО для запроса/ответа. Все пишется интуитивно понятно:

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

int64 — для Java это тип Long. Допустим id профиля будут long.

string — также как и в Java это строковая переменная.

Отлично у нас есть ДТО для обмена сообщениями. Теперь нам необходим сервис:

gRPC поддерживает несколько видов взаимодействия клиент/сервер:

• Запрос-ответ
• Клиент стрим
• Сервер стрим
• Двунаправленный стрим

Подробнее о таком взаимодействии рассказано тут — https://habr.com/en/post/565020/

После того как у нас есть описанный сервис, нам понадобится сгенерировать необходимые классы. Для этого в pom.xml нам в build секцию потребуется добавить плагин:

   kr.motd.maven os-maven-plugin 1.6.2    org.xolstice.maven.plugins protobuf-maven-plugin 0.6.1 $/src/main/proto $/target/generated-sources/grpc-java com.google.protobuf:protoc:3.12.0:exe:$ grpc-java io.grpc:protoc-gen-grpc-java:1.38.0:exe:$ false    compile compile-custom       

protoSourceRoot — указание директории, где находятся .proto файлы.

outputDirectory — указываем директорию, куда будут генерироваться файлы.

clearOutputDirectory — флаг указывающий не очищать сгенерированные файлы.

После того как вы выполните сборку проекта, можно будет раскрыть папку target и найти следующую структуру:

Если вы получили примерно такую структуру, то поздравляю. Все идет по плану и у нас все получается. Если что то пошло не так, то можно посмотреть на код проекта https://github.com/deft1991/petproject/tree/master/grpc-server.

Итак, мы получили сгенерированные сервисы. Теперь нам необходимо их использовать.

Напишем свой GrpcProfileService, который будет наследовать ProfileServiceGrpc.ProfileServiceImplBase. Прекрасно. У нас готов основной сервис.

Теперь можно переопределять методы, как это сделано на следующем скриншоте :

Можно заметить, что над сервисом стоит аннотация GRpcService. Эта аннотация помечает, что класс должен быть зарегистрирован как gRPC бин.

Вернемся к нашему методу. Пока я переопределил всего 1 метод — метод, который получает профиль. Для ответа клиенту мы используем responseObserver. Что бы сообщение ушло на клиент мы вызываем responseObserver.onNext и передаем тело сообщения. В нашем случае это ProfileDescriptorOuterClass.ProfileDescriptor. У всех сгенерированных сообщений сразу генерируется Builder и при помощи него мы можем “сблидить” объект. После отправки сообщения, необходимо отправить responseObserver.onCompleted — уведомление об успешном завершении стрима.

Для проверки и тестовой отправки сообщений в REST используется обычно Postman. Также с его помощью можно отправить gRPC запросы. Но для меня более удобным является BloomRPC. Ему нужно указать путь к proto файлам и хост, на который отправлять запрос.

При оправке запроса getCurrentProfile мы получим:

Отлично. Давайте двинемся дальше и разберем client stream. При таком типе запросов, клиент может посылать сообщения запросы, а сервер реагировать на каждое из них и/или, при поступлении всех клиентских сообщений, обработать их. В нашем случае предопределенный метод будет выглядеть так:

Мы возвращаем новый StreamObserver клиенту. Так как StreamObserver — это интерфейс, то нам необходимо реализовать его методы. Нас пока интересует метод onNext. В этот метод будут приходить сообщения от клиента. При запуске кода и посылке сообщений от клиента на сервер, можно будет заметить, что счетчик pointCount постоянно увеличивается и в консоль выводится сообщение.

Server stream. В данном типе запросов, после того как клиент послал сообщение запрос, сервер начинает посылать данные для клиента. Это безумно удобный механизм общения между клиентом и сервером. При помощи данной возможности мы можем рассылать клиентам системные уведомления, события и нотификации. Простой код реализации:

После открытия стрима, сервер посылает 5 ответов. В каком последующем ответе найди профиля увеличивается.

После того как мы разобрали стримы с клиента на сервер и сервера на клиент, мы можем приступить к рассмотрению bidirectional streams. В таком типе запросов клиент и сервер могут постоянно обмениваться сообщениями не блокируя друг друга.

В нашем примере в ответ на сообщение клиента, сервер будет посылать новый профиль с увеличенным счетчиком pointCount.

Если у вас возникли сложности с воспроизведением данного примера, то вы можете воспользоваться репозиторием https://github.com/deft1991/petproject/tree/master/grpc-server , где лежит код приведенный в данной статье.

Мы разобрали основные момменты, которые стоит выполнить, что бы написать сервер с использованием gRPC. Посмотрели основные варианты взаимодействия клиента и сервера. Для тестирования я использую BloomRPC.

А вы используете gRPC в проде? Какие у вас ключевые пункты по реализации сервера с использованием gRPC?

Всем приветы. В прошлом посте мы сравнили gRPC и REST. И собственно, прежде чем писать новый сервер на gRPC, давайте попробуем понять нужен ли он нам действительно. Нашей команде была необходима кодогенерация на разные языки программирования. На эту роль неплохо подходил Swagger, Thrift и gRPC со встроенным кодогенератором. От Thrift, спустя какое-то время, пришлось отказаться, из-за его особенностей и сложностей поддержи на c# (по-моему это была основная причина отказа). Дальше был выбор между Swagger + REST и gRPC. В целом оба варианта хороши, но если мы думаем гонять много и часто данные между клиентом и сервером, то почему бы не протестировать gRPC?