Комментарии 43
Если убрать Protobuf и поддержку в веб-сервисах гугла — получатся обычные веб-сервисы. Поэтому перед тем, как использовать очередной нестандартный стандарт в своем проекте, я бы посоветовал вспомнить про WS и SOAP — если, конечно, серверная часть своя.
Мы тут с коллегой думали думали и придумали.
Гугл засчет написаного ими же бинарного транспорта для протобаф экономят трафик. Простой пример:
структура из 50 флагов. true это бит в бинарном транспорте, а в сжатом xml это все равно чуть больше потому что это в заголовке архива вся строка а дальше флаги по всему архиву.
учитывая что они посылают очень много таких структур в секунду… экономия трафика очевидна…
а морочиться с бинарным транспортом XML им просто не захотелось ну или они посчитали это костылем.
вот и изобрели свое… (это ж еще и маркетинг: «покупай мою шаверму»)
раньше у них не было самого RPC… и люди пользовались сомнительными решениями в своих протобаф-системах… ну теперь все будет энтерпразненько.
Гугл засчет написаного ими же бинарного транспорта для протобаф экономят трафик. Простой пример:
структура из 50 флагов. true это бит в бинарном транспорте, а в сжатом xml это все равно чуть больше потому что это в заголовке архива вся строка а дальше флаги по всему архиву.
учитывая что они посылают очень много таких структур в секунду… экономия трафика очевидна…
а морочиться с бинарным транспортом XML им просто не захотелось ну или они посчитали это костылем.
вот и изобрели свое… (это ж еще и маркетинг: «покупай мою шаверму»)
раньше у них не было самого RPC… и люди пользовались сомнительными решениями в своих протобаф-системах… ну теперь все будет энтерпразненько.
Меня минусуют хипстеры =)
Докера вам с протобафом и шлюхами.
Докера вам с протобафом и шлюхами.
пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC
Видимо, то же самое произошло, когда Google не устроил стандарт OpenCL для Android и родился «самый правильный» стандарт RenderScript.
странные SOAP и .NET RemotingОдин я пропустил букву т?
А есть ли возможность использовать другие варианты транспорта?
Меня, честно говоря, тоже сильно напрягает протокол HTTP/2. Да, я знаю, что за ним будущее. Но после поверхностной оценки RFC для него, мне стало не очень ясно, как впихнуть его поддержку во все популярные языки?
Скажем, для базового уровня поддержки HTTP/1.0 нужна лишь базовая поддержка TCP и работа со строками в минимальном варианте. Это позволяет реализовать его хоть в IoT. С другой стороны, множественные потоки, приоритеты и т.п. ввергают меня в пучину ужаса, при мысли о том, как все это впихнуть в 32КБ памяти. А тот-же gRPC в этой области избавил бы от множества проблем…
Поэтому, также прошу знающих людей разъяснить момент с альтернативным транспортом прикладного уровня.
Скажем, для базового уровня поддержки HTTP/1.0 нужна лишь базовая поддержка TCP и работа со строками в минимальном варианте. Это позволяет реализовать его хоть в IoT. С другой стороны, множественные потоки, приоритеты и т.п. ввергают меня в пучину ужаса, при мысли о том, как все это впихнуть в 32КБ памяти. А тот-же gRPC в этой области избавил бы от множества проблем…
Поэтому, также прошу знающих людей разъяснить момент с альтернативным транспортом прикладного уровня.
Не так уж много нынче устройств с 32КБ на борту, в основном помощнее. А что касается поддержки в языках — понаписывают библиотек для всех. Да в принципе уже понаписывали. Ну, а то, что теперь телнетом к серверу не приконектишься запросик-другой написать, это да, слишком сложно теперь. Но это уж с любой технологией так — либо просто, либо эффективно.
Ну, если из gRPC убрать транспорт — останется голый Protobuf, сериализуйте себе данные на здоровья и гоняйте как хотите.
если убрать транспорт остается еще IDL сервисов
Достаточно примитивненький.
И, кстати говоря, IDL сервисов — формально часть Protobuf
А что на счет отладки?
Сделать запрос из telnet?
Кинуть коллеге запрос «Copy-as-curl»?
Посмотреть сниффером что там ходит по сети?
Научным тыком исследовать плохо (не) документированное API?
Отдельным пунктом:
Одно API для браузера (JS) и всего остального?
Сделать запрос из telnet?
Кинуть коллеге запрос «Copy-as-curl»?
Посмотреть сниффером что там ходит по сети?
Научным тыком исследовать плохо (не) документированное API?
Отдельным пунктом:
Одно API для браузера (JS) и всего остального?
Отладка чего именно? Гугловского транспорта? А как будто вы сейчас можете отладить, что, скажем внутри браузерного XMLHTTPRequest происходит. Вам приходит строка результата — вы её анализируете. А тут будет приходить сразу структура — отлаживайте себе.
Запрос из телнет — нет, никак. Наверняка будет что-то типа конструктора пакетов.
«Copy-as-curl» — я уверен, что в curl добавят поддержку HTTP/2. Ну или форк будет.
«Посмотреть сниффером что там ходит по сети? » — посмотрите на Wireshark c его системой плагинов — расшифровывает всё, что угодно. И для этого будет плагин.
«Научным тыком исследовать плохо (не) документированное API?» — а с протобафом не может быть «плохо документированного API». Если у вас есть proto-файл, то у вас есть все методы, параметры и ответы. Если у вас его нет — вы ничего не сделаете в любом случае.
«Одно API для браузера (JS) и всего остального?» — с приходом в EcmaScript полноценных классов, бинарных буферов, а в браузеры — HTTP/2, вскоре появится и поддержка gRPC.
Запрос из телнет — нет, никак. Наверняка будет что-то типа конструктора пакетов.
«Copy-as-curl» — я уверен, что в curl добавят поддержку HTTP/2. Ну или форк будет.
«Посмотреть сниффером что там ходит по сети? » — посмотрите на Wireshark c его системой плагинов — расшифровывает всё, что угодно. И для этого будет плагин.
«Научным тыком исследовать плохо (не) документированное API?» — а с протобафом не может быть «плохо документированного API». Если у вас есть proto-файл, то у вас есть все методы, параметры и ответы. Если у вас его нет — вы ничего не сделаете в любом случае.
«Одно API для браузера (JS) и всего остального?» — с приходом в EcmaScript полноценных классов, бинарных буферов, а в браузеры — HTTP/2, вскоре появится и поддержка gRPC.
А вы думаете, что методы, параметры и ответы — это документация? Нет, это всего лишь интерфейс (даже не контракт). И в вопросах исследования «методом тыка» текстовые протоколы легче бинарных.
Я не очень понимаю что такое «исследование методом тыка». Если это от начала до конца ваша система — вы сами себе проектируете и документируете интерфейсы как хотите. Если вы используете чей-то публичный API — у него будет описание, иначе это не публичный API, а хрень какая-то. Если вы реверсите чужой трафик между компонентами, куда в теории никто не должен вклиниваться — так это никогда не было простым делом и там всегда была нужна какая-то расшифровка, декомпрессия, дизасамблирование клиента или сервера и т.д.
К сожалению, все далеко не так прекрасно. Публичные API оказываются недодокументированными. От своих собственных API, разработанных год назад, документация утеряна, код нечитаем, разбирайся, как хочешь. Два ближайших интегратора не могут понять формализованное описание и просят примеры, которые они могут запустить через SoapUI/curl. Два других интегратора все «понимают», но шлют фигню, единственный способ разобраться с которой — это поймать ее на лету и посмотреть, что же в ней не так.
Надеюсь, вы сообщили об ошибках в документации авторам?
У них своё виденье «ошибок». К примеру, если C++ код собирается под gcc, но не собирается под винду — они это ошибкой не считают. Точно также не являются ошибкой по их мнению отсутствие в пошаговой инструкции пунктов, которые находятся в других документах (которые могут быть даже в других репозиториях) или пункты, которые написаны туманно, но объясняются в темах на форуме.
Все эти игрушки тупо копируют друг друга вместо того чтобы предлагать киллер-фичи. Что это, что Thrift, что ещё куча rpc не умеют простую вещь — чтобы когда 2 проги соединялись друг с другом можно было дёргать функции и слать сообщения из одной в другую, и неважно, кто из них к кому подцепился — чтобы каждый был и клиентом и сервером. Сейчас такое можно только через гемор с программированием на сокетах иметь, либо AMQP. А вот чтобы both-direction RPC из коробки с сериализацией объектов между экосистемами (C#, Java, ObjC, Javascript, Python, Ruby, C) — есть ли где-то такое вообще?
Да, есть. SOAP over MQ. Или любая другая реализация RPC over MQ.
Киньте ссылкой, пожалуйста, на конкретную реализацию. Потому что тот же Thrift over MQ очень крутая затея, но требующая писать всю имплементацию ручками. Есть что-нибудь уже готовое, чтобы «взял и заюзал»?
У нас своя реализация. Из открытого — вот нашел только что.
gRPC это умеет: «gRPC supports streaming semantics, where either the client or the server (or both) send a stream of messages on a single RPC call. The most general case is Bidirectional Streaming where a single gRPC call establishes a stream where both the client and the server can send a stream of messages to each other. The streamed messages are delivered in the order they were sent.»
Тоже копал в эту сторону. В результате пока сделал обмен через стандартные пайпы ввода-вывода на Java/C++/Pascal Linux/Windows intel/ARM. Но у меня пока синхронный rpc. Делал для простого разделения на процессы, миграции по частям, заворачивания ненадёжных dll в перезапускаемые процессы… Пока в планах стыки на javascript и python. Вообще, дальше в планах добавить к этому shared memory для текущего обрабатываемого пула данных на memory-mapped файлах, чтобы в части случаев не просто сократить передачу данных через пайпы но и вообще избежать её.
Некоторые имплементации JSON-RPC это умеют. А ещё лучше взгляните на WAMP.
вот на WAMP смотреть не надо как раз — из первой версии, идеально простой и понятной, он эволюционировал во вторую — которую мало кто поддерживает и монструозно-непонятную фигню
А чем вторая хуже первой?
И какую альтернативу вы видите?
Требования:
1. Сериализация между C#/.NET, Python, Javascript, PHP, Java, ObjC
2. Двухсторонний RPC между тем, кто подключился, и тем, к кому подключились с киданием засериализованных структур и автоматической десериализацией в нативные структуры.
И какую альтернативу вы видите?
Требования:
1. Сериализация между C#/.NET, Python, Javascript, PHP, Java, ObjC
2. Двухсторонний RPC между тем, кто подключился, и тем, к кому подключились с киданием засериализованных структур и автоматической десериализацией в нативные структуры.
Сегодня же куча реализаций уже есть: wamp.ws/implementations. Монструозность обусловлена только сложностью задачи, потому что WAMP не взваливает огромное количество смежных подзадач на программиста, а решает их сам. К тому же протокол разбит на две части: basic и advanced.
О, вроде похоже на то, что мне надо. Спасибо!
Поясните, пожалуйста, зачем при использование Protobuf использовать HTTP/2 — почему просто не использовать TCP сокет?
А если использовать HTTP/2 зачем Protobuf? Разве я не могу тогда просто все в JSON сериализовать и гонять по HTTP/2 и все будет супер круто сжиматься и прочее…
А если использовать HTTP/2 зачем Protobuf? Разве я не могу тогда просто все в JSON сериализовать и гонять по HTTP/2 и все будет супер круто сжиматься и прочее…
У вас получилось собрать это все в VC++ 2015?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
gRPC — фреймворк от Google для удалённого вызова процедур