CC BY
9
doi: 10.36724/2409-5419-2023-15-2-23-32
ЭФФЕКТИВНОСТЬ ФРЕЙМВОРКОВ ДЛЯ ПЕРЕДАЧИ ИНФОРМАЦИИ В ВИРТУАЛИЗИРОВАННОЙ СЕТИ СВЯЗИ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ
БУЖИН
Игорь Геннадьевич1
ДЕРЕВЯНКИН
Алексей Юрьевич2
АНТОНОВА
Вероника Михайловна3
ПЕРЕВАЛОВ
Алексей Павлович4
МИРОНОВ Юрий Борисович5
Сведения об авторах:
1к.т.н., доцент кафедры "Сети и системы фиксированной связи", Московский Технический Университет Связи и Информатики, Москва, Россия, i.g.buzhin@mtuci.ru
2магистрант, Московский Технический Университет Связи и Информатики, Москва, Россия, alexeyderevyankin@yahoo.com
3к.т.н., доцент, зав. кафедры "Сети и системы фиксированной связи", Московский Технический Университет Связи и Информатики, Москва, Россия, у.т.а^опо-va@mtuci.ru
АННОТАЦИЯ
Введение: При проектирование различных информационных систем наблюдается переход от классической монолитной архитектуры построения сети к микросервисной. В связи с этим возникает необходимость устанавливать требования к показателям соединений между микросервисами, которые реалзиуются с помощью различных фреймворков. Цель исследования: сравнительный анализ фреймворков для передачи данных в микросервисной архитектуре по нескольким критериям, выработка рекомендаций по эффективному выбору средств для коммуникации микросервисов. Результаты: проведен сравнительный анализ RPC-фреймворков по следующим критериям: наличие центра регистрации, наличие встроенных средств безопасности на уровне фреймворка, основные технологии сериализации, возможность балансировки нагрузки. Разработан экспериментальный стенд, на основе которого были измерены и проведен сравнительный анализ временных задержек при передачи разного объема нагрузки. В случае передачи информации малого размера, по полученным значениям можно сделать вывод, что минимальная задержка вызова удаленной процедуры у фреймворка RPCX, у Apache Dubbo напротив - задержка максимальна. При изменении типа передачи с унарных вызовов на потоковую, задержка уменьшается.
4аспирант, Московский Технический Университет Связи и Информатики, Москва, Россия, a.p.perevalov@mtuci.ru
5к.т.н., декан факультета "Сети и системы связи", Московский Технический Университет Связи и Информатики, Москва, Россия, i.b.mironov@mtuci.ru
КЛЮЧЕВЫЕ СЛОВА: микросервисная архитектура, gRPC, Apache Thrift, Apache Dubbo, RPCX.
Для цитирования: Бужин И.Г., Деревянкин А.Ю., Антонова В.М., Перевалов А.П., Миронов Ю.Б. Эффективность фреймворков для передачи информации в виртуализированной сети связи с микросервисной архитектурой // Наукоемкие технологии в космических исследованиях Земли. 2023. Т. 15. № 2. С. 23-32. doi: 10.36724/2409-5419-202315-2-23-32
Введение
Современные инфокоммуникационные сети включают в себя множество архитектурных элементов, в том числе вир-туализированную сетевую инфраструктуру, и предполагают наличие таких требований, как масштабируемость, модульность, независимость от используемых платформ и инструментов разработки, использование стандартизированных интерфейсов для взаимодействия по стандартизированным протоколам. Использование монолитной архитектуры при реализации виртуализированной сетевой инфраструктуры ограничивает возможность модернизации системы, увеличивает ее программную сложность, затрудняет реализацию интерфейсов для управления и мониторинга. Таким образом, наблюдается переход от классической монолитной архитектуры построения сети к микросервисной. При такой реализации архитектуры возрастает количество устанавливаемых соединений в программных системах. В связи с этим возникает необходимость устанавливать требования к показателям соединений между микросервисами [1, 15]. В качестве таких показателей могли выступать задержка установленного соединения, количество запросов за интервал, эффективность балансировки нагрузки, скорость сжатия сообщения для передачи и т.д. Для обеспечения нужного уровня всех показателей необходимо эффективное использование инструментами для передачи данных в микросервисной архитектуре.
Одним из распространенных способов запуска микросервисов является использование контейнеров. Для управления контейнерами используются средства для оркестровки, например Kubernetes. Системы оркестровки включают в себя множество услуг, таких как мониторинг и конфигурация сети, балансировка нагрузки, планирование, DNS-службы и др. Внутри компании контейнеры взаимодействуют друг с другом посредством межсервисной связи [2, 13].
Принцип функционирования RPC
Использование RPC (от англ. remote procedure call (Удалённый вызов процедур)) в качестве межсервисного взаимодействия приносит некоторые преимущества. Одно из главных преимуществ заключается в абстрагировании разработчика от многих механизмов, связанных с коммуникацией, вместо этого разработчик может сосредоточится над проблемами функциональности разрабатываемого приложения [2, 16].
Стоит отметить, что для ряда задач, использование RPC приведет к большим затратам, чем использование других технологий, например REST (от англ. Representational State Transfer — «передача репрезентативного состояния») или SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам). Поэтому стоит комбинировать средства для межсервисной коммуникации в программных системах.
В [3] подробно описан процесс установления соединения по протоколу RPC. Процесс можно разделить на следующую последовательность (рис. 1):
1. Приложение на стороне клиента вызывает метод, находящийся в клиентской заглушке (англ. client stub), передавая входные параметры.
2. Заглушка упаковывает имя метода и входные параметры в тело запроса и передает его в библиотеку среды выполнения (англ. run-time library).
3. Библиотека обрабатывает запрос и передает транспортной службе узла.
4. Клиент отправляет запрос на адрес сервера.
5. Библиотека среды восстанавливает сообщение, полученное из транспортной службы сервера.
6. Сообщение распаковывается и передается на серверную заглушку.
7. Серверная заглушка вызывает нужный метод, реализованный в серверном приложении.
8. После выполнения вызываемого метода, возвращаемое значение преобразуется в ответное сообщение заглушкой сервера.
9. Заглушка передает ответное сообщение библиотеке среды выполнения сервера.
10-13. После чего ответное сообщение передается клиентской заглушке таким же образом, как сообщение запроса было передано на серверную заглушку.
14. Клиентская заглушка преобразует ответное сообщение в возвращаемое значение вызываемого изначально метода и возвращает его клиентскому приложению.
Клиент Сервер
Приложение Приложение
i f у [
Клиентская заглушка Серверная заглушка
i г к i ? у
Клиентская библиотека среды выполнения Серверная библиотека среды выполнения
i ,3 к. i 10 5 i
Транспорт Транспорт
) 1 11 i 4 i
Рис. 1. Процесс установления соединения по протоколу RPC
Сравнительный анализ фреймворков для реализации RPC соединений
Существует множество фреймворков для реализации RPC соединений. В данной статье исследованы четыре RPC-фреймворка: «Apache Thrift», «gRPC», «RPCX» и «Apache Dubbo».
Одним из популярных фреймворков в наши дни является gRPC. Данное решение было предоставлено компанией Google в открытый доступ в2015 году под лицензией Apache License 2.0. gRPC использует протокол НТТР/2 (англ. Hypertext Transfer Protocol v2.0 - «протокол передачи гипертекста v2.0») для передачи данных и «Protocol Buffers» в качестве языка описания интерфейса. Фреймворк имеет встроенную поддержку установления безопасного соединения с использованием механизма аутентификации, а также средства для балансировки нагрузки на стороне клиента.
Технология gRPC позволяет определить четыре типа передачи [4]:
1. Унарные вызовы, при которых клиент делает запрос на сервер и получает обратно один ответ как при обычном вызове функции.
2. Серверные потоковые вызовы, в которых клиент делает запрос на сервер и получает обратно поток последовательности сообщений. Клиент считывает данные из возвращенного потока до тех пор, пока не останется сообщений с серверной части. Все полученные сообщения упорядочиваются.
3. Клиентские потоковые вызовы. В данном типе передачи, клиент отправляет поток сообщений на сервер, сервер в свою очередь, получив все сообщения, возвращает ответ клиенту в виде одного сообщения.
4. Двунаправленные потоковые вызовы, в которых обе стороны обмениваются потоками сообщений. Потоки передаются независимо, поэтому клиент и сервер могут считывать и записывать данные в произвольном порядке.
Для передачи данных, gRPC использует двоичный протокол НТТР/2, который поддерживает асинхронную обработку запросов - при передаче сообщения не блокируют друг друга и не ждут в очереди обработки других. Для сериализации данных по умолчанию gRPC использует Protobuf, но также поддерживает другие форматы, например JSON (англ. JavaScript Object Notation).
Балансировку в gRPC можно разделить на два архитектурных типа: на стороне прокси (используя Load Balancer) и на стороне клиента. При отправке клиентом запроса на прокси, запрос пересылается на сервер с наименьшей загрузкой. При этом клиенты ничего не знают о внутренних серверах. Сам балансировщик отслеживает загрузку серверов с помощью специальных сообщений, получаемых от всех серверов. В случае балансировки на стороне клиента, клиент получает отчёты о загрузке внутренних серверов и реализует алгоритмы балансировки нагрузки [5].
Если говорить о плюсах данных типов, то в случае с прокси можно выделить отсутствие осведомленности о серверной части на стороне клиента, а в случае клиентской балансировки плюсом является высокая производительность из-за отсутствия дополнительных скачков загрузки. Из недостатков можно отметить присутствие дополнительного узла, что негативно сказывается на задержке в первом типе, и большое количество возложенных на клиента функций во втором типе. Вдобавок, при балансировке без прокси, клиент может отслеживать состояние сервера.
Рабочий процесс балансировки показан на рисунке 2. При запуске клиент получает информацию от распознавателя
имён (англ. Name Resolver) которая содержит список доступных IP-адресов с произвольными атрибутами и конфигурацией сервисов (1).
f gRPC клиент
Сервис рчюлщцйвакия имен 1 gRPC клиент в 2,5 Сервис определения алгоритма N
\ у* А
6 i X.
------ V
gRPC сервер gRPC сервер gRPC еероор
Рис. 2. Схема балансировки нагрузки gRPC
Атрибуты и конфигурация используются для определения алгоритма балансировки. По умолчанию в качестве распознавателя имён используется DNS служба. Затем клиент передаёт конфигурацию и атрибуты на сервис, отвечающий за выбор алгоритма балансировки (2). Как упоминалось ранее, можно использовать балансировщик как прокси-сервис. Балансировщик отслеживает состояние gRPC-серверов (0), и принимает все решения по балансировке запросов - для этого необходимо отправлять запросы на балансировщик (3,4). В конченом итоге, клиент получает информацию о том, на какой сервер осуществить RPC-вызов.
gRPC поддерживает три алгоритма балансировки: Pick First, Round Robin и gRPC Load Balancing. Основным алгоритмом по умолчанию является Prick Frist. После получения списка IP-адресов от распознавателя имён, балансировщик, начинает опрашивать сервисы из списка до тех пор, пока не установит соединение. Если соединение установлено, то оно помечается соответствующим флагом о готовности. Далее клиент подключается к первому в списке сервису.
В gRPC встроены следующие методы аутентификации [6]:
• Возможно использование SSL/TLS для аутентификации на сервере и шифрования соединения ме^ду клиентом и сервером;
• Аутентификация на основе JWT-токенов. Токены передаются в качестве метаданных авторизации по защищенному с помощью механизма SSL/TLS каналу.
• Поддержка ALTS (англ. Application Layer Transport Security). Данная система аутентификации и транспортного шифрования используется в случае запуска сервисов в GCP (англ. Google Cloud Platform).
Данные метода аутентификации подходят как для внутреннего взаимодействия между сервисами, так и для внешнего API.
Apache Dubbo - это высокопроизводительный RPC-фреймворк с открытым исходным кодом на основе Java. Изначально проект разрабатывался под руководством Alibaba Group, но в 2018 году перешел под управление некоммерческой организации Apache Software Foundation. В настоящее время поддерживается организацией Apache. Apache Dubbo используется более чем в 150 компаниях, включая Alibaba Group, China Telecom и другие, а реализация на Golang используется в Xiaomi Inc. Dubbo имеет реализации на языках Java, Golang, Erlang и Rust.
В качестве протокола передачи, Dubbo использует протокол Tripple, основанный на НТТР/2. Фреймворк также поддерживает опцию межъязыкового взаимодействия - для этого необходимо использовать язык для описания интерфейсов IDL (англ. Interface Definition Language). В качестве IDL возможно использование Protobuf, Hessian и др. Hessian это двоичный протокол, разработанный Caucho Technology на языке Java, используемый Dubbo по умолчанию. Для языка Golang официальной версии технологии описания интерфейса от разработчиков не предоставляется, но доступны сторонние реализации с открытым исходным кодом.
ски пропускную способность между потребителем и поставщиком с помощью коэффициента использования услуг поставщика. При увеличении количества запросов (рис. 4), время отклика на вызываемую услугу увеличивается линейно (В и С) до определенной критической точки.
/ TPS-
/ D / \ TPS
/ с 7 в Optimal num.
Number of Requests
Рис. 3. Коммуникация между компонентами Dubbo
Рис. 4. Зависимость коэффициента использования услуг от количества запросов поставщикам при балансировке
На рисунке 3 представлена схема коммуникации между компонентами Apache Dubbo при вызове потребителем услуги у поставщика. В качестве услуг выступают те процедуры, которые разработчик определил с помощью IDL. Для этого выполняются следующие шаги [7]:
0. Контейнер производит запуск поставщика.
1. Поставщик регистрирует свои услуги в регистрационном центре при запуске. В качестве регистрационных центров можно использовать Zookeeper, Nacos, etcd и Consul.
2. Потребитель фиксирует регистрационный центр при запуске.
3. Регистрационный центр возвращает список поставщиков потребителю; при изменении списка поставщиков, регистрационный центр оповестит об этом потребителя.
4. Основываясь на алгоритме балансировки нагрузки, потребитель выбирает поставщика и выполняет вызов.
5. При запуске, монитор фиксирует всех поставщиков и потребителей, которые зарегистрировались; потребитель и поставщик подсчитывают количество вызовов и каждую минуту отправляют статистику монитору.
Dubbo поддерживает верификацию по JWT-токенам. Поставщик генерирует токен и передает его в регистрационный центр, после чего потребитель может запросить токен в регистрационном центре перед вызовом службы и подтвердить свою подлинность у поставщика.
Для балансировки нагрузки Apache Dubbo использует, так называемую, технологию гибкой балансировки. Традиционно балансировка нагрузки основывается на устоявшихся алгоритмах таких как Round Robin, Least Connections, Sticky Sessions и др. Dubbo при балансировке оценивает динамиче-
Далее при увеличении количества запросов время отклика будет увеличиваться экспоненциально (D). Критическая точка является экстремумом кривой коэффициента использования услуг. Исходя из этого можно сделать вывод, что суть гибкой балансировки заключается в поддержании максимального значения коэффициента использования услуг, то есть оптимального количества запросов на один сервис [8].
RPCX это многофункциональный, быстрый и простой в использовании, подобный Apache Dubbo и Weibo Motan, RPC-фреймворк, за основу которого была взята стандартная библиотека RPC языка Golang.
Стандартно, для передачи байт данных, RPCX использует протоколы TCP или UDP - транспортные протоколы семиуровневой модели OSI. Фреймворк также поддерживает HTTP-вызовы на прикладном уровне, но сам разработчик, в виду производительности, не рекомендует их использовать. Также была добавлена поддержка протокола QUIC, описанного в RFC 9000. Для сериализации данных RPCX поддерживает множество технологий (Avro, JSON, Protobuf и др) и даёт возможность пользователю для написания собственного кодека. По умолчанию RPCX использует формат MessagePack -это двоичная форма представления структур данных [8].
Схема взаимодействия клиента и сервера очень схожа со схемой Apache Dubbo. Незначительные отличия могут быть в связи с регистрационным центром в некоторых версиях. В качестве регистрационного центра фреймворк поддерживает Apache Zookeeper, etcd, Consul и mDNS.
Отдельно следует отметить возможность развертывания в режиме прокси, когда клиент взаимодействует с компонентами через отдельный сервис.
Возможно два варианта развертывания схемы в данном режиме (рис. 5): шлюз на отдельной машине и агент на локальной машине с клиентом. В первом случае шлюз отвечает за преобразования HTTP запросов в RPC вызовы и наоборот. Как вариант, можно развернуть несколько шлюзов и использовать Nginx для балансировки нагрузки между клиентами. Во втором случае роль агента схожа с ролью шлюза, но агент развертывается на локальной машине с клиентом в виде отдельной службы и взаимодействует с регистрационным центром и сервисом.
Рис. 5. Варианты развертывания прокси между клиентом и сервисом RPCX
Как было упомянуто ранее в качестве протокола передачи, RPCX использует протокол TCP. Конкретно в реализации на Golang, которая будет рассмотрена в данной статье, используется стандартная библиотека "net". Поэтому для того, чтобы повысить защищенность соединения необходимо настроить TLS-сессию. Сделать это можно, сгенерировав ключи и сертификат с помощью библиотеки OpenSSL и подключив библиотеку «tls».
На прикладном уровне, как утверждает разработчик, поддерживается аутентификация с помощью токенов. Сама же реализация очень проста и суть её заключается в проверке двух строк через оператор «equal-to», но пользователь может изменить логику аутентификации самостоятельно.
Для балансировки нагрузки RPCX использует набор стандартных алгоритмов: Round Robin, Weight Round Robin, Random (без балансировки). Если пользователю предпочтительнее распределить нагрузку по качеству соединения, то реализован и такой метод, основанный на данных ping. Для крупномасштабных, в плане расположения серверов, задач существует реализация балансировки по географическим координатам - клиенту будут предложены услуги самого ближнего находящегося к нему сервера. Возможно написание реализации балансировки и самим пользователем.
В RPCX встроено множество дополнительных плагинов, таких как: широковещательная рассылка запросов на все сервисы, health check для поддержки состояния сессии, группировка услуг по определенным параметрам, мониторинг показателей сервисов с помощью Grafana и др. Пользователю доступна разработка плагинов самостоятельно.
Apache Thrift - это платформа для межъязыковой сериа-лизации и удаленного вызова процедур, разработанная некоммерческой организацией Apache Software Foundation. Фреймворк поддерживает более 20 языков программирования, среди которых есть С++, Java и Golang. Компания Meta совместно с Apache Software Foundation разработала собственную усовершенствованную версию фреймворка и открыла доступ в феврале 2014 года под названием Facebook Thrift.
Thrift также использует прикладной протокол НТТР/2 для передачи данных, но также возможна передача байт данных с помощью транспортного протокола TCP. По умолчанию, фреймворк использует собственное решение Apache Thrift IDL которое поддерживает три протокола сериализации данных [9].
В отличии от Dubbo и RPCX, Apache Thrift не имеет центра регистрации. Архитектура взаимодействия клиента и сервера платформы Thrift напоминает стандартную схему взаи-модействияРРС (рис. 6) [9].
Внизу стека располагается транспорт, изолирующий верхние уровни от устройств. Транспорт позволяет читать и записывать потоки байт вне зависимости от производителя и прошивки устройств, поддерживая новые типы устройств и версии промежуточного программного обеспечения. В качестве транспорта при асинхронной передаче используется транспорт кадрирования (англ. Framed Transport) - к каждому сообщению добавляется четырёхбайтовый префикс с размером сообщения для более эффективной обработки. При синхронной передаче используется буферизированный транспорт (англ. Buffered Transport), который записывает данные переданных пакетов во внутренний буфер.
Сервер
Библиотеки Apacha Thrifi □ Код сгенерированный IDL
Программа клиента
Сервисный обработчик
> h
Слой сервисных зашлутек
Слой пользовательских типов
Слой протокола
Слой транспорта
Устройство (file memory net...)
Рис. 6. Архитектура фреймворка Apache Thrift
«Protocol» - это слой сериализации типов. Apache Thrift IDL поддерживает в основном базовые типы данных, определенных в большинстве языках (int, string, float и др.), а также распространенные типы контейнеров: map, set и list [10].
Apache Thrift IDL поддерживает следующие протоколы сериализации: Compact Protocol, Binary Protocol и JSON Protocol. Binary Protocol - протокол перевода данных в поток байт. Compact Protocol кодирует данные более сложными типами кодировок, за счёт чего уменьшается размер передаваемых данных, но требуется больше ресурсов центрального процессора чем у Binary Protocol.
JSON Protocol преобразует входные данные в устоявшийся JSON формат, что дает более широкую совместимость и удобочитаемость, но потребляет больше всего системных ресурсови увеличивает время передачи [9].
Слой "User types" определяет интерфейс использования типов. Пользователь в конфигурационном IDL файле имеет возможность определять собственные типы в виде структур. Структуры представляют собой набор полей, состоящих из базовых типов.
«Services stubs» предоставляет пользователю интерфейс для вызова удаленных процедур в виде сгенерированных заглушек.
Apache Thrift не предусматривает средств для защиты соединения на уровне фреймворка, поскольку многие используемые системы размещены в защищенных центрах обработки данных. Для установления безопасного соединения возможно настроить механизмы SSL/TLS, либо реализовать систему безопасности самостоятельно.
Для балансировки нагрузки также следует использовать сторонние сервисы.
В табл.1 представлено сравнение RPC-фреймворков по расписанным выше критериям.
Таблица 1
Сравнение RPC-фреймворков
Apache Dubbo RPCX Apache Thrift gRPC
Центр регистрации + + - -
Встроенные средства безопасности на уровне фреймворка + - - +
Основные технологии сериализации Hessian MsgPack Binary Protocol и Compact Protocol Рго1оЬи£
Балансировка нагрузки Помимо стандартных алгоритмов, имеет собственные решения Реализованы стандартные алгоритмы - Реализованы некоторые стандартные алгоритмы
Поддерживаемые ЯП Java, Golang, Erlang, Rust Golang, Rust, Java Поддерживает 28 языков программирования Поддерживает 13 языков программирования
Измерения производились на вычислительной машине со следующими характеристиками:
• CPU: Intel(R) Core (TM) Í5-10300H CPU @ 2.50GHz 2.50 GHz
RAM: 16 GB
Версия OS: Ubuntu 20.04.5 LTS, amd64 Версия Golang: 1.19.4 gRPC: 1.51.0 RPCX: vl.7.11 ApacheThrift: 0.17.0 Apache Dubbo: v3.0.2 Клиент и сервер запускались в docker-контейнерах и передавали между собой полезную нагрузку. В роли средств мониторинга и визуализации метрик использовалась связка Grafana и Prometheus. Для средств оркестрации docker-контейнеров, с помощью инструмента для запуска локального кластера kind, был развернут Kubernetes кластер. Полученные данные были проанализированы и представлены в виде графиков и гистограмм, построенных с помощью программы gnuplot. На рис. 7 приведена примерная схема развернутого кластера для снятия тестовых измерений.
Экспериментальное исследование
Для сравнения фреймворков по задержке были проведены тестовые измерения путём передачи данных между клиентом и сервером. В качестве языка программирования для написания приложений был выбран язык Со1а^. Основной причиной выбора стало наличие реализаций на данном языке у рассмотренных решений.
Рис. 7. Схема экспериментального кластера
Размер малых данных передаваемых в качестве полезной нагрузки можно считать пренебрежимо малым, при передаче же массивных данных, добавлялась произвольная полезная нагрузка размером 437 кБайт. Для измерения задержки каждого соединения использовалась встроенная в язык Go библиотека «time». Также стоит отметить, что вызов считается завершенным, когда сторона, открывшая соединение, его закрывает.
На рисунке 8 представлен результат исследования при передаче малых и больших данных между клиентом и сервером. В случае передачи информации малого размера, по полученным значениям можно сделать вывод, что минимальная задержка вызова удаленной процедуры у фреймворка RPCX, у Apache Dubbo напротив - задержка максимальна. Полученные результаты можно объяснить использованием технологий представления данных для передачи. RPCX сериализует данные с помощью MsgPack, который не упаковывает никакую дополнительную мета информацию в передаваемые сообщения, что дает высокую производительность, однако возникают сложности при передаче больших данных с большим количеством полей, поскольку приходится обрабатывать каждое поле структуры.
Рис. 8. Сравнение RPC-фреймворков при передаче малой и большой полезной нагрузки по задержке (95th percentile)
qRPC RPCXj Apache Dubbo, Apache Tr¡ft qRPC RPCX. Apache Dubbo, Apache Trift
Рис. 9. Сравнение RPC-фреймворков при разных типах передач gRPC (95th percentile)
Метаинформация Thrift содержит много различных идентификаторов, что даёт большую задержку в передаче. Dubbo использует протокол Hessian, также который является двоичным. Большая задержка при передаче малых данных может говорить как о большом количестве сторонней дополнительной информации в сообщении, так и о недочётах в реализации на Golang. В тестировании использовалась версия Hessian из официального репозитория Apache Software Foundation.
Результаты Protobuf и gRPC следует выделить отдельно. Как было упомянуто ранее, gRPC имеет четыре типа передачи. На приведенном выше рисунке 8 был использован только тип передачи унарных вызовов, поэтому сравнение можно представить следующим образом (рис. 9). При изменении типа передачи с унарных вызовов на потоковую, задержка уменьшается. Этот факт можно объяснить следующим образом: при потоковой передаче, данные разбиваются на части на уровне фреймворка и передаются асинхронно в
разных горутинах [12] (англ. Go routine). В случае двунаправленной передачи, полезная нагрузка вовсе передавалась в обе стороны по 437 КБайт.
Заключение
Таким образом, в результате сравнительного анализа RPC-фреймворков для передачи данных в микросервисной архитектуре можно сделать вывод, что при выборе средств для коммуникации сервисов необходимо находить компромисс между производительностью и функционалом технологии для решения задачи. Для большинства задач, завязанных на производительность и задержку системы, а также передачу массивных данных, следует рассмотреть вариант использования потоковых передач gRPC. Протокол Protobuf является одним из самых быстрых на обработку и компактных на передачу протоколов сериализации.
Решая простые задачи, не требующие высокой производительности, но требующие разнообразности функций инструмента рекомендуется рассмотреть фреймворк RPCX. Данный фреймворк показал свою простоту в реализации клиентской и серверной части, а широкий функционал позволил осуществить передачу метрик на систему мониторинга без использования сторонних библиотек. Для передачи массивных данных фреймворк RPCX не подходит.
Для построения сложных систем, требующих возможности расширить функциональность инструмента, стоит сделать выбор в сторону решения от Apache Dubbo. Помимо уже имеющегося набора функций, фреймворк является достаточно гибким для реализации и внедрения собственных решений. Проблемы возможны при изучении официальной документации, поскольку фреймворк изначально разрабатывался китайской компанией и имеет небольшую часть описаний на английском языке.
В больших и сложных системах, требующих высокой точности описания инструмента, возможности для расширения и в то же время высокой производительности предлагается использовать фреймворк Apache Thrift. Из-за большого количества документации данным инструментом можно овладеть в совершенстве за относительно короткий промежуток времени, а также возможно расширить функционал. Двоичные протоколы сериализации являются одними из самых производительных, что обеспечивает большую скорость при передаче.
Литература
1. Zhizhou Zhang, Murali Krishna Ramanathan, Prithvi Raj, Ab-hishek Parwal, Timothy Sherwood, Milind Chabbi. CRISP: CriticalPath Analysis of Large-Scale Microservice Architectures II USENIX Annual Technical Conference, 2022, Carlsbad, CA, USA.
2. Zhipeng Jia, Emmett Witchel. Nightcore: Effrcient and Scalable Serverless Computing for Latency-Sensitive, Interactive Microservices II ASPLOS '21,April 19-23,2021, Virtual, USA.
3. Принцип работы RPC II Официальная документация Microsoft. [Электронный ресурс]: https://learn.microsoft.com/ru-ru/win-dows/win32/rpc/how-rpc-works.
4. Introduction to gRPC II Официальная документация gRPC. [Электронный ресурс]: https://grpc.io/docs/what-is-grpc/introduction/.
5. gRPC Load Balancing И Официальная документация gRPC. [Электронный ресурс]: https://grpc.io/blog/grpc-load-balancing/.
6. Michal Stefanic. Developing the guidelines for migration from RESTful microservices to gRPC II Masaryk University, Faculty of Informatics, Brno, 2021.
7. Architecture of Apache Dubbo II Официальная документация Apache Dubbo. [Электронный ресурс]: https://dubbo.apache.org/en/ docs/v2.7/user/preface/architecture/.
8. Flexible load balancing II Официальная документация Apache Dubbo. [Электронный ресурс]: https://dubbo.apache.org/zh/docs3-v2/golang-sdk/concept/service_management/adaptive_lb/.
9. Randy Abernethy. Programmer's guide to Apache Trift//Manning Publications Co, 2019.
10. Introduction to RPCX II Официальная документация RPCX. [Электронный ресурс]: https://doc.rpcx.io/.
11. Thrift types II Официальная документация Apache Thrift. [Электронныйресурс]: https://thrift.apache.org/docs/types.html.
12. Coroutines II Официальная документация Golang. [Электронный ресурс]: https://go.dev/tour/concurrency.
13. Thurlow R. RFC 5531: RPC: Remote procedure call protocol specification version 2. 2009.
14. He X., Yang X. Authentication and authorization of end user in microservice architecture //Journal of Physics: Conference Series. IOP Publishing, 2017. T. 910. №1. C. 012060.
15. Safaryan O. et al. Information system development for restricting access to software tool built on microservice architecture IIE3S Web of Conferences. EDP Sciences, 2020. T. 224. C. 01041.
16. El Kholy M., El Fatatry A. Framework for interaction between databases and microservice architecture II IT Professional. 2019. T. 21. №. 5. C. 57-63.
17. Mochalov V. P. et al. Methods and models of resource allocation service in load balancing clusters for data centers. 2022.
18. Мочалов В.П. и др. Инфокоммуникационные технологии II Инфокоммуникационныетехнологии. 2021. Т. 19. №.2. С. 163-172.
19. БурановМЛ., КарташевскийВ.Г., МутханнаА.С. Анализ параметров функционирования программно-конфигурируемой сети на основе протокола OpenFlow// Электросвязь. 2022. № 4. С. 2-7. DOI 10.34832/ELSV.2022.29.4.001. EDN KMHZKH.
20. StepanovM.S., Stepanov S.N., Ndayikunda J. etal. The Increasing of Resource Sharing Efficiency in Network Slicing Implementation II Communications in Computer and Information Science. 2022. Vol. 1552. P. 18-35. DOI 10.1007/978-3-030-97110-6-2. EDNZSXJTR.
21. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels II 45th European Conference on Optical Communication (ECOC 2019). IET, 2019. C. 1-4.
THE EFFECTIVENESS OF FRAMEWORKS FOR TRANSMITTING INFORMATION
IN A VIRTUALIZED COMMUNICATION NETWORK WITH A MICROSERVICE ARCHITECTURE
IGOR G. BUZHIN,
Moscow, Russia, i.g.buzhin@mtuci.ru
ALEKSEY YU. DEREVYANKIN,
Moscow, Russia, alexeyderevyankin@yahoo.com
VERONIKA M. ANTONOVA,
Moscow, Russia, v.m.antonova@mtuci.ru
ALEKSEY P. PEREVALOV,
Moscow, Russia, a.p.perevalov@mtuci.ru
YURIY B. MIRONOV,
Moscow, Russia, i.b.mironov@mtuci.ru
KEYWORDS: microservice architecture, gRPC, Apache Thrift, Apache Dubbo, RPCX.
ABSTRAd
Introduction: Different information system designs are moving from a classical monolithic network architecture to a microservice one. Therefore, there is a need to set requirements to the performance of interconnection between microservices, which are implemented using various frameworks. The aim of this study is to make a comparative analysis of frameworks for data transmission in a microservice architecture according to several criteria as well as to develop recommendations for effective selection of tools for microservice communication. The results of the study include a comparative analysis of RPC frameworks by the fol-
lowing criteria: the availability of a registration centre, the availability of built-in framework-level security features, the main serialization technologies, the ability to balance the load. An experimental stand was developed; it was used to measure time delays and to make their comparative analysis while transmitting different data workload. When small amounts of information are transferred, the values obtained indicate that the RPCX framework has the lowest latency for a remote procedure call, while Apache Dubbo, on the contrary, has the highest latency. When the transfer type switches from unary calls to streaming, the latency decreases.
REFERENCES
1. Zhizhou Zhang, Murali Krishna Ramanathan, Prithvi Raj, Abhishek Parwal, Timothy Sherwood, Milind Chabbi. CRISP: Critical Path Analysis of Large-Scale Microservice Architectures. USENIX Annual Technical Conference, 2022, Carlsbad, CA, USA.
2. Zhipeng Jia, Emmett Witchel. Nightcore: Efficient and Scalable Serverless Computing for Latency-Sensitive, Interactive Microservices. ASPLOS '21, April 19-23, 2021, Virtual, USA.
3. The principle of RPC operation // Official Microsoft documentation. [Electronic resource]: https://learn.microsoft.com/ru-ru/win-dows/win32/rpc/how-rpc-works.
4. Introduction to gRPC // Official gRPC documentation. [Electronic resource]: https://grpc.io/docs/what-is-grpc/introduction/.
5. gRPC Load Balancing // Official gRPC documentation. [Electronic resource]: https://grpc.io/blog/grpc-load-balancing/
6. Michal Stefanic. Developing the guidelines for migration from RESTful microservices to gRPC. Masaryk University, Faculty of Informatics, Brno, 2021.
7. Architecture of Apache Dubbo // Официальная документация Apache Dubbo. [Electronic resource]: https://dubbo.apache.org/en/docs/v2.7/user/preface/architecture/.
8. Flexible load balancing // Official Apache Dubbo documentation. [Electronic resource]: https://dubbo.apache.org/zh/docs3-v2/golang-sdk/concept/service_management/adaptive_lb/ .
9. Randy Abernethy. Programmer's guide to Apache Trift. Manning Publications Co, 2019.
10. Introduction to RPCX // Official RPCX documentation. [Electronic resource]: https://doc.rpcx.io/.
11. Thrift types // Official Apache Thrift documentation. [Electronic resource]: https://thrift.apache.org/docs/types.html.
12. Goroutines. Official documentation of Golang. [Electronic resource]: https://go.dev/tour/concurrency.
13. Thurlow R. RFC 5531: RPC: Remote procedure call protocol specification version 2. 2009.
14. He X., Yang X. Authentication and authorization of end user in microservice architecture. Journal of Physics: Conference Series. IOP Publishing, 2017. Vol. 910. No. 1. P. 012060.
15. Safaryan O. et al. Information system development for restricting access to software tool built on microservice architecture. E3S Web of Conferences. EDP Sciences, 2020. Vol. 224. P. 01041.
16. El Kholy M., El Fatatry A. Framework for interaction between databases and microservice architecture. IT Professional. 2019. Vol. 21. No. 5, pp. 57-63.
17. Mochalov V.P. et al. Methods and models of resource allocation service in load balancing clusters for data centers. 2022.
18. Mochalov V.P. et al. Infocommunication technologies. Infocommunication technologies Founders: Volga State University of Telecommunications and Informatics, Academy of Telecommunications and Informatics. 2021. Vol. 19. No. 2, pp. 163-172.
19. Buranova M.A., Kartashevsky V.G., Muthanna A.S. Analysis of the parameters of the functioning of a software-configurable network based on the OpenFlow protocol. Telecommunications. 2022. No. 4, pp. 2-7. DOI 10.34832/ELSV.2022.29.4.001.
20. Stepanov S.N. Stepanov J. Ndayikunda et al. The Increasing of Resource Sharing Efficiency in Network Slicing Implementation. Communications in Computer and Information Science. 2022. Vol. 1552, pp. 18-35. DOI 10.1007/978-3-030-97110-6_2.
21. Vilalta R. et al. GRPC-based SDN control and telemetry for soft-failure detection of spectral/spacial superchannels. 45th European Conference on Optical Communication (ECOC 2019). IET, 2019, pp. 1-4.
INFORMATION ABOUT AUTHORS:
Igor G. Buzhin, PhD, Associate Professor of the Department "Fixed-line networks and Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
Aleksey Yu. Derevyankin, Student, Moscow Technical University of Communications and Informatics, Moscow, Russia
Veronika M. Antonova, PhD, docent, Head of the Department "Fixed-line networks and Systems", Moscow Technical University of Communications and Informatics, Moscow, Russia
Aleksey P. Perevalov, graduate student, Moscow Technical University of Communications and Informatics, Moscow, Russia
Yuriy B. Mironov, PhD, Dean of the Faculty of "Networks and Communication Systems", Moscow Technical University of Communications and
Informatics, Moscow, Russia
For citation: Buzhin I.G., Derevyankin A. Yu., Antonova V.M., Perevalov A.P., Mironov Yu.B. The effectiveness of frameworks for transmitting information in a virtualized communication network with a microservice architecture. H&ES Reserch. 2023. Vol. 15. No 2. P. 23-32. doi: 10.36724/24095419-2023-15-2-23-32 (In Rus)
ORGANIZERS:
IRIS ASSOCIATION (INSTITUTE OF RADIO AND INFORMATION SYSTEMS, VIENNA, AUSTRIA) RUSSIA SECTION TEM/GRS/ITSS JOINT CHAPTER
INTERNATIONAL CONFERENCE
«2023 International Conference «Engineering Management of Communication and Technology»
(EMCTECH)
IEEE Conference 16 - 18 October 2023, Vienna, Austria
Conference will produce a publication.
All accepted and presented Papers following the conference will be submitted for inclusion into IEEE Xplore and will be submitted also for indexing in Scopus and Web of Science data bases
The papers which are discussed at the conference can be divided into the following chapters:
CHAPTER 1. TECHNOLOGY ADVANCEMENTS IN IOT DEVICES & ARTIFICIAL INTELLIGENCE
CHAPTER 2. TRANSPORT AND COLLECTIVE SYSTEMS: SMART CONTROL TECHNOLOGY IN TRANSPORTATION, BIOMEDICAL, FARMING AND CYBER PHYSICAL SYSTEMS (new opportunities using technology in biomedical, farming, transportation, and cyber physical systems)
CHAPTER 3. BROADCAST TECHNOLOGIES ADVANCEMENTS - RADIO, IP, CELLULAR, ON DEMAND, INTERACTIVE CHAPTER 4. TECHNOLOGY ADVANCEMENTS IN WIRE AND OPTICAL COMMUNICATION AND CONTROL SYSTEMS CHAPTER 5. DIGITALIZATION PROCESS AND SECURITY MANAGEMENT IN DIGITAL SOCIETY AND INDUSTRY 4.0 CHAPTER 6. DIGITAL TRANSFORMATION AND DATA RISK MANAGEMENT IN ICT/TELECOMMUNICATION CHAPTER 7. DEVELOPING PERSONAL SKILLS FOR LEADING INNOVATION INITIATIVES
CHAPTER 8. ENGINEERING TECHNOLOGY LEADING TO SOCIAL, POLITICAL AND ECONOMICAL CHANGE
Materials are available in English http://media-publisher.eu/conference-emctech/call-for-papers/
