A high performance, open source universal RPC framework
gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.
https://grpc.io/
The story behind gRPC
gRPC was initially created by Google, which has used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers for over a decade. In March 2015, Google decided to build the next version of Stubby and make it open source. The result was gRPC, which is now used in many organizations outside of Google to power use cases from microservices to the “last mile” of computing (mobile, web, and Internet of Things).
For more background on why we created gRPC, see the gRPC Motivation and Design Principles on the gRPC blog.
gRPC
Статья от 29.03.2023 Оригинал статьи по ссылке: https://learn.microsoft.com/ru-ru/dotnet/architecture/cloud-native/grpc
В этой статье
Совет
Это содержимое является выдержкой из электронной книги Архитектор облачных собственных приложений .NET для Azure, доступной в документации .NET или в виде бесплатного pdf-файла, который можно читать в автономном режиме.
До сих пор в этой книге мы сосредоточились на взаимодействии на основе REST . Мы видели, что REST — это гибкий архитектурный стиль, определяющий операции на основе CRUD с ресурсами сущностей. Клиенты взаимодействуют с ресурсами по протоколу HTTP с помощью модели обмена запросами и ответами. В то время как REST широко внедряется, новая технология коммуникации gRPC приобрела огромный импульс в сообществе облачных технологий.
Что такое gRPC?
gRPC — это современная высокопроизводительная платформа, развивающая устаревший протокол удаленного вызова процедур (RPC). На уровне приложения gRPC упрощает обмен сообщениями между клиентами и внутренними службами. GRPC, созданная google, является открытый код и частью экосистемы Cloud Native Computing Foundation (CNCF) облачных предложений. CNCF считает gRPC инкубационным проектом. Инкубировать означает, что конечные пользователи используют технологию в рабочих приложениях, а в проекте есть работоспособное количество участников.
Типичное клиентское приложение gRPC предоставляет локальную внутрипроцессную функцию, реализующую бизнес-операцию. Под заголовком эта локальная функция вызывает другую функцию на удаленном компьютере. То, что представляется локальным вызовом, по сути, становится прозрачным внепроцессным вызовом удаленной службы. Сантехника RPC абстрагирует сетевой обмен данными типа “точка— точка”, сериализацию и выполнение между компьютерами.
В облачных приложениях разработчики часто работают на разных языках программирования, платформах и технологиях. Такое взаимодействие усложняет контракты сообщений и сантехнику, необходимую для межплатформенного обмена данными. gRPC предоставляет “равномерный горизонтальный слой”, который абстрагирует эти проблемы. Код разработчиков на собственной платформе ориентирован на бизнес-функции, в то время как gRPC обрабатывает коммуникации.
gRPC предлагает комплексную поддержку в большинстве популярных стеков разработки, включая Java, JavaScript, C#, Go, Swift и NodeJS.
Преимущества gRPC
gRPC использует HTTP/2 для своего транспортного протокола. Несмотря на совместимость с HTTP 1.1, HTTP/2 обладает множеством расширенных возможностей:
- Протокол двоичного кадрирования для передачи данных в отличие от HTTP 1.1, который основан на тексте.
- Поддержка мультиплексирования для отправки нескольких параллельных запросов через одно и то же подключение— HTTP 1.1 ограничивает обработку одним сообщением запроса или ответа за раз.
- Двунаправленное полнодуплексное взаимодействие для одновременной отправки клиентских запросов и ответов сервера.
- Встроенная потоковая передача, позволяющая асинхронно выполнять потоковую передачу больших наборов данных.
- Сжатие заголовков, которое сокращает использование сети.
gRPC является легким и высокопроизводительным. Это может быть в 8 раз быстрее, чем сериализация JSON, при этом сообщения на 60–80 % меньше. В языке Microsoft Windows Communication Foundation (WCF) производительность gRPC превышает скорость и эффективность высокооптимизированных привязок NetTCP. В отличие от NetTCP, который предпочитает стек Майкрософт, gRPC является кроссплатформенным.
Protocol Buffers
gRPC включает технологию с открытым кодом, называемую буферами протоколов. Они обеспечивают высокоэффективный и не зависящий от платформы формат сериализации структурированных сообщений, которые службы отправляют друг другу. С помощью кроссплатформенного языка определения интерфейса (IDL) разработчики определяют контракт службы для каждой микрослужбы. Контракт, реализованный в виде текстового .proto файла, описывает методы, входные и выходные данные для каждой службы. Один и тот же файл контракта можно использовать для клиентов и служб gRPC, созданных на разных платформах разработки.
С помощью файла proto компилятор protocProtobuf создает как клиентский, так и служебный код для целевой платформы. Код включает следующие компоненты:
- Строго типизированные объекты, совместно используемые клиентом и службой, которые представляют операции службы и элементы данных для сообщения.
- Строго типизированный базовый класс с обязательной сетевой сетью, которую может наследовать и расширять удаленная служба gRPC.
- Клиентская заглушка, содержащая необходимую сантехнику для вызова удаленной службы gRPC.
Во время выполнения каждое сообщение сериализуется как стандартное представление Protobuf и обменивается данными между клиентом и удаленной службой. В отличие от JSON или XML, сообщения Protobuf сериализуются как скомпилированные двоичные байты.
Книга gRPC для разработчиков WCF, доступная на сайте архитектуры Майкрософт, содержит подробное описание gRPC и буферов протоколов.
Поддержка gRPC в .NET
gRPC интегрирован в пакет SDK для .NET Core 3.0 и более поздних версий. Поддерживаются следующие средства:
- Visual Studio 2022 с установленной рабочей нагрузкой ASP.NET и веб-разработки
- Visual Studio Code
- Интерфейс командной
dotnetстроки
Пакет SDK включает средства для маршрутизации конечных точек, встроенных средств Интернета вещей и ведения журнала. Веб-сервер Kestrel с открытым кодом поддерживает подключения HTTP/2. На рисунке 4-20 показан шаблон Visual Studio 2022, который формирует каркас проекта для службы gRPC. Обратите внимание, что .NET полностью поддерживает Windows, Linux и macOS.
Рис. 4-20. Поддержка gRPC в Visual Studio 2022
На рисунке 4-21 показана служба gRPC, созданная на основе встроенного формирования шаблонов, включенного в Visual Studio 2022.
Рис. 4-21. Проект gRPC в Visual Studio 2022
На предыдущем рисунке обратите внимание на файл описания proto и код службы. Как вы увидите вскоре, Visual Studio создает дополнительную конфигурацию как в классе Startup, так и в базовом файле проекта.
Использование gRPC
Следует использовать gRPC в следующих сценариях:
- Синхронное взаимодействие между микрослужбами серверной части, где для продолжения обработки требуется немедленный ответ.
- Полиглотовые среды, которые должны поддерживать платформы смешанного программирования.
- Низкая задержка и высокая пропускная способность, где важна производительность.
- Обмен данными между точками в режиме реального времени— gRPC может отправлять сообщения в режиме реального времени без опроса и имеет отличную поддержку двунаправленной потоковой передачи.
- Среды с ограничениями сети — двоичные сообщения gRPC всегда меньше, чем эквивалентные текстовые сообщения JSON.
На момент написания этой статьи gRPC в основном использовался с внутренними службами. Современные браузеры не могут предоставить уровень управления HTTP/2, необходимый для поддержки внешнего клиента gRPC. Тем не более что существует поддержка gRPC-Web с .NET , которая обеспечивает обмен данными gRPC из браузерных приложений, созданных с помощью JavaScript или Blazor WebAssembly технологий. gRPC-Web позволяет ASP.NET Core приложение gRPC для поддержки функций gRPC в приложениях браузера:
- Строго типизированные клиенты, созданные кодом
- Сжатие сообщений Protobuf
- Потоковая передача сервера
Реализация gRPC
В эталонной архитектуре микрослужб eShop on Containers от корпорации Майкрософт показано, как реализовать службы gRPC в приложениях .NET. На рис. 4-22 показана архитектура серверной части.
Рис. 4-22. Архитектура серверной части для eShop в контейнерах
На предыдущем рисунке обратите внимание на то, как eShop охватывает шаблон серверной части для интерфейсов (BFF), предоставляя несколько шлюзов API. Мы обсудили шаблон BFF ранее в этой главе. Обратите особое внимание на микрослужбу агрегатора (серым цветом), которая находится между шлюзом API Web-Shopping и микрослужбами внутренних покупок. Агрегатор получает один запрос от клиента, отправляет его в различные микрослужбы, агрегирует результаты и отправляет их обратно клиенту- запросу. Такие операции обычно требуют синхронного взаимодействия, чтобы получить немедленный ответ. В eShop внутренние вызовы от агрегатора выполняются с помощью gRPC, как показано на рисунке 4-23.
Рис. 4-23. gRPC в eShop в контейнерах
Для обмена данными gRPC требуются как клиентские, так и серверные компоненты. На предыдущем рисунке обратите внимание на то, как агрегатор покупок реализует клиент gRPC. Клиент выполняет синхронные вызовы gRPC (красным цветом) к внутренним микрослужбам, каждая из которых реализует сервер gRPC. Как клиент, так и сервер используют преимущества встроенной сантехники gRPC из пакета SDK для .NET. Заглушки на стороне клиента обеспечивают подключение для вызова удаленных вызовов gRPC. Серверные компоненты обеспечивают возможности gRPC, которые пользовательские классы служб могут наследовать и использовать.
Микрослужбам, предоставляющим как RESTful API, так и обмен данными gRPC, требуется несколько конечных точек для управления трафиком. Необходимо открыть конечную точку, которая прослушивает HTTP-трафик для вызовов RESTful, а другую — для вызовов gRPC. Конечную точку gRPC необходимо настроить для протокола HTTP/2, необходимого для обмена данными gRPC.
Хотя мы стремимся отделить микрослужбы от асинхронных шаблонов связи, некоторые операции требуют прямых вызовов. gRPC должен быть основным выбором для прямого синхронного взаимодействия между микрослужбами. Его высокопроизводительный протокол связи, основанный на HTTP/2 и буферах протокола, делает его идеальным выбором.
Планы на будущее
Заглядывая в будущее, gRPC будет продолжать развиваться для облачных систем. Преимущества производительности и простота разработки являются убедительными. Однако REST, скорее всего, будет использоваться в течение длительного времени. Он отлично подходит для общедоступных API и для обеспечения обратной совместимости.