gRPC;

Совет

Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

До сих пор в этой книге мы сосредоточились на взаимодействии на основе REST. Мы видели, что REST — это гибкий архитектурный стиль, определяющий операции на основе CRUD для ресурсов сущностей. Клиенты взаимодействуют с ресурсами по протоколу HTTP с моделью связи запроса и ответа. В то время как REST широко реализуется, более новая технология коммуникации, gRPC, получила огромный импульс в облачном сообществе.

Что такое gRPC?

gRPC — это современная высокопроизводительная платформа, развивающая протокол вызова удаленной процедуры (RPC). На уровне приложения gRPC упрощает обмен сообщениями между клиентами и внутренними службами. Исходя из Google, gRPC является открытый код и часть экосистемы 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 является упрощенным и высокопроизводительным. Это может быть до 8x быстрее, чем сериализация JSON с сообщениями размером 60–80 % меньше. В parlance Microsoft Windows Communication Foundation (WCF) производительность gRPC превышает скорость и эффективность высокооптимизированных привязок NetTCP. В отличие от NetTCP, которая благоприятует стеку Майкрософт, gRPC является кроссплатформенной.

Protocol Buffers

gRPC охватывает технологию с открытым исходным кодом, называемую буферами протокола. Они предоставляют очень эффективный и нейтральный от платформы формат сериализации для сериализации структурированных сообщений, которые службы отправляют друг другу. Используя кроссплатформенный язык определения интерфейса (IDL), разработчики определяют контракт службы для каждой микрослужбы. Контракт, реализованный в виде текстового .proto файла, описывает методы, входные и выходные данные для каждой службы. Один и тот же файл контракта можно использовать для клиентов и служб gRPC, созданных на разных платформах разработки.

Используя файл proto, компилятор Protobuf, protocсоздает код клиента и службы для целевой платформы. Код включает следующие компоненты:

• Строго типизированные объекты, совместно используемые клиентом и службой, которые представляют операции службы и элементы данных для сообщения.
• Строго типизированный базовый класс с необходимым сетевым сантехникой, наследуемой и расширяющейся службой gRPC.
• Заглушка клиента, содержащая необходимую сантехнику для вызова удаленной службы gRPC.

Во время выполнения каждое сообщение сериализуется как стандартное представление Protobuf и обменивается данными между клиентом и удаленной службой. В отличие от JSON или XML сообщения Protobuf сериализуются как скомпилированные двоичные байты.

Поддержка 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 создает дополнительную конфигурацию как в классе запуска, так и в базовом файле проекта.

Использование gRPC

Пользу gRPC для следующих сценариев:

• Синхронное взаимодействие микрослужбы с микрослужбой, в которой требуется немедленный ответ для продолжения обработки.
• Среды Polyglot, которые должны поддерживать смешанные платформы программирования.
• Низкая задержка и высокая пропускная способность, в которой критически важна производительность.
• Обмен данными в режиме реального времени — 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 веб-покупок и микрослужбами внутренних покупок. Агрегатор получает один запрос от клиента, отправляет его в различные микрослужбы, агрегирует результаты и отправляет их обратно клиенту запроса. Такие операции обычно требуют синхронного взаимодействия для получения немедленного ответа. В eShop внутренние вызовы из агрегатора выполняются с помощью gRPC, как показано на рис. 4-23.

Рис. 4-23. gRPC в eShop on Containers

Для обмена данными gRPC требуются как клиентские, так и серверные компоненты. На предыдущем рисунке обратите внимание, что агрегатор покупок реализует клиент gRPC. Клиент выполняет синхронные вызовы gRPC (красным) для внутренних микрослужб, каждый из которых реализует сервер gRPC. И клиент, и сервер используют встроенные сливки gRPC из пакета SDK для .NET. Заглушки на стороне клиента предоставляют сантехнику для вызова удаленных вызовов gRPC. Компоненты на стороне сервера предоставляют сантехнику gRPC, которую пользовательские классы служб могут наследовать и использовать.

Микрослужбы, предоставляющие КАК API RESTful, так и связь gRPC, требуют нескольких конечных точек для управления трафиком. Вы откроете конечную точку, которая прослушивает HTTP-трафик для вызовов RESTful и другого для вызовов gRPC. Конечная точка gRPC должна быть настроена для протокола HTTP/2, необходимого для связи gRPC.

Хотя мы стремимся разделить микрослужбы с асинхронными шаблонами связи, некоторые операции требуют прямых вызовов. gRPC должен быть основным выбором для прямого синхронного взаимодействия между микрослужбами. Его высокопроизводительный протокол связи, основанный на буферах HTTP/2 и протоколов, делает его идеальным выбором.

Планы на будущее

Заглядывая вперед, gRPC будет продолжать получать тяги к облачным системам. Преимущества производительности и удобство разработки являются убедительными. Тем не менее, REST, скорее всего, будет вокруг в течение длительного времени. Он выделяется для общедоступных API и по причинам обратной совместимости.

НазадДалее