Проблема

Когда мы разрабатываем приложение, которое разделено на независимые автономные компоненты, мы говорим о микросервисной архитектуре. Для взаимодействия компонентов используется API. Самый популярным API является REST. Это обусловлено его гибкостью, эффективностью (в большинстве сценариев) и тем, что он легко масштабируется. 

Большая часть реализаций REST использует стандарт JSON для обмена сообщениями. Обычно это удобно - сама по себе такая структура легко читается людьми и предоставляет независимость от языка программирования.

Недостатками такого решения является избыточность данных и сущностей из которых состоит запрос. В большинстве случаев это некритично. Проблемы начинаются в сценариях, когда нужно передавать много данных с низкой задержкой.

Зачем нужен gRPC

gRPC (Remote Procedure Calls) — это система удалённого вызова процедур (RPC) с открытым исходным кодом, первоначально разработанная в Google. В качестве основного протокола передачи применяется HTTP/2, для описания процедур применяется “Protocol Buffers”. Это в свою очередь приносит дополнительные преимущества: сжатие HTTP-заголовков и мультиплексирование запросов.

gRPC предполагает возможность аутентификации, потоковой передачи данных в любую сторону, управление потоками, отмену и time-out запросов, при этом выделяется кроссплатформенностью за счет генерации исходного кода классов для всех популярных языков программирования. 

Когда использовать gRPC

Статистика говорит о том, что gRPC используется гораздо реже, чем REST. К сожалению, часто только из-за этого разработчики выбирают REST. И если в небольших проектах это оправдано, тогда напрашивается вопрос: в каких случаях правильным выбором всё же будет gRPC?

Стоит взглянуть на таблицу их основных отличий.

Хотя REST подход также может использовать HTTP 2 для обмена данными, тем не менее он будет ограничен моделью запрос-ответ, при которой не применяется поддержка двусторонней потоковой передачи данных возможной для HTTP При этом, конечно же сохраняется возможность унарных взаимодействий, которые реализует HTTP 1.1 (один запрос - один ответ).

В конечном итоге мы получаем более высокую скорость ответа в разных сценариях.

При этом в gRPC наименования полей, ожидаемых запросов и возвращаемых ответов определяется и описывается в одном месте - в файле .proto. И если вы хотя бы раз разрешали конфликты в наименовании полей вида ObjectID и object_id, то вам определенно понравится работать с gRPC.

Пример .proto файла:

syntax = "proto3";

/* Наименование пакета данных */

message Calculator {

    int32 xxx = 1;

    int32 yyy = 2;

}

message CalculatorRequest {

    Calculator calculator = 1;

}

message CalculatorResponse {

    int32 result = 1;

}

Когда не использовать gRPC

gRPC при всех своих достоинствах не лишен недостатков. Вот парочка:

• Использование HTTP/2 в gRPC, что делает невозможным реализацию клиента gRPC в браузере - вместо этого приходится использовать прокси. 

• Более сложная отладка по сравнению с REST из-за бинарного обмена сообщениями

Реальный кейс

Как упоминалось выше, для работы с gRPC достаточно одного .proto файла.

Мы делали реализацию API на Python, где использовали дуплексное (двунаправленное соединение) для сервиса потокового распознавания речи в текст.

Дуплексное соединение gRPC на Python:

def stream_recorder(self) -> Union[RecognitionRequest, str]:

    """Потоковый захват речи"""

    for _ in range(0, int(self.rate / self.chunk * self.seconds)):

        data = self.stream.read(self.chunk, exception_on_overflow=False)

        yield RecognitionRequest(audio=data)

def stream_recognize(self) -> str:

    """Потоковое распознавание речи"""

    credentials = grpc.ssl_channel_credentials()

    with grpc.secure_channel(f'{settings.SPEECH_SERVER}:{settings.SPEECH_PORT}',

                            credentials=credentials) as chennel:

        stub = VoiceAssistantServiceStub(chennel)

        metadata = [('authorization', f'Bearer {settings.SPEECH_API_TOKEN}'), ('audioformat', 'lpcm')]

        for response in stub.RecognizeAudio(self.stream_recorder(), metadata=metadata):

            if response.chunks[0].final:

                return response.chunks[0].text.strip()

Эти декларативные преимущества gRPC работают не только в момент написания кода. Особенно удобно делать отладку соединения в Postman, который предоставляет поддержку протокола. 

Даже не имея доступа к удаленному серверу мы можем имитировать запросы с моковыми данными и эмулировать ответ нажатием одной кнопки.

Выводы

В отличие от REST, gRPC - решение, которое не зависит от платформы и языка. И благодаря HTTP/2 и протоколу Protobuf решает проблемы, связанные со скоростью передачи данных, их весом, в результате повышая эффективность обмена сообщениями.