URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 101600
[ Назад ]

Исходное сообщение
"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."

Отправлено opennews , 26-Фев-15 23:49 
Компания 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


Содержание

Сообщения в этом обсуждении
"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Есюки , 26-Фев-15 23:49 
"Protocol Buffers" == "Protobuf"

или это что-то другое?


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 01:21 
Оно, да

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено anonymous , 27-Фев-15 00:43 
RPC и IDL в глобальных сетях? Ну-ну.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 01:24 
А что здесь такого? Можно подумать, что нынешние запросы к облачным сервисам - это не RPC. Только обычно - это JSON или HTML-формы без формального описания. асинхронность и ошибки, опять же, все давно обрабатывать научились...

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено anonymous , 27-Фев-15 08:45 
Messages (events) и RPC --- это разные вещи.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 13:37 
Да нет, суть одна и та же. Вся разница в обертке.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 15:00 
И где ты видел облачные API, основанные на сообщениях? Везде именно RPC, только не формализованный толком - от социалок до интерфейса амазоновских облаков.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено yet another anonymous , 27-Фев-15 18:17 
Кто-нибудь из столь уверенно высказавшихся имел дело с эксплуатацией скажем, CORBA-, based сервиса с неопределенным количеством клиентов? (А еще лучше --- с трафиком выходящим за пределы корпоративной сети).

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 18:28 
Ну, CORBA - это вообще отдельный разговор. Интересно, хоть где-то ещё жив этот монстр? Нынче решения проще на порядок.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Нанобот , 27-Фев-15 12:09 
никто не заставляет тебя использовать это в глобальных сетях, не переживай ты так

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 00:52 
> предлагаемый инструментарием Protocol Buffers.

А просто слать по сети вот это вот - им показалось слишком простым, да? :)


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 01:25 
Если gRPC уже используется внутри гугла - скорее всего в нём есть какие-то плюсы, нет?

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Kodir , 27-Фев-15 12:38 
Не факт. Силовое решение вопроса - не гарантия идеальной системы. Думаете, не силовое? Тогда там сейчас был бы десяток разных сервисных протоколов, включая WCF и Corba.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 15:02 
То, что гугл - один из технологических лидеров - для меня достаточное основание, чтобы считать, что технические решения там обычно выбираются эффективно.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Д.Попов , 27-Фев-15 22:45 
Лидер, ха!
Может быть вы и русским софтом не пользуетесь?

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 28-Фев-15 04:27 
А что такое "русский софт"?

Софт, в разработке которого принимали участие разработчики из России - понятно, такого полно. Даже софт, в котором большая часть написана разработчиками из России, вроде nginx - тоже понятно, хотя такого уже очень мало и мне он действительно не нужен. А "русский", "китайский" или "американский" софт - не знаю такого.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 19:50 
1C же! :) Если не знаешь - повезло, все кто узнал - сгорят в аду :))))

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 19:51 
> Лидер, ха!
> Может быть вы и русским софтом не пользуетесь?

В оригинале - "один из технологических лидеров"!
И нравится тебе это или нет - это так. А "руссийсофт" - это стыдоба 1С. Больше ничего нет.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Анон1 , 10-Мрт-15 18:35 
Сиди и кури, пёс, если окромя 1С отечественных продуктов в области IT не знаешь

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Тот самый с плаката , 27-Фев-15 02:25 
Ты когда-нибудь распределённые сетевые приложения писал? При достижении определённой сложности взаимодействия компонентов в коде либо самопроизвольно зарождается свой доморощенный аналог Protobuf (не всегда плохой, просто самописанный), либо выкидываются костыли и берётся Protobuf. Я участвовал в разработке двух таких систем для обмена телеметрией с производств (ничего особенного, просто потоки "событий" и "реакций" на эти события, даже без слишком жёстких требований по времени). Первый раз мы не без проблем выкидывали свои разработки и внедряли Protobuf в срочном порядке, когда на очередную итерацию нам принесли радость в виде необходимости "склеиться" с внешним вендором. К счастью, ребята на том конце были опытные и дружелюбные, помогли и советом, и кодом. Второй раз решили не выпендриваться, и взяли Protobuf сразу же. Оказалось, не зря -- создалась аналогичная ситуация, но на этот раз всё ограничилось обменом парой файлов и сертификатом.

А так да, можно и просто слать по сети. Через lo, например.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 02:40 
Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Тот самый с плаката , 27-Фев-15 03:50 
> Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.

Потому что Protobuf -- это библиотека общего назначения для разработчиков, а HTTP/2 -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать в терминах Protobuf. Но зачем?


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 12:02 
> -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать
> в терминах Protobuf. Но зачем?

Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 22:28 
>Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.

15% пользователей фейсбука считают что никогда не пользовались интернетом.

Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 20:34 
> Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.

Он как-то сильно наворочен для транспортного уровня и занимается кучей всякой дряни, явно не свойственной транспорту.

