tg-me.com/eshu_coding/181
Last Update:
Палантир. Часть 1. Начинаю серию постов по изученным мной в процессе разработки сборщика данных с телеграма техническим нюансам.
#палантир@eshu_coding
Как уже было сказано, мной используется схема master - slave. Для связи между ними вместо традиционных http запросов я использую gRPC.
Суть технологии в следующем в файлах с расширениями .proto описываются основные точно взаимодействия элементов приложения и используемые структуры данных.
Видов взаимодействия может быть четыре:
1. Одиночный вызов. Клиент стучит на сервер, закидывает туда данные в описанном формате, получает ответ заданного формата.
Остальное - варианты стримминга. Доступны следующие варианты:
А) Клиент шлет одиночный запрос, в ответ получает поток ответов.
Б) Клиент отправляет на сервер поток сознания, получает одиночный ответ.
В) Клиент отправляет поток сознания и получает поток в ответ.
Все эти режимы работы, а также формат отдельных сообщений прописан в .proto файле.
gRPC - мультиязычная платформа, что крайне удобно для связи сервисов, написанных на разных языках. Структуры данных, описанные в протофайле, доступны для использования как обычные классы.
В случае с# и node.js достаточно добавить в проект протофайл и можно пользоваться этими структурами. В питоне нужно отдельной командой сгенерировать питоновские файлы, в которых будут автогенерированные классы, описанные в протобуфе.
Чем еще хороша gRPC? Во-первых - удобство. Описал взаимодействие всех компонентов и гоняй стандартизированные структуры данных через стандартизированные API туда-сюда. Многие ошибки отваливаются на этапе сборки проектов.
Во вторых - стримминг и подписка на события реализуется просто и без боли.
В третьих grpc тупо шустрее обычных http запросов: от 20% до 7-10 раз, вот одна из статей с замерами.
В общем, годная технология, но наверняка есть и подводные камни.
#кодинг
BY Эшу быдлокодит
Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283
Share with your friend now:
tg-me.com/eshu_coding/181