The OpenNET Project / Index page

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

Компания Google открыла код gRPC, RPC-фреймворка на основе HTTP/2

26.02.2015 22:28

Компания Google представила новый высокопроизводительный RPC-фреймворк gRPC, позволяющий организовать прозрачное взаимодействие клиентских и серверных приложений. Сетевое взаимодействие в gRPC базируется на применении протокола HTTP/2. gRPC позволяет создавать микросервисы на различных языках программирования, которые взаимодействуют между собой при помощи универсального API. Код фреймворка написан на языке Си и распространяется под лицензией BSD. Обвязки подготовлены для языков C++, Node.js, Python, Ruby, Objective-C, PHP, C#, Go и Java.

Для определения формата передаваемых сообщений и генерации клиентского и серверного кода по умолчанию предлагается использовать язык описания интерфейсов (IDL), предлагаемый инструментарием Protocol Buffers. В дальнейшем планируется обеспечить в gRPC поддержку и других форматов, таких как JSON, Thrift и XML. Поддерживается как синхронная, так и асинхронная обработка запросов. Одновременно с gRPC компания Google представила третью версию протокола сериализации данных Protocol Buffers, в котором среди прочего добавлены новые типы полей и появилась поддержка маппинга в формат JSON. gRPC уже активно применяется в облачных продуктах Google и будет использован для организации доступа к большинству публичных сервисов Google.

Новая система изначально развивалась с оглядкой на высокие требования к масштабируемости и надёжности инфраструктуры Google, обеспечивающей выполнение десятков миллиардов запросов в секунду. Из особенностей gRPC отмечается минимальное время задержки, высокая масштабируемость, возможность использования в распределённых системах, поддержка применения для организации взаимодействия мобильных клиентов с облачными сервисами, независимость от используемых языков программирования, пригодность для использования в приложениях реального времени и в "умных" устройствах, многослойная архитектура, позволяющая подключать в виде расширений новые методы аутентификации, балансировки нагрузки, журналирования и мониторинга.

  1. Главная ссылка к новости (http://googledevelopers.blogsp...)
  2. OpenNews: Google открыл код FlatBuffers, библиотеки для эффективной сериализации данных
  3. OpenNews: Google опубликовал протокол обмена данными "Protocol Buffers"
  4. OpenNews: Введение в систему обмена сообщениями ZeroMQ
  5. OpenNews: HTTP/2.0 получил статус предложенного стандарта
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/41737-grpc
Ключевые слова: grpc, http2
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (40) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Есюки (?), 23:49, 26/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    "Protocol Buffers" == "Protobuf"

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

     
     
  • 2.5, Crazy Alex (ok), 01:21, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Оно, да
     

  • 1.3, anonymous (??), 00:43, 27/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    RPC и IDL в глобальных сетях? Ну-ну.
     
     
  • 2.6, Crazy Alex (ok), 01:24, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что здесь такого? Можно подумать, что нынешние запросы к облачным сервисам - это не RPC. Только обычно - это JSON или HTML-формы без формального описания. асинхронность и ошибки, опять же, все давно обрабатывать научились...
     
     
  • 3.12, anonymous (??), 08:45, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Messages (events) и RPC --- это разные вещи.
     
     
  • 4.18, Аноним (-), 13:37, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да нет, суть одна и та же. Вся разница в обертке.
     
  • 4.22, Crazy Alex (ok), 15:00, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И где ты видел облачные API, основанные на сообщениях? Везде именно RPC, только не формализованный толком - от социалок до интерфейса амазоновских облаков.
     
     
  • 5.27, yet another anonymous (?), 18:17, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кто-нибудь из столь уверенно высказавшихся имел дело с эксплуатацией скажем, CORBA-, based сервиса с неопределенным количеством клиентов? (А еще лучше --- с трафиком выходящим за пределы корпоративной сети).
     
     
  • 6.28, Crazy Alex (ok), 18:28, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, CORBA - это вообще отдельный разговор. Интересно, хоть где-то ещё жив этот монстр? Нынче решения проще на порядок.
     
  • 2.14, Нанобот (ok), 12:09, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    никто не заставляет тебя использовать это в глобальных сетях, не переживай ты так
     

  • 1.4, Аноним (-), 00:52, 27/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > предлагаемый инструментарием Protocol Buffers.

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

     
     
  • 2.7, Crazy Alex (ok), 01:25, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если gRPC уже используется внутри гугла - скорее всего в нём есть какие-то плюсы, нет?
     
     
  • 3.16, Kodir (ok), 12:38, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт. Силовое решение вопроса - не гарантия идеальной системы. Думаете, не силовое? Тогда там сейчас был бы десяток разных сервисных протоколов, включая WCF и Corba.
     
     
  • 4.23, Crazy Alex (ok), 15:02, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То, что гугл - один из технологических лидеров - для меня достаточное основание, чтобы считать, что технические решения там обычно выбираются эффективно.
     
     
  • 5.32, Д.Попов (?), 22:45, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лидер, ха!
    Может быть вы и русским софтом не пользуетесь?
     
     
  • 6.34, Crazy Alex (ok), 04:27, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что такое "русский софт"?

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

     
     
  • 7.35, Аноним (-), 19:50, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    1C же! :) Если не знаешь - повезло, все кто узнал - сгорят в аду :))))
     
  • 6.36, Аноним (-), 19:51, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Лидер, ха!
    > Может быть вы и русским софтом не пользуетесь?

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

     
     
  • 7.45, Анон1 (?), 18:35, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сиди и кури, пёс, если окромя 1С отечественных продуктов в области IT не знаешь
     
  • 2.8, Тот самый с плаката (?), 02:25, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ты когда-нибудь распределённые сетевые приложения писал? При достижении определённой сложности взаимодействия компонентов в коде либо самопроизвольно зарождается свой доморощенный аналог Protobuf (не всегда плохой, просто самописанный), либо выкидываются костыли и берётся Protobuf. Я участвовал в разработке двух таких систем для обмена телеметрией с производств (ничего особенного, просто потоки "событий" и "реакций" на эти события, даже без слишком жёстких требований по времени). Первый раз мы не без проблем выкидывали свои разработки и внедряли Protobuf в срочном порядке, когда на очередную итерацию нам принесли радость в виде необходимости "склеиться" с внешним вендором. К счастью, ребята на том конце были опытные и дружелюбные, помогли и советом, и кодом. Второй раз решили не выпендриваться, и взяли Protobuf сразу же. Оказалось, не зря -- создалась аналогичная ситуация, но на этот раз всё ограничилось обменом парой файлов и сертификатом.

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

     
     
  • 3.9, Аноним (-), 02:40, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.
     
     
  • 4.11, Тот самый с плаката (?), 03:50, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я про то что нафиг они какой-то HTTP/2 достаточно навороченный городили. Могли бы сразу слать протокол буферы свои с какой-нибудь совсем минимальной транспортной обвязкой.

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

     
     
  • 5.13, Аноним (-), 12:02, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > -- это конкретный стандартизованный протокол. Может быть HTTP/2 и можно описать
    > в терминах Protobuf. Но зачем?

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

     
     
  • 6.30, Аноним (-), 22:28, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Скорее, зачем нужен HTTP/2 если есть Protobuf который один фиг натянули на него.

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

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

     
     
  • 7.42, Аноним (-), 20:34, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Protobuf это уровень приложения. HTTP/2 - Транспортный уровень.

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

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

     
  • 4.26, Crazy Alex (ok), 15:13, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что этот HTTP/2 будет скоро везде. И логично сразу на него закладываться. А для RPC чем больше всего жестко стандартизировано - тем меньше потом проблем с интероперабельностью.
     
  • 3.17, Kodir (ok), 12:45, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты когда-нибудь распределённые сетевые приложения писал?

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

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

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

     
     
  • 4.25, Crazy Alex (ok), 15:11, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя ноль усилий для описания формата - значит он не описан и у тебя нет никакой уверенности в том, что он обрабатывается хоть как-то аккуратно. Плюс - у тебя нет готовой документации для него.

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

     
     
  • 5.37, Аноним (-), 19:56, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Не хочешь свои сравнимые (да хрен со сравнимостью - хоть как-то заметные) достижения предъявить?

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

     
  • 4.41, Аноним (-), 20:30, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > JSON over TCP - у меня тоже есть опыт системы,

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

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

     

  • 1.15, Kodir (ok), 12:35, 27/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > ...предлагается использовать язык описания интерфейсов (IDL)

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

     
     
  • 2.19, Аноним (-), 13:39, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > JSON уже умеет сериализовать нативные структуры БЕЗ использования ещё одной точки инконсистентности,
    > так что поделки гугловских студентов идут нафик.

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

     
  • 2.24, Crazy Alex (ok), 15:08, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А потом под этот JSON предлагаешь руками делать обработчике во всех 100500 системах, которые должны понимать твои структуры данных - это, конечно, ни разу не источник неконстистентности и ошибок.

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

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

     
  • 2.29, Нанобот (ok), 20:03, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    вообще-то сериализация в json на порядок медленнее protocol buffers. или на два порядка, если реализация кривая
     
     
  • 3.39, Аноним (-), 20:27, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > вообще-то сериализация в json на порядок медленнее protocol buffers. или на два
    > порядка, если реализация кривая

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

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

     
  • 3.43, Аноним (-), 21:26, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Для сведения порадок это 10 крат, 2 порядка 100 крат, если увас протобаф работает в 100 раз быстрее парсера json то у вас парсер json явно не на си написан.
     
     
  • 4.44, Crazy Alex (ok), 02:18, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы не пытались _большой_ JSON парсить. Там скорость падает как-то совершенно нелинейно обычно
     
  • 2.31, Аноним (-), 22:33, 27/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > JSON уже умеет сериализовать нативные структуры

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


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

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

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

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


     

  • 1.33, Анона (?), 00:01, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня rpc ассоциируется с бэкдорами, благодаря мс...
     
     
  • 2.40, Аноним (-), 20:28, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня rpc ассоциируется с бэкдорами, благодаря мс...

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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