gRPC

Современные приложения редко работают в изоляции. Большинство из них общаются друг с другом по сети и координируют свои действия, обмениваясь сообщениями. Таким образом, современная программная система представ- ляет собой набор распределенных приложений, которые работают на разных участках сети и взаимодействуют с помощью различных коммуникационных протоколов. Микросервисы должны связываться друг с другом по сети, используя методики межпроцессного (межсервисного, межпрограммного) взаимодействия (inter-process communication, IPC). Межпроцессное взаимодействие обычно реализуется путем обмена сообще- ниями в асинхронном стиле (на основе запросов и ответов или событийной модели). При асинхронном событийном подходе процессы обмениваются асинхронными сообщениями, используя посредника, известного как брокер событий. Часто возникает необходимость в хорошо масштабируемой технологии IPC со слабой связанностью, которая была бы более эффективной по сравнению с REST. Именно эту роль берет на себя gRPC — современный стиль межпроцессного взаимодействия для создания распределенных приложений и микросервисов. gRPC в основном использует синхронные запросы и ответы, но вместе с тем имеет полностью асинхронный или потоковый режим, доступный после установления соединения. При разработке gRPC-приложения первым делом нужно определить ин- терфейс сервисов. Данное определение содержит информацию о том, как потребители могут обращаться к вашим сервисам, какие методы можно вызывать удаленно, какие параметры и форматы сообщений следует при- менять при вызове этих методов и т. д. Язык, который используется в спецификации сервиса, называется языком описания интерфейсов (interface definition language, IDL). На основе спецификации сервиса можно сгенерировать серверный код (или серверный каркас), который упрощает создание логики на серверной сто- роне за счет предоставления абстракций для низкоуровневого взаимодействия. Вы также можете сгенерировать клиентский код (или клиентскую заглушку), инкапсулирующий низкоуровневые аспекты коммуникационного протоко- ла в разных языках программирования. Методы, указанные в определении интерфейса сервиса, можно вызывать удаленно на клиентской стороне по примеру того, как вызываются локальные функции. Внутренний фреймворк gRPC возьмет на себя все сложные аспекты, присущие соблюдению строгих контрактов между сервисами, сериализации данных, сетевых коммуникаций, аутентификации, контролю доступа, наблюдаемости и т. д. Допустим,мы занимаемся разработкой приложения для розничной торговли, состоящего из нескольких микросервисов, и хотим, чтобы один из них возвращал описание товаров, доступных для продажи Определение сервиса находится в файле ProductInfo.proto, который исполь- зуется для генерации кода как на серверной, так и на клиентской стороне. Сетевое взаимодействие обоих объектов происходит по HTTP/2. **Определение сервиса** В качестве IDL для определения интерфейса сервисов gRPC использует Protocol Buffers— расширяемый механизм сериализации структурированных данных, который не зависит от языка и платформы. Определение интерфейса сервиса хранится в proto- файле — обычном текстовом файле с расширением .proto.