The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от opennews on 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.ru/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.ru/opennews/art.shtml?num=41737

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 01:21 
Оно, да
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  –3 +/
Сообщение от anonymous (??) on 27-Фев-15, 00:43 
RPC и IDL в глобальных сетях? Ну-ну.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 01:24 
А что здесь такого? Можно подумать, что нынешние запросы к облачным сервисам - это не RPC. Только обычно - это JSON или HTML-формы без формального описания. асинхронность и ошибки, опять же, все давно обрабатывать научились...
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от anonymous (??) on 27-Фев-15, 08:45 
Messages (events) и RPC --- это разные вещи.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

18. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Аноним (??) on 27-Фев-15, 13:37 
Да нет, суть одна и та же. Вся разница в обертке.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 15:00 
И где ты видел облачные API, основанные на сообщениях? Везде именно RPC, только не формализованный толком - от социалок до интерфейса амазоновских облаков.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

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

28. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 18:28 
Ну, CORBA - это вообще отдельный разговор. Интересно, хоть где-то ещё жив этот монстр? Нынче решения проще на порядок.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

14. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Нанобот (ok) on 27-Фев-15, 12:09 
никто не заставляет тебя использовать это в глобальных сетях, не переживай ты так
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  –1 +/
Сообщение от Аноним (??) on 27-Фев-15, 00:52 
> предлагаемый инструментарием Protocol Buffers.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 01:25 
Если gRPC уже используется внутри гугла - скорее всего в нём есть какие-то плюсы, нет?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

16. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Kodir (ok) on 27-Фев-15, 12:38 
Не факт. Силовое решение вопроса - не гарантия идеальной системы. Думаете, не силовое? Тогда там сейчас был бы десяток разных сервисных протоколов, включая WCF и Corba.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

23. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 15:02 
То, что гугл - один из технологических лидеров - для меня достаточное основание, чтобы считать, что технические решения там обычно выбираются эффективно.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

32. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  –1 +/
Сообщение от Д.Попов on 27-Фев-15, 22:45 
Лидер, ха!
Может быть вы и русским софтом не пользуетесь?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

34. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Crazy Alex (ok) on 28-Фев-15, 04:27 
А что такое "русский софт"?

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Аноним (??) on 28-Фев-15, 19:50 
1C же! :) Если не знаешь - повезло, все кто узнал - сгорят в аду :))))
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

45. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Анон1 on 10-Мрт-15, 18:35 
Сиди и кури, пёс, если окромя 1С отечественных продуктов в области IT не знаешь
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Аноним (??) on 27-Фев-15, 02:40 
Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

26. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 15:13 
Потому что этот HTTP/2 будет скоро везде. И логично сразу на него закладываться. А для RPC чем больше всего жестко стандартизировано - тем меньше потом проблем с интероперабельностью.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

41. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Аноним (??) on 28-Фев-15, 20:30 
> JSON over TCP - у меня тоже есть опыт системы,

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

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

24. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  –1 +/
Сообщение от Crazy Alex (ok) on 27-Фев-15, 15:08 
А потом под этот JSON предлагаешь руками делать обработчике во всех 100500 системах, которые должны понимать твои структуры данных - это, конечно, ни разу не источник неконстистентности и ошибок.

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

29. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Нанобот (ok) on 27-Фев-15, 20:03 
вообще-то сериализация в json на порядок медленнее protocol buffers. или на два порядка, если реализация кривая
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

43. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Аноним (??) on 28-Фев-15, 21:26 
Для сведения порадок это 10 крат, 2 порядка 100 крат, если увас протобаф работает в 100 раз быстрее парсера json то у вас парсер json явно не на си написан.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

44. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Crazy Alex (ok) on 01-Мрт-15, 02:18 
Это вы не пытались _большой_ JSON парсить. Там скорость падает как-то совершенно нелинейно обычно
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

31. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +1 +/
Сообщение от Аноним (??) on 27-Фев-15, 22:33 
> JSON уже умеет сериализовать нативные структуры

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


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

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

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

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


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

33. "Компания Google открыла код gRPC, RPC-фреймворка на основе H..."  +/
Сообщение от Анона on 28-Фев-15, 00:01 
У меня rpc ассоциируется с бэкдорами, благодаря мс...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру