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)
5. В чому недоліки існуючих
стандартів?
• Близько ¾ клієнт-серверних стандартів базуються на REST +
HTTP/1.1.
• Основний їх недолік
– неефективність протоколу HTTP/1.1
– нестиснені заголовки, відсутність повноцінного двостороннього
звязку, неефективний підхід до викоричтання ресурсів ОС
– Надлишковий трафік, затримки.
– Необхідність «натягувати» свою модель даних на REST, що
часто є надлишковим
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)
• Згенеровані класи легше використовувати програмно
13. HTTP/2
• HTTP/2 – лежить в основі транспортування даних gRPC.
• Збільшення ефективності використання мережевих ресурсів за
рахунок використання пріоритетів запитів, стиснення заголовків
HTTP та ін.
• Серйозне збільшення продуктивності для сучасних браузерів і
мобільних пристроїв.
• Забезпечення сучасних вимог до безпеки
16. Корисні посилання:
• Офіційний github gRPC:
https://github.com/grpc/grpc
• Документація, інструкції, туторіали, ВСЕ
http://www.grpc.io/docs/
