Большинство программных приложений должны иметь возможность подключения к другому коду по нескольким причинам. Это может быть что угодно - от интеграции до добавления новой функциональности. Для обеспечения связи программного обеспечения с другими приложениями и его интеграции в другие программы разработчики используют API. Именно поэтому интерфейс прикладного программирования необходим для большинства программ. Благодаря своей роли связующего звена между системами, API позволяют людям получать доступ к различным веб-сервисам. Поэтому важно выбрать подходящую технологию, чтобы предложить API для вашего проекта.
Любая организация, которая хочет поделиться своим приложением или платформой со своими пользователями, должна использовать API. Существует множество способов разработки и тонкой настройки API, чтобы они идеально подходили для вашего приложения. Одним из последних методов, который программисты используют для разработки API, является gRPC. Давайте рассмотрим, что такое gRPC, его плюсы и минусы.
Что такое gRPC?
gRPC означает Google Remote Procedure Call. gRPC - это RPC-фреймворк с открытым исходным кодом, который используется для создания масштабируемых и быстрых API. Он позволяет создавать сетевые системы и обеспечивает открытое взаимодействие между gRPC клиентскими и серверными приложениями. gRPC был принят несколькими ведущими технологическими компаниями, включая Google, IBM, Netflix и другие. Фреймворк gRPC опирается на передовые технологические стеки, такие как HTTP/2, буферы протоколов и многое другое для оптимальной защиты API, высокопроизводительных удаленных вызовов процедур и масштабируемости.
Что такое RPC?
RPC и REST - Representational State Transfer- исторически были двумя разными подходами к созданию API. Кроме того, для этих целей также используются такие протоколы, как SOAP и GraphQL. Удаленные вызовы процедур позволяют писать программное обеспечение так, как будто оно будет выполняться локально, хотя может работать на другом устройстве.
Они являются наиболее традиционно используемой основой для разработки API. В отличие от типичного вызова протокола HTTP, RPC использует вызов функции в качестве основного метода взаимодействия клиента и сервера. RPC является продуктивной техникой для создания API, поскольку обмены просты, а содержание легковесно. gRPC сервисы также имитируют эту коммуникационную архитектуру. RPC использует IDL - Interface Definition Language для контрактации типа данных и методов, которые будут вызываться. Принятые gRPC сервисы от RPC стали очень популярны в последние годы.
Почему были разработаны сервисы gRPC?
По мере того как все больше предприятий открывают каналы для интеграции, становится все труднее связывать такое программное обеспечение. RPC API сложно интегрировать и рискованно распространять, поскольку они могут раскрывать внутреннюю специфику. Они разрабатываются на многих языках программирования и тесно связаны с базовой основой.
Эта проблема была решена, а доступность API повысилась, когда в 2000 году был запущен REST API. В частности, он предоставил пользователям последовательный способ получения информации косвенно через активы с помощью стандартных методов HTTP, таких как GET, PUT, POST и другие. Основное отличие RPC от REST API заключается в том, что в RPC рассматриваются процессы, но нелегко предсказать, какими могут быть процессы в различных системах.
REST API не смог полностью заменить простой и легкий RPC, поскольку он создавал большое количество метаданных, хотя и предлагал усовершенствованный формат для работы со многими приложениями. Это привело к появлению сервисов GraphQL от Facebook и gRPC от Google.
Google создал gRPC в 2015 году как дополнение к фреймворку RPC для соединения многочисленных архитектур микросервисов, созданных с использованием различных техник. gRPC изначально был тесно связан с основной инфраструктурой Google, но в итоге был сделан с открытым исходным кодом и стандартизирован для использования широкой общественностью.
Обзор концепций gRPC
Использование передовых технологий, которые обладают высокой производительностью по сравнению с JSON и XML и обеспечивают большую целостность API, является причиной создания и популярности gRPC. Некоторые из концепций gRPC, о которых вы должны знать, следующие:
Буферы протокола
Буферы протокола, также известные как Protobuf, являются стандартами сериализации или десериализации, которые упрощают определение приложений и автоматически выполняют генерацию кода клиентских библиотек. Последняя версия, proto3, более проста в использовании и предлагает новейшие возможности gRPC.
.Proto Файлы обеспечивают работу сервисов gRPC и обмен между клиентами gRPC и сообщениями сервера. Файл .proto загружается в память при выполнении компилятором Protobuf - protoc. Этот компилятор создает gRPC клиентские и gRPC серверные приложения, которые используют структуру в памяти для сериализации и десериализации двоичных данных. Каждое сообщение отправляется и принимается между пользователем и удаленным сервисом после генерации кода в gRPC.
Поскольку данные переводятся в двоичную форму, а зашифрованные сигналы становятся меньше, разбор с помощью Protobuf использует меньше CPU энергии для gRPC. Поэтому даже на компьютерах со слабым CPU, таких как сотовые телефоны, сообщения отправляются быстрее с помощью gRPC.
HTTP/2
gRPC сервис построен на HTTP/2, версии HTTP/1.1, которая имеет меньше ограничений. Хотя он работает со старым протоколом HTTP, HTTP/2 имеет несколько усовершенствованных функций для gRPC. К ним относится уровень двоичного обрамления, который делит каждый запрос и ответ HTTP/2 на более мелкие сообщения и обрамляет их в двоичный формат для улучшения доставки сообщений. Кроме того, gRPC поддерживает несколько запросов и ответов от клиента и сервера gRPC в двунаправленном полнодуплексном потоке.
HTTP/2 имеет метод управления потоком, который позволяет точно контролировать RAM, необходимое для буферизации пакетов в полете. Он также предлагает сжатие заголовков для gRPC сервисов. В HTTP/2 все шифруется перед передачей, даже заголовки, что обеспечивает высокопроизводительные удаленные вызовы процедур. gRPC обеспечивает как асинхронную, так и синхронную обработку в HTTP/2, позволяя выполнять различные интерактивные и потоковые типы RPC.
Благодаря всем этим характеристикам HTTP/2 сервисы gRPC могут использовать меньше ресурсов, что приводит к ускорению времени отклика облачных приложений и сервисов gRPC и увеличению времени автономной работы клиентов gRPC, работающих на мобильных устройствах.
Потоковая передача
Важнейшей идеей, которую поддерживает gRPC, является потоковая передача, которая позволяет выполнять несколько процессов в рамках одного запроса. gRPC делает это возможным благодаря функции мультиплексирования HTTP/2, которая позволяет одновременно отправлять или получать несколько ответов или запросов через одно TCP - Transmission Control Protocol - соединение. Основными форматами потоковой передачи являются серверные потоковые RPC, клиентские потоковые RPCs и двунаправленные потоковые RPCs.
Каналы
В отличие от потоков HTTP/2, которые допускают множество одновременных потоков на одном соединении запроса, канал gRPC поддерживает несколько непрерывных потоков через несколько запросов. Они используются для создания клиентской заглушки и предоставляют механизм для соединения с сервером gRPC по определенному IP и порту.
gRPC Архитектура
Архитектура gRPC состоит из клиента gRPC и сервера gRPC. Каждый клиентский сервис gRPC содержит заглушку или автоматически генерируемый файл, который является подобием интерфейса, содержащего активные удаленные процессы. Клиент gRPC инициирует вызов локальной процедуры к заглушке, содержащей аргументы, которые должны быть переданы в сообщения сервера gRPC. Затем заглушка клиента gRPC отправляет запрос в локальный блок клиентского времени на локальном компьютере после сериализации аргументов с помощью процедуры Protobuf marshaling.
Операционная система использует протокол HTTP/2 для связи с удаленным серверным компьютером. ОС сервера принимает сообщения и вызывает процесс-заглушку сервера, который использует Protobuf для вызова соответствующей операции после декодирования входящих параметров. Затем клиентский транспортный уровень получает зашифрованный ответ от заглушки сервера. Выполнение возвращается к вызывающей стороне после того, как клиентская заглушка gRPC получает ответные сообщения и разворачивает предоставленные аргументы.
Плюсы gRPC
gRPC имеет ряд преимуществ перед другими механизмами проектирования API. gRPC также улучшает структуру RPC. Вот наиболее заметные преимущества сервисов gRPC:
- Высокопроизводительные удаленные вызовы процедур
Используя Protobuf и HTTP/2, сервисы gRPC обеспечивают в 10 раз более высокую производительность и защиту API по сравнению с взаимодействием REST+JSON. Благодаря использованию подталкивания сервера, мультиплексирования и сжатия заголовков, HTTP/2 обеспечивает высокопроизводительное ранжирование сервисов gRPC. Мультиплексирование позволяет устранить задержку в головной части линии, а server push дает возможность HTTP/2 передавать материал с сервера на клиент до того, как он потребуется. При использовании HTTP/2 сообщения сжимаются более эффективно, что приводит к более быстрой загрузке сервисов gRPC.
- Потоковая передача
Описание услуг для потоковых сервисов gRPC уже включает в себя принципы потокового вещания на стороне клиента или сервера. В результате создание клиентов gRPC и потоковых сервисов значительно упрощается.
- Генерация кода
Генерация кода для gRPC клиентских и gRPC серверных программ является ключевым компонентом gRPC веб-подхода. Для генерации кода из файла .proto модули gRPC используют компилятор .protoc. Формат Protobuf контролируется через генерацию кода в gRPC, который используется для определения форматов данных и конечных точек приложения. Он может создавать сетевые заглушки на стороне клиента и скелеты на стороне сервера, что сокращает время на разработку программ с различными сервисами в gRPC services.
- Интероперабельность
Многочисленные системы и языки программирования, такие как Java, Ruby, Go, C# и другие, поддерживаются ресурсами и библиотеками gRPC. Используя эти языки программирования, разработчики могут создавать производительные приложения, используя полную кросс-платформенную совместимость с gRPC. Это достигается благодаря бинарной форме подключения Protobuf и эффективной генерации кода практически для всех систем.
- Безопасность
Безопасность API обеспечивается в gRPC с помощью HTTP/2 через сквозную зашифрованную сессию TLS. gRPC способствует внедрению SSL/TLS для шифрования данных и аутентификации между сервером и клиентом gRPC.
- Производительность и удобство использования
Поскольку gRPC является полной альтернативой RPC, он работает без проблем на широком спектре систем и языков. gRPC также обладает отличным инструментарием, при этом многие необходимые шаблоны кода генерируются вручную. Инженеры теперь могут больше сосредоточиться на основной функциональности благодаря значительной экономии времени при использовании gRPC.
Минусы gRPC
Хотя мы можем надеяться, что недостатки gRPC со временем будут устранены, они создают некоторые проблемы для его использования сейчас. Некоторые минусы gRPC, о которых вы должны знать, следующие:
- Недостаточная зрелость
Развитие технологии может быть существенным барьером для ее принятия. Это также очевидно при использовании gRPC. GraphQL Один из аналогов gRPC имеет более 14k запросов на StackOverflow, в то время как на gRPC на данный момент только чуть меньше 4k. Сообществу gRPC не хватает знаний о лучших практиках, решениях и успехах, потому что за пределами Google не так много программистов для HTTP/2, а также буферов протокола. Однако, по мере расширения сообщества gRPC и привлечения новых разработчиков, эта ситуация со временем изменится.
- Ограниченная поддержка браузеров
Поскольку ни один из существующих браузеров gRPC не может обрабатывать фреймы HTTP/2, вы не можете эффективно вызывать сервис gRPC из браузера, так как gRPC Web в основном зависит от HTTP/2. В результате вы должны использовать прокси-сервер с gRPC, что имеет ряд недостатков.
- Нечитаемость человеком
В отличие от XML и JSON, файлы Protobuf не читаются человеком, поскольку данные сжимаются до двоичного формата. Разработчики должны использовать дополнительные инструменты, такие как протокол отражения сервера и командная строка gRPC для оценки полезной нагрузки, устранения неполадок и создания ручных запросов.
- Крутая кривая обучения
В отличие от REST и GraphQL, которые в основном используют JSON, потребуется некоторое время, чтобы познакомиться с буферами протокола и открыть для себя методы борьбы с трениями HTTP/2.
Чем поможет AppMaster?
No-code generation меняет представление людей о программировании. No-code generation позволяет людям быстрее обучаться и создавать программное обеспечение благодаря генерации кода. Генерация кода для вашего приложения упрощается с помощью платформ генерации no-code, таких как AppMaster. Здесь также нет проблем с правом собственности, поскольку генерация кода защищена, и созданный вами код будет принадлежать только вам. Вы можете быстрее и проще создавать клиентские и серверные приложения с помощью AppMaster.
No-code платформа AppMaster с функцией кодогенерации позволяет разработчикам использовать протокол gRPC для выполнения запросов между бэкендами микросервисной архитектуры. В следующем году мы расширим поддержку gRPC, включив API как для веб-приложений gRPC, так и для мобильных приложений gRPC.
Заключение
Хотя сервисы gRPC имеют ряд преимуществ, которые делают их привлекательными для предприятий и разработчиков, в конечном итоге решение об использовании сервисов gRPC вместо других, таких как REST или SOAP, зависит от вашего приложения. В то время как некоторые программы получат высокопроизводительные преимущества при использовании gRPC, другим могут больше подойти его альтернативы. Вы должны понять недостатки и преимущества сервисов gRPC и решить, подходит ли он вам.