Ну вон например компрессия заголовков занимается сохранением состояния сессии (синхронные буфера локально и у ремоты же, с перекидыванием только дельты). Это уже ближе к управлению сессией ... при том на уровне приложения. Или вон например мультиплексироваие. Сделали как-то излишне навороченно, имхо.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 15:13 
Потому что этот HTTP/2 будет скоро везде. И логично сразу на него закладываться. А для RPC чем больше всего жестко стандартизировано - тем меньше потом проблем с интероперабельностью.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Kodir , 27-Фев-15 12:45 
> Ты когда-нибудь распределённые сетевые приложения писал?

А ты хочешь выдать за опыт "все обе" своих системы?? Негусто...

Я вот тоже сторонник работы "без наворотов". Протобуф - ни бог весть какое откровение, всего-лишь тупо ЕЩЁ ОДНА библиотечка для сериализации. К тому же, требующая ЕЩЁ ОДИН язык для определения формата и создавая ЕЩЁ ОДНО "слабое звено" в виде отдельного файла, который требуется синхронизировать с нативным кодом. Оно надо?
Гугл - это студота, фик знает по каким критериям нанятая, поэтому нечего на них молиться.

JSON over TCP - у меня тоже есть опыт системы, где мне пришлось делать ровно НОЛЬ усилий для "описания формата", сохраняя при этом гибкость.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 15:11 
Если у тебя ноль усилий для описания формата - значит он не описан и у тебя нет никакой уверенности в том, что он обрабатывается хоть как-то аккуратно. Плюс - у тебя нет готовой документации для него.

А гугл - достаточно хорош технически, чтобы быть в лидерах. Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 19:56 
> Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?

Джентльменам верят на слово ... (С)  Kodir же сказал ...   :)


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 20:30 
> JSON over TCP - у меня тоже есть опыт системы,

Капитан Очевидность намекает что случаи бывают разные. JSON и ProtoBuf весьма разные. Протокольные буфера имеют смысл там где надо быстрый парсинг и компактное представление.

Вон OSMщики как получили XML весом в 250 гигабайтов (!!!) и обнаружили что тулзей для работы с XML такого размера просто не бывает - быстро перешли на .pbf, базированый на protocol buffer'ах.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Kodir , 27-Фев-15 12:35 
> ...предлагается использовать язык описания интерфейсов (IDL)

Извините, ребята, мы это уже проходили - к 19 стандартам добавление 20-го!
JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности, так что поделки гугловских студентов идут нафик.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 13:39 
> JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности,
> так что поделки гугловских студентов идут нафик.

JSON ничего не умеет, это формат, причем текстовый.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 27-Фев-15 15:08 
А потом под этот JSON предлагаешь руками делать обработчике во всех 100500 системах, которые должны понимать твои структуры данных - это, конечно, ни разу не источник неконстистентности и ошибок.

В плане RPC я знаю только один принцип - он может быть любым, но стандартизированным. Есть IDL для формата сериализации - хорошо. Жестко прибит нижележащий протокол - ещё лучше. Четко определено, куда даолжны идти запросы и как они дистпетчеризуются - вообще отлично. Это значит, что это всё не надо будет продумывать самим и потом нарываться на то, что у пратнёров всё не так.

А так - ну я бы сам MsgPack предпочел буферам - но хрен бы с ним, лучше буферы везде, чем нестандартные поделки


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Нанобот , 27-Фев-15 20:03 
вообще-то сериализация в json на порядок медленнее protocol buffers. или на два порядка, если реализация кривая

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 20:27 
> вообще-то сериализация в json на порядок медленнее protocol buffers. или на два
> порядка, если реализация кривая

А еще бинарные данные в нем сереализовать ну вообще сакс.

А так - можете взять .pbf файл от OSMщиков и конвертануть в json. И посмотреть как их 20 гигов превратятся в 100.


"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 21:26 
Для сведения порадок это 10 крат, 2 порядка 100 крат, если увас протобаф работает в 100 раз быстрее парсера json то у вас парсер json явно не на си написан.

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Crazy Alex , 01-Мрт-15 02:18 
Это вы не пытались _большой_ JSON парсить. Там скорость падает как-то совершенно нелинейно обычно

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 27-Фев-15 22:33 
> JSON уже умеет сериализовать нативные структуры

Бумага умеет писать стихи и неплохие, скажу я вам.


> БЕЗ использования ещё одной точки инконсистентности,

Я знаю карате кун-фу тейквандо и еще пару страшных китайских слов.

> так что поделки гугловских студентов идут нафик.

Вы явно не представляете распространенности protobuff. Для затравки: 3% мирового трафика минимум - это сообщения в формате protobuff.



"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Анона , 28-Фев-15 00:01 
У меня rpc ассоциируется с бэкдорами, благодаря мс...

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Отправлено Аноним , 28-Фев-15 20:28 
> У меня rpc ассоциируется с бэкдорами, благодаря мс...

RPC == Remote Procedure Call. И все-таки нечто бэкдорическое в этом есть, по определению :)