Компания Google представила (http://googledevelopers.blogspot.ru/2015/02/introducing-grpc...) новый высокопроизводительный RPC-фреймворк gRPC (http://www.grpc.io/), позволяющий организовать прозрачное взаимодействие клиентских и серверных приложений. Сетевое взаимодействие в gRPC базируется на применении протокола HTTP/2 (http://www.opennet.me/opennews/art.shtml?num=41684). gRPC позволяет создавать микросервисы на различных языках программирования, которые взаимодействуют между собой при помощи универсального API. Код фреймворка написан на языке Си и распространяется (https://github.com/grpc/grpc) под лицензией BSD. Обвязки подготовлены для языков C++, Node.js, Python, Ruby, Objective-C, PHP, C#, Go и Java.Для определения формата передаваемых сообщений и генерации клиентского и серверного кода по умолчанию предлагается использовать язык описания интерфейсов (IDL), предлагаемый инструментарием Protocol Buffers. В дальнейшем планируется обеспечить в gRPC поддержку и других форматов, таких как
JSON, Thrift и XML. Поддерживается как синхронная, так и асинхронная обработка запросов. Одновременно с gRPC компания Google представила (https://github.com/google/protobuf/releases) третью версию протокола сериализации данных Protocol Buffers, в котором среди прочего добавлены новые типы полей и появилась поддержка маппинга в формат JSON. gRPC уже активно применяется в облачных продуктах Google и будет использован для организации доступа к большинству публичных сервисов Google.
Новая система изначально развивалась с оглядкой на высокие требования к масштабируемости и надёжности инфраструктуры Google, обеспечивающей выполнение десятков миллиардов запросов в секунду. Из особенностей gRPC отмечается минимальное время задержки, высокая масштабируемость, возможность использования в распределённых системах, поддержка применения для организации взаимодействия мобильных клиентов с облачными сервисами, независимость от используемых языков программирования, пригодность для использования в приложениях реального времени и в "умных" устройствах, многослойная архитектура, позволяющая подключать в виде расширений новые методы аутентификации, балансировки нагрузки, журналирования и мониторинга.URL: http://googledevelopers.blogspot.ru/2015/02/introducing-grpc...
Новость: http://www.opennet.me/opennews/art.shtml?num=41737
"Protocol Buffers" == "Protobuf"или это что-то другое?
Оно, да
RPC и IDL в глобальных сетях? Ну-ну.
А что здесь такого? Можно подумать, что нынешние запросы к облачным сервисам - это не RPC. Только обычно - это JSON или HTML-формы без формального описания. асинхронность и ошибки, опять же, все давно обрабатывать научились...
Messages (events) и RPC --- это разные вещи.
Да нет, суть одна и та же. Вся разница в обертке.
И где ты видел облачные API, основанные на сообщениях? Везде именно RPC, только не формализованный толком - от социалок до интерфейса амазоновских облаков.
Кто-нибудь из столь уверенно высказавшихся имел дело с эксплуатацией скажем, CORBA-, based сервиса с неопределенным количеством клиентов? (А еще лучше --- с трафиком выходящим за пределы корпоративной сети).
Ну, CORBA - это вообще отдельный разговор. Интересно, хоть где-то ещё жив этот монстр? Нынче решения проще на порядок.
никто не заставляет тебя использовать это в глобальных сетях, не переживай ты так
> предлагаемый инструментарием Protocol Buffers.А просто слать по сети вот это вот - им показалось слишком простым, да? :)
Если gRPC уже используется внутри гугла - скорее всего в нём есть какие-то плюсы, нет?
Не факт. Силовое решение вопроса - не гарантия идеальной системы. Думаете, не силовое? Тогда там сейчас был бы десяток разных сервисных протоколов, включая WCF и Corba.
То, что гугл - один из технологических лидеров - для меня достаточное основание, чтобы считать, что технические решения там обычно выбираются эффективно.
Лидер, ха!
Может быть вы и русским софтом не пользуетесь?
А что такое "русский софт"?Софт, в разработке которого принимали участие разработчики из России - понятно, такого полно. Даже софт, в котором большая часть написана разработчиками из России, вроде nginx - тоже понятно, хотя такого уже очень мало и мне он действительно не нужен. А "русский", "китайский" или "американский" софт - не знаю такого.
1C же! :) Если не знаешь - повезло, все кто узнал - сгорят в аду :))))
> Лидер, ха!
> Может быть вы и русским софтом не пользуетесь?В оригинале - "один из технологических лидеров"!
И нравится тебе это или нет - это так. А "руссийсофт" - это стыдоба 1С. Больше ничего нет.
Сиди и кури, пёс, если окромя 1С отечественных продуктов в области IT не знаешь
Ты когда-нибудь распределённые сетевые приложения писал? При достижении определённой сложности взаимодействия компонентов в коде либо самопроизвольно зарождается свой доморощенный аналог Protobuf (не всегда плохой, просто самописанный), либо выкидываются костыли и берётся Protobuf. Я участвовал в разработке двух таких систем для обмена телеметрией с производств (ничего особенного, просто потоки "событий" и "реакций" на эти события, даже без слишком жёстких требований по времени). Первый раз мы не без проблем выкидывали свои разработки и внедряли Protobuf в срочном порядке, когда на очередную итерацию нам принесли радость в виде необходимости "склеиться" с внешним вендором. К счастью, ребята на том конце были опытные и дружелюбные, помогли и советом, и кодом. Второй раз решили не выпендриваться, и взяли Protobuf сразу же. Оказалось, не зря -- создалась аналогичная ситуация, но на этот раз всё ограничилось обменом парой файлов и сертификатом.А так да, можно и просто слать по сети. Через lo, например.
Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.
> Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.Потому что Protobuf -- это библиотека общего назначения для разработчиков, а HTTP/2 -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать в терминах Protobuf. Но зачем?
> -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать
> в терминах Protobuf. Но зачем?Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.
>Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.15% пользователей фейсбука считают что никогда не пользовались интернетом.
Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.
> Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.Он как-то сильно наворочен для транспортного уровня и занимается кучей всякой дряни, явно не свойственной транспорту.
Ну вон например компрессия заголовков занимается сохранением состояния сессии (синхронные буфера локально и у ремоты же, с перекидыванием только дельты). Это уже ближе к управлению сессией ... при том на уровне приложения. Или вон например мультиплексироваие. Сделали как-то излишне навороченно, имхо.
Потому что этот HTTP/2 будет скоро везде. И логично сразу на него закладываться. А для RPC чем больше всего жестко стандартизировано - тем меньше потом проблем с интероперабельностью.
> Ты когда-нибудь распределённые сетевые приложения писал?А ты хочешь выдать за опыт "все обе" своих системы?? Негусто...
Я вот тоже сторонник работы "без наворотов". Протобуф - ни бог весть какое откровение, всего-лишь тупо ЕЩЁ ОДНА библиотечка для сериализации. К тому же, требующая ЕЩЁ ОДИН язык для определения формата и создавая ЕЩЁ ОДНО "слабое звено" в виде отдельного файла, который требуется синхронизировать с нативным кодом. Оно надо?
Гугл - это студота, фик знает по каким критериям нанятая, поэтому нечего на них молиться.JSON over TCP - у меня тоже есть опыт системы, где мне пришлось делать ровно НОЛЬ усилий для "описания формата", сохраняя при этом гибкость.
Если у тебя ноль усилий для описания формата - значит он не описан и у тебя нет никакой уверенности в том, что он обрабатывается хоть как-то аккуратно. Плюс - у тебя нет готовой документации для него.А гугл - достаточно хорош технически, чтобы быть в лидерах. Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?
> Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?Джентльменам верят на слово ... (С) Kodir же сказал ... :)
> JSON over TCP - у меня тоже есть опыт системы,Капитан Очевидность намекает что случаи бывают разные. JSON и ProtoBuf весьма разные. Протокольные буфера имеют смысл там где надо быстрый парсинг и компактное представление.
Вон OSMщики как получили XML весом в 250 гигабайтов (!!!) и обнаружили что тулзей для работы с XML такого размера просто не бывает - быстро перешли на .pbf, базированый на protocol buffer'ах.
> ...предлагается использовать язык описания интерфейсов (IDL)Извините, ребята, мы это уже проходили - к 19 стандартам добавление 20-го!
JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности, так что поделки гугловских студентов идут нафик.
> JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности,
> так что поделки гугловских студентов идут нафик.JSON ничего не умеет, это формат, причем текстовый.
А потом под этот JSON предлагаешь руками делать обработчике во всех 100500 системах, которые должны понимать твои структуры данных - это, конечно, ни разу не источник неконстистентности и ошибок.В плане RPC я знаю только один принцип - он может быть любым, но стандартизированным. Есть IDL для формата сериализации - хорошо. Жестко прибит нижележащий протокол - ещё лучше. Четко определено, куда даолжны идти запросы и как они дистпетчеризуются - вообще отлично. Это значит, что это всё не надо будет продумывать самим и потом нарываться на то, что у пратнёров всё не так.
А так - ну я бы сам MsgPack предпочел буферам - но хрен бы с ним, лучше буферы везде, чем нестандартные поделки
вообще-то сериализация в json на порядок медленнее protocol buffers. или на два порядка, если реализация кривая
> вообще-то сериализация в json на порядок медленнее protocol buffers. или на два
> порядка, если реализация криваяА еще бинарные данные в нем сереализовать ну вообще сакс.
А так - можете взять .pbf файл от OSMщиков и конвертануть в json. И посмотреть как их 20 гигов превратятся в 100.
Для сведения порадок это 10 крат, 2 порядка 100 крат, если увас протобаф работает в 100 раз быстрее парсера json то у вас парсер json явно не на си написан.
Это вы не пытались _большой_ JSON парсить. Там скорость падает как-то совершенно нелинейно обычно
> JSON уже умеет сериализовать нативные структурыБумага умеет писать стихи и неплохие, скажу я вам.
> БЕЗ использования ещё одной точки инконсистентности,Я знаю карате кун-фу тейквандо и еще пару страшных китайских слов.
> так что поделки гугловских студентов идут нафик.
Вы явно не представляете распространенности protobuff. Для затравки: 3% мирового трафика минимум - это сообщения в формате protobuff.
У меня rpc ассоциируется с бэкдорами, благодаря мс...
> У меня rpc ассоциируется с бэкдорами, благодаря мс...RPC == Remote Procedure Call. И все-таки нечто бэкдорическое в этом есть, по определению :)