Проектирование gRPC-сервиса
В поддержку моего нового курса по архитектуре информационных систем Дизайн API, сегодня я покажу принципы и последовательность проектирования gRPC-сервиса на примере системы работы с поставщиками.
Еще раз о gRPC: краткий ликбез
В последнее время gRPC как технология интеграции информационных систем становится все более популярной. Этот фреймворк и протокол удалённого вызова процедур (Remote Procedure Calls) предложены компанией Google в 2015 году. Одним из главных достоинств gRPC считается скорость, которая обеспечивается благодаря следующим факторам:
- быстрый протокол HTTP/2 в качестве транспорта данных, который обеспечивает мультиплексирование, более эффективное сжатие заголовков запросов и ответов, а также двунаправленную потоковую передачу;
- бинарный формат сериализации полезной нагрузки Protocol Buffers (protobuf) со встроенной схемой данных.
С точки зрения разработчика gRPC хорош тем, что поддерживает разные языки программирования, позволяя, например, писать frontend на одной языке, а backend – на другом. Жесткая схема входных данных как параметров функций (процедур), вызываемых на удаленном сервере, а также результатов их обработки, обеспечивает валидацию сообщений и сокращает количество ошибок, связанных с несовпадением типов данных.
С точки зрения клиент-серверной архитектуры, gRPC поддерживает 4 варианта удаленного взаимодействия:
- унарное в стиле запрос-ответ, когда клиент отправляет серверу один запрос и получает один ответ;
- потоковое серверное, когда в ответ на запрос клиента сервер начинает потоковую передачу данных (стриминг);
- потоковое клиентское, когда клиент отправляет на сервер поток запросов и получает один ответ;
- двунаправленное потоковое, когда клиент и сервер передают друг другу потоки данных в обоих направлениях.
Такое разнообразие вариантов взаимодействия позволяет охватить множество интеграционных сценариев с разным характером передачи данных. Поэтому gRPC хорошо подходит для создания высокопроизводительных и масштабируемых распределенных систем, включая микросервисную и событийную архитектуры.
Проектирование gRPC-сервиса
Вспомнив, что такое gRPC, рассмотрим последовательность проектирования gRPC-сервиса. Как обычно, пойдем от требований. В качестве примера возьмем систему работы с поставщиками, которая должна иметь следующие функции:
- выдавать информацию о поставщике по его ИНН: название, адрес, телефон, email;
- принимать поток заказов этому поставщику до тех пор, пока количество единиц товара не превысит определенный лимит, например, 50 единиц. По завершении приема заказов система выдает общую сумму и суммарное количество товарных единиц, отправленных в заказ, а также дату и время окончания приема.
Сформулируем эти требования в виде вариантов использования (ВИ) и покажем на UML-диаграмме Use Case.
Скрипт PlantUML для этой UML-диаграммы Use Case:
Чтобы понять характер каждого варианта использования, раскроем детали его выполнения на UML-диаграммах последовательности.
Скрипт PlantUML для этой UML-диаграммы последовательности:
Скрипт PlantUML для этой UML-диаграммы последовательности:
Определим для каждого варианта использования полезную нагрузку запросов и ответов в формате protobuf.
В полезной нагрузке запросов и ответов, помимо перечисления полей и их типов данных также приведены значения для каждого поля в виде целых числе, начиная с 1. Этот уникальный номер называется тегом и нужен для идентификации поля при сериализации и десериализации данных. Теги начинаются с 1 и могут достигать 536870911, кроме диапазона от 19000 до 19999, который зарезервирован для использования в будущем и не должен использоваться в пользовательских сообщениях. Эти теги позволяют protobuf эффективно кодировать данные, обеспечивая компактное представление сообщений и быстродействие при их обработке. При сериализации данных, т.е. переводе их в бинарный вид из нулей и единиц, сохраняются не имена полей, а их уникальные номера. Это делает процесс передачи данных более эффективным по сравнению с текстовыми форматами, такими как JSON или XML.
После первичного определения gRPC-сервиса в таблице можно составить proto-файл, в котором будут описаны не только входные/выходные сообщения для RPC-функций в формате protobuf, но и сами функции. Сервис определяется с помощью ключевого слова service, после которого идет его имя. В теле сервиса перечисляются функции, определенные с помощью ключевого слова rpc с указанием входных параметров и возвращаемых результатов для каждой функции.
Для моего примера этот proto-файл выглядит так:
По своей сути, этот proto-файл является интерфейсом, который должны реализовать компоненты проектируемой системы, т.е. ее клиентская и серверная части. Заготовки для их фактической реализации на любом языке программирования генерируются автоматически из proto-файла с помощью protobuf-компилятора protoc. Сгенерированный код код включает в себя классы для сообщений, а также базовые классы и интерфейсы для реализации серверной логики и клиентских вызовов. Как это сделать, я расскажу в следующей статье, реализовав серверную и клиентскую часть рассмотренного gRPC-сервиса на Python.
Больше примеров и подробностей про архитектуру и интеграцию информационных систем вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
Статья:
Курсы:
Наш сайт:
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"