eleks.comeleks.com
Google RPC.
Ще раз про концепцію RPC
• RPC – Remote Procedure Call
• Ідея полягає в передачі керування і даних з
однієї програми в іншу, яка може(і
здебільшого) знаходитись на іншому
фізичному компютері через мережу.
Які технології з забезпеченням RPC
є на даний момент ?
Ось тільки вершина айсберга: (з Вікі)
• Sun RPC (бінарний протокол на базі TCP та UDP)
• Net Remoting (бінарний протокол на базі TCP, UDP, HTTP)
• XML-RPC (текстовий протокол на базі HTTP)
• SOAP — Simple Object Access Protocol (текстовий протокол на
базі HTTP)
• Java RMI — Java Remote Method Invocation
• JSON-RPC JavaScript Object Remote Procedure Calls
(текстовий, на базі HTTP)
Нічого не нагадує? 
В чому недоліки існуючих
стандартів?
• Близько ¾ клієнт-серверних стандартів базуються на REST +
HTTP/1.1.
• Основний їх недолік
– неефективність протоколу HTTP/1.1
– нестиснені заголовки, відсутність повноцінного двостороннього
звязку, неефективний підхід до викоричтання ресурсів ОС
– Надлишковий трафік, затримки.
– Необхідність «натягувати» свою модель даних на REST, що
часто є надлишковим
And Here’s Johnny ! (gRPC)
Protobuf
• Protobuf – це гнучкий, ефективний автоматизований механізм для
серіалізації структурованих даних. (Уявіть собі ХМЛ, але менший,
швидший і простіший)
• Ви визначаєте, як хочете, щоб ваші дані були структуровані один
раз, а потім можете використовувати згенерований код для легкого
зчитування/запису даних, з використанням різних мов
• На даний момент останя версія Protobuf - proto3, в якій є спрощений
синтаксис, деякі корисні нові функції, підтримує багато мов
• Google каже, що protobuf до 10 разів ефективніший, ніж XML-based
протоколи, not bad, а? :))
• Детально про protobuf можна дізнатися тут.
Як працює Protobuf
• Програміст визначає, як він хоче серіалізувати інформацію за
допомогою визначення цього в .proto файлі
• Кожне повідомлення в protocol buffer є логічним записом, який
містить серію пар «ключ-значення»
• Детальний опис синтаксису protobuf – тут
• Після визначення повідомлень, потрібно викликати компілятор
protobuf для .proto файла, який згенерує код на відповідній мові (C#,
C++, Java напр.)
• (!) Можна додавати до повідомлень нові поля без втрати сумісності з
попередніми версіями
І ще раз: XML vs Protobuf
• Простіші (ага )
• Від 3 до 10 разів менший обєм
• Від 20 до 100 разів швидші
• Є менш неоднозначні (мається на увазі чітке визначення типів в
protobuf)
• Згенеровані класи легше використовувати програмно
Приклад
Визначення інтерфейсу сервіса
Що під капотом?
HTTP/2
• HTTP/2 – лежить в основі транспортування даних gRPC.
• Збільшення ефективності використання мережевих ресурсів за
рахунок використання пріоритетів запитів, стиснення заголовків
HTTP та ін.
• Серйозне збільшення продуктивності для сучасних браузерів і
мобільних пристроїв.
• Забезпечення сучасних вимог до безпеки
Конкуренти!
• Так, вони є.
• Головний конкурент – це Apach Thrift
Порівняння:
Корисні посилання:
• Офіційний github gRPC:
https://github.com/grpc/grpc
• Документація, інструкції, туторіали, ВСЕ 
http://www.grpc.io/docs/

G rpc lection1_theory_bkp2

  • 1.
  • 2.
    Ще раз проконцепцію RPC • RPC – Remote Procedure Call • Ідея полягає в передачі керування і даних з однієї програми в іншу, яка може(і здебільшого) знаходитись на іншому фізичному компютері через мережу.
  • 3.
    Які технології ззабезпеченням RPC є на даний момент ? Ось тільки вершина айсберга: (з Вікі) • Sun RPC (бінарний протокол на базі TCP та UDP) • Net Remoting (бінарний протокол на базі TCP, UDP, HTTP) • XML-RPC (текстовий протокол на базі HTTP) • SOAP — Simple Object Access Protocol (текстовий протокол на базі HTTP) • Java RMI — Java Remote Method Invocation • JSON-RPC JavaScript Object Remote Procedure Calls (текстовий, на базі HTTP)
  • 4.
  • 5.
    В чому недолікиіснуючих стандартів? • Близько ¾ клієнт-серверних стандартів базуються на REST + HTTP/1.1. • Основний їх недолік – неефективність протоколу HTTP/1.1 – нестиснені заголовки, відсутність повноцінного двостороннього звязку, неефективний підхід до викоричтання ресурсів ОС – Надлишковий трафік, затримки. – Необхідність «натягувати» свою модель даних на REST, що часто є надлишковим
  • 6.
  • 7.
    Protobuf • Protobuf –це гнучкий, ефективний автоматизований механізм для серіалізації структурованих даних. (Уявіть собі ХМЛ, але менший, швидший і простіший) • Ви визначаєте, як хочете, щоб ваші дані були структуровані один раз, а потім можете використовувати згенерований код для легкого зчитування/запису даних, з використанням різних мов • На даний момент останя версія Protobuf - proto3, в якій є спрощений синтаксис, деякі корисні нові функції, підтримує багато мов • Google каже, що protobuf до 10 разів ефективніший, ніж XML-based протоколи, not bad, а? :)) • Детально про protobuf можна дізнатися тут.
  • 8.
    Як працює Protobuf •Програміст визначає, як він хоче серіалізувати інформацію за допомогою визначення цього в .proto файлі • Кожне повідомлення в protocol buffer є логічним записом, який містить серію пар «ключ-значення» • Детальний опис синтаксису protobuf – тут • Після визначення повідомлень, потрібно викликати компілятор protobuf для .proto файла, який згенерує код на відповідній мові (C#, C++, Java напр.) • (!) Можна додавати до повідомлень нові поля без втрати сумісності з попередніми версіями
  • 9.
    І ще раз:XML vs Protobuf • Простіші (ага ) • Від 3 до 10 разів менший обєм • Від 20 до 100 разів швидші • Є менш неоднозначні (мається на увазі чітке визначення типів в protobuf) • Згенеровані класи легше використовувати програмно
  • 10.
  • 11.
  • 12.
  • 13.
    HTTP/2 • HTTP/2 –лежить в основі транспортування даних gRPC. • Збільшення ефективності використання мережевих ресурсів за рахунок використання пріоритетів запитів, стиснення заголовків HTTP та ін. • Серйозне збільшення продуктивності для сучасних браузерів і мобільних пристроїв. • Забезпечення сучасних вимог до безпеки
  • 14.
    Конкуренти! • Так, вониє. • Головний конкурент – це Apach Thrift
  • 15.
  • 16.
    Корисні посилання: • Офіційнийgithub gRPC: https://github.com/grpc/grpc • Документація, інструкції, туторіали, ВСЕ  http://www.grpc.io/docs/