Структура издания

SPL
gRPC: расширенные возможности
Иногда при разработке реальных gRPC-приложений приходится реализовывать дополнительные возможности, такие как перехват входящих и исходящих RPC-сообщений, эластичная обработка сетевых задержек, обработка ошибок, обмен метаданными между сервисами и потребителями и т. д.

В этой главе вы познакомитесь с некоторыми ключевыми расширенными возможностями gRPC: с применением перехватчиков для перехвата RPC-сообщений на серверной и клиентской стороне, использованием крайних сроков для определения времени ожидания вызовов, обработкой ошибок на стороне сервера и клиента с учетом общепринятых рекомендаций. Кроме того, мы рассмотрим запуск нескольких сервисов на одном сервере с помощью мультиплексирования, обмен пользовательскими метаданными между приложениями, балансировку нагрузки и сопоставление имен при вызове других сервисов, а также сжатие RPC-вызовов для эффективного использования пропускной способности сети.
Начнем с обсуждения перехватчиков.
Перехватчики
Иногда перед вызовом удаленной функции на клиентской или серверной стороне или после него нужно выполнить некие рутинные операции. На этот случай gRPC позволяет перехватывать вызов для выполнения таких задач, как ведение журнала, аутентификация, сбор метрик и пр., используя механизм расширения под названием «перехватчик» (interceptor). Установка перехватчиков в клиентском или серверном приложении возможна с помощью предоставленного gRPC простого API. Это один из ключевых способов расширения gRPC, который довольно хорошо подходит для реализации журналирования, аутентификации, авторизации, сбора метрик, трассировки и других потребительских требований.

Перехватчики можно разделить на две категории в зависимости от перехватываемых типов вызовов. В унарном RPC можно использовать унарные перехватчики, а в потоковом — потоковые. Они могут применяться как на серверной, так и на клиентской стороне. Сначала посмотрим, как они работают на стороне сервера.
Серверные перехватчики
В момент вызова клиентом удаленного метода gRPC-сервиса можно выполнить определенную логику, используя серверный перехватчик. Это помогает в ситуациях, когда перед удаленным вызовом, к примеру, нужно провести аутентификацию. Как видно на рис. 5.1, к любому gRPC серверу, который вы разрабатываете, можно подключить один или несколько перехватчиков. Например, чтобы подключить новый серверный перехватчик к сервису OrderManagement, вы можете реализовать перехватчик и зарегистрировать его при создании gRPC-сервера.
Унарные и потоковые перехватчики предназначены для соответствующих видов RPC. Сначала рассмотрим серверные унарные перехватчики.
Унарный перехватчик
Если вы хотите перехватить унарный удаленный вызов на стороне сервера, то вам необходимо реализовать серверный унарный перехватчик. В листинге 5.1

показан фрагмент кода на языке Go, в котором при создании gRPC-сервера реализуется и регистрируется функция типа UnaryServerInterceptor. Это тип серверных унарных перехватчиков со следующей сигнатурой:

Внутри этой функции вы имеете полный контроль над унарными удаленными вызовами, которые получает ваш gRPC-сервер.
Листинг 5.1. Серверный унарный перехватчик в gRPC

1. Перед вызовом: здесь вы можете перехватить сообщение до того, как будет вызван соответствующий удаленный метод.
2. Вызов RPC-метода с помощью UnaryHandler.
3. После вызова: здесь вы можете обработать ответ, сгенерированный в результате удаленного вызова.
4. Возвращение RPC-ответа.
5. Регистрация унарного перехватчика на gRPC-сервере.
Реализацию серверного унарного перехватчика обычно можно разделить на три этапа: предобработки, вызова RPC-метода, постобработки. Как понятно из названия, этап предобработки выполняется до вызова удаленного метода. На этапе постобработки пользователь может получить информацию о текущем RPC-вызове, проанализировав переданные аргументы, такие как контекст (ctx), запрос (req) и состояние сервера. Возможно даже модифицировать RPC-вызов.
Дальше используется обработчик UnaryHandler для вызова удаленного метода. Затем идет этап постобработки, на котором при необходимости можно обработать возвращаемый ответ и сообщение об ошибке; по его окончании вы должны вернуть ответ и сообщение об ошибке в виде параметров функции своего перехватчика. Если постобработка не требуется, то вы можете просто вернуть вызов обработчика (handler(ctx, req)).
Теперь обсудим потоковые перехватчики.
Потоковый перехватчик
Серверные потоковые перехватчики перехватывают любые вызовы потокового RPC, которые приходят на gRPC-сервер. Они состоят из двух этапов: предобработки и перехвата потоковой операции.
Во фрагменте кода на языке Go, показанном в листинге 5.2, перехватываются вызовы потокового RPC, направленные к сервису OrderManagement. Тип StreamServerInterceptor — это тип серверного потокового перехватчика, а orderServerStreamInterceptor — функция данного типа, имеющая следующую сигнатуру:

Как и в унарном перехватчике, этап предобработки позволяет перехватить вызов потокового RPC, пока он не дошел до реализации сервиса. Далее, чтобы завершить выполнение удаленного метода, можно вызвать StreamHandler. После этапа предобработки вы можете перехватить сообщение потокового RPC, воспользовавшись оберткой, реализующей интерфейс grpc.ServerStream. Эту обертку можно передать при вызове grpc.StreamHandler, используя выражение handler(srv, newWrappedStream(ss)). Интерфейс grpc.ServerStream перехватывает потоковые сообщения, отправляемые или принимаемые gRPC-сервисом. Он реализует функции SendMsg и RecvMsg, которые вызываются в момент получения или отправления сервисом сообщения потокового RPC.
Листинг 5.2. Серверный потоковый перехватчик в gRPC

1. Обертка для потока grpc.ServerStream.
2. Реализация функции RecvMsg, принадлежащей обертке; обрабатывает сообщения, принимаемые с помощью потокового RPC.
3. Реализация функции SendMsg, принадлежащей обертке; обрабатывает сообщения, отправляемые с помощью потокового RPC.
4. Создание экземпляра обертки.
5. Реализация потокового перехватчика.
6. Этап предобработки.
7. Вызов метода потокового RPC с помощью обертки.
8. Регистрация перехватчика.
Понять, как потоковый перехватчик ведет себя на серверной стороне, помогут следующие журнальные записи gRPC-сервера. Учитывая порядок, в котором они выводятся, можно проследить действия, выполняемые потоковым перехватчиком. Здесь вызывается удаленный потоковый метод SearchOrders:

В клиентских перехватчиках используется очень похожая терминология, с некоторыми незначительными отличиями, касающимися интерфейсов и сигнатур функций. Поговорим об этом подробно.
Об авторах
Касун Индрасири — архитектор программных систем, имеющий богатый опыт в области микросервисной и облачно-ориентированной архитектур, а также корпоративной интеграции. Занимает должность директора по архитектуре интеграции в WSO2 и отвечает за разработку WSO2 Enterprise Integrator. Касун написал книгу Microservices for Enterprise (Apress, 2018). Кроме того, он выступал на нескольких конференциях, включая O’Reilly Software Architecture Conference 2019 в Сан-Хосе и GOTO Con 2019 в Чикаго, а также на конференции WSO2. Касун живет в Сан-Хосе, штат Калифорния; организовал одну из крупнейших встреч для специалистов по микросервисам в районе залива Сан-Франциско, Silicon Valley Microservices, APIs and Integration.
Данеш Курупу — ведущий разработчик в WSO2, работает в области корпоративной интеграции и микросервисных технологий. Как проектировщик и разработчик он руководит внедрением поддержки gRPC в открытый облачно-ориентированный язык программирования Ballerina. Является участником сообщества и ключевым соавтором таких проектов, как WSO2 Microservices Framework for Java и WSO2 Governance Registry.