Pages Navigation Menu

ISSN 2227-6017 (ONLINE), ISSN 2303-9868 (PRINT), DOI: 10.18454/IRJ.2227-6017
ЭЛ № ФС 77 - 80772, 16+

DOI: https://doi.org/10.23670/IRJ.2022.118.4.007

Скачать PDF ( ) Страницы: 40-43 Выпуск: № 4 (118) Часть 1 () Искать в Google Scholar
Цитировать

Цитировать

Электронная ссылка | Печатная ссылка

Скопируйте отформатированную библиографическую ссылку через буфер обмена или перейдите по одной из ссылок для импорта в Менеджер библиографий.
Гагарин В. Ю. ОСОБЕННОСТИ МИГРАЦИИ ТЕХНИЧЕСКИХ ПРОЕКТОВ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ И ИСПОЛЬЗОВАНИЕМ GRPC В КАЧЕСТВЕ ПРОТОКОЛА МЕЖСЕРВИСНОГО ВЗАИМОДЕЙСТВИЯ С ПЛАТФОРМЫ .NET CORE 3 НА ПЛАТФОРМУ .NET 6 / В. Ю. Гагарин, А. В. Вагнер, А. А. Тропченко // Международный научно-исследовательский журнал. — 2022. — № 4 (118) Часть 1. — С. 40—43. — URL: https://research-journal.org/technical/osobennosti-migracii-texnicheskix-proektov-s-mikroservisnoj-arxitekturoj-i-ispolzovaniem-grpc-v-kachestve-protokola-mezhservisnogo-vzaimodejstviya-s-platformy-net-core-3-na-platformu-net-6/ (дата обращения: 25.05.2022. ). doi: 10.23670/IRJ.2022.118.4.007
Гагарин В. Ю. ОСОБЕННОСТИ МИГРАЦИИ ТЕХНИЧЕСКИХ ПРОЕКТОВ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ И ИСПОЛЬЗОВАНИЕМ GRPC В КАЧЕСТВЕ ПРОТОКОЛА МЕЖСЕРВИСНОГО ВЗАИМОДЕЙСТВИЯ С ПЛАТФОРМЫ .NET CORE 3 НА ПЛАТФОРМУ .NET 6 / В. Ю. Гагарин, А. В. Вагнер, А. А. Тропченко // Международный научно-исследовательский журнал. — 2022. — № 4 (118) Часть 1. — С. 40—43. doi: 10.23670/IRJ.2022.118.4.007

Импортировать


ОСОБЕННОСТИ МИГРАЦИИ ТЕХНИЧЕСКИХ ПРОЕКТОВ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ И ИСПОЛЬЗОВАНИЕМ GRPC В КАЧЕСТВЕ ПРОТОКОЛА МЕЖСЕРВИСНОГО ВЗАИМОДЕЙСТВИЯ С ПЛАТФОРМЫ .NET CORE 3 НА ПЛАТФОРМУ .NET 6

DOI: https://doi.org/10.23670/IRJ.2022.118.4.007

ОСОБЕННОСТИ МИГРАЦИИ ТЕХНИЧЕСКИХ ПРОЕКТОВ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ
И ИСПОЛЬЗОВАНИЕМ GRPC В КАЧЕСТВЕ ПРОТОКОЛА МЕЖСЕРВИСНОГО ВЗАИМОДЕЙСТВИЯ
С ПЛАТФОРМЫ .NET CORE 3 НА ПЛАТФОРМУ .NET 6

Научная статья

Гагарин В.Ю.1,*, Вагнер А.В.2, Тропченко А.А.3

1, 2, 3 Университет ИТМО, Санкт-Петербург, Россия

* Корреспондирующий автор (gagarinvy[at]itmo.ru)

Аннотация

В последнее время продукты компании Microsoft начинают всё чаще использоваться в коммерческой разработке. Они активно захватывают рынок enterprise приложений. Раньше .NETFramework задавал множество ограничений, среди которых было использование операционной системы Windows в качестве базовой среды размещения. Сегодня, с появлением кроссплатформенной среды .NETCore, разработчики программного обеспечения получили платформу с открытым исходным кодом и возможность создавать приложения различного типа на разных операционных системах. В данной статье проводится сравнительный анализ особенностей платформ 3 и 6 версий. При этом в статье показаны технические особенности миграции проектов с микросервисной архитектурой и использованием GRPC в качестве протокола межсервисного взаимодействия с одной платформы на другую. Результатами являются описание и план действий по миграции, который необходим для безопасного перевода проекта на новую платформу, и сравнение итогов нагрузочного тестирования промышленного приложения с микросервисной архитектурой, работающего под управлением двух разных платформ.

Ключевые слова: миграция, .NET, микросервисная архитектура, GRPC.

FEATURES OF MIGRATION OF TECHNICAL PROJECTS WITH MICROSERVICE ARCHITECTURE AND THE USE OF GRPC AS AN INTER-SERVICE COMMUNICATION PROTOCOL FROM .NET CORE 3 TO .NET 6

Research article

Gagarin V.Yu.1,*, Vagner A.V.2, Tropchenko A.A.3

1, 2, 3 ITMO University, Saint Petersburg, Russia

* Corresponding author (gagarinvy[at]itmo.ru )

Abstract

Recently, Microsoft products have been increasingly used in commercial development. They are actively capturing the enterprise application market. Earlier .NET Framework set many restrictions, among which was the use of the Windows operating system as the base hosting environment. Today, with the advent of a cross-platform environment .NET Core, software developers have received an open source platform and the ability to create applications of various types on different operating systems. This article provides a comparative analysis of the features of the platform’s versions 3 and 6 At the same time, the article shows the technical features of the migration of projects with microservice architecture and the use of GRPC as an inter-service communication protocol from one platform to another. The results of the research are a description and an action plan for migration, which is necessary for the safe transfer of the project to a new platform, and a comparison of the results of load testing of an industrial application with a microservice architecture running on two different platforms.

Keywords: migration, .NET, microservice architecture, GRPC.

Введение

Количество пользователей социально-промышленных интернет-систем растёт с каждым днём. Число людей, которые регулярно посещают, например, социальную сеть Facebook, увеличилось за прошедший год на восемь процентов и достигло отметки в 2,5 миллиарда человек. Каждые 5 лет сложность информационных сервисов, в среднем, увеличивается в 10 раз. Если раньше одного разработчика программного обеспечения было достаточно для создания программного продукта, то теперь для выполнения аналогичной задачи создаются целые отделы.
Как горизонтально и вертикально масштабировать такую платформу при бурном росте числа пользователей?
Какие современные технологии использовать для оптимизации нагрузки в архитектуре таких систем?

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

Работая в компании, которая занимается разработкой подобного highload решения, мы стараемся много времени уделять соблюдению гарантированно заданных показателей пропускной способности системы, разработке новых методов и средств оптимизации нагрузки или оценке существующих параметров эффективности.

Целью данной работы является попытка уменьшить среднее время выполнения запроса к нашей системе за счёт миграции микросервисов на новую платформу .NET 6.

Исходя из поставленной цели были определены пять основных задач:

  1. Дать краткую характеристику использования платформ .NETCore 3 и .NET 6 на базе протокола GRPC;
  2. Провести сравнительный анализ платформ, выделив их основные достоинства и недостатки;
  3. Выполнить миграцию части микросервисов промышленного приложения на новую платформу .NET 6, выработав шаблон перехода;
  4. Провести нагрузочное тестирование части функционала промышленной системы;
  5. Дать оценку эффективности работы промышленной системы на разных платформах.

Сравнительный анализ платформ

.NETCore 3 представляет из себя кроссплатформенную среду разработки, поэтому в качестве прикладного средства доставки и размещения программного обеспечения можно использовать разные операция системы – Windows, macOS или Linux. Продукт разрабатывается компанией Microsoft и имеет открытый исходный код. Благодаря этому сформировано большое лояльное сообщество разработчиков, постоянно дополняющих и улучшающих платформу. На базе .NETCore возможно разрабатывать широкий спектр различных типов приложений: десктопные, мобильные, веб-приложения, облачные сервисы, продукты для интернета вещей, игры, искусственный интеллект.

При этом в .NET 6 появился ряд существенных архитектурно-технических изменений, которые потенциально могут повысить производительность приложений. Из основных можно выделить следующие:

  • GRPC сервер на языке C#;
  • Поддержка технологии ReadyToRun для JIT компиляции;
  • Поддержка Profile-Guided Optimization;
  • Поддержка горячей перезагрузки приложений.

JIT компилятор – это одновременно и преимущество и недостаток. С одной стороны, программа тратит меньше времени на запуск приложения, а с другой –время выполнения первых запросов к системе может превышать привычный таймаут, и они будут завершаться с ошибкой. Такая начальная задержка иногда ещё называется «прогревом». Дело в том, что сначала компилятор компилирует код в промежуточный язык (intermediatelanguage), а уже потом срабатывает JIT компилятор. Он обрабатывает только тот код, который был непосредственно вызван пользователем.

Технология ReadyToRun позволяет предварительно осуществить сборку всего приложения, а уже потом запустить программу. Логично, что в таком случае мы не будем терять время на «прогрев», и время выполнения первых запросов к системе не будет кратно увеличено, а будет примерно совпадать со временем выполнения последующих запросов.

Говоря про особенности протокола GRPC, нужно понимать, что это система удалённого вызова процедур, которая в качестве транспорта использует HTTP/2. В .NET 6 появилась практически встроенная поддержка KeepAlive пингов, которые позволяют удерживать активные HTTP/2 соединения в периоды бездействия, что безусловно тоже снижает накладные расходы.

Чтобы нагляднее продемонстрировать различия и особенности двух разных платформ, обратимся к таблице ниже (см. таблицу 1).

Таблица 1 – Сравнительный анализ платформ .NETCore 3 и .NET 6

.NET Core 3 .NET 6
GRPC сервер на языке C# +
Keep alive пинги +
Сериализация объектов + Множество улучшений
Поддержка Arm64 (Apple) +
Технология PGO +
Технология ReadyToRun +/- +
Технология HotReload +

Особенности миграции

.NETCore 3 не содержит сторонних библиотек, которые бы имели поддержку GRPC сервера, написанного на языке C#. В библиотеке Grpc.Core он реализован на языке C++, поэтому существуют накладные расходы на конвертацию и преобразование вызовов. Используется С++ Interop (ImplicitPInvoke). Очень важное нововведение в .NET 6 заключается в том, что появился nuget пакет Grpc.AspNetCore, который содержит GRPC сервер, написанный на языке C#. Это упрощает и реализацию, и поддержку программных GRPC вызовов.

В случае, когда в проекте используется nuget пакет Autofac для регистрации компонентов, то от него тоже можно отказаться в новой версии .NET. Вместо этого можно использовать ServiceCollection.

Если необходимо собирать метрики в какую-то систему сбора метрик, например Prometheus, то можно воспользоваться nuget пакетами NetGrpcPrometheus, prometheus-net.DotNetRuntime и Prometheus.Client.MetricServer.

Также в новой платформе можно использовать новую 9 версию языка C#, которая содержит множество новых функций и улучшений: record-типы, init-свойства, атрибуты у локальных типов, упрощённая структура кода и. т. д.

Основные результаты

Для сравнения работоспособности промышленного приложения, работающего под управлением двух разных платформ, было проведено нагрузочное тестирование с помощью программы ApacheJMeter.

Тестовые пользователи в количестве 100000 юнитов генерировали случайную нагрузку, осуществляя действия, приближенные к поведению реальных пользователей в системе. Длительность теста составила порядка 90 минут.

Далее с помощью системы сбора метрик Prometheus, которая используется для анализа данных и мониторинга распределенных высоконагруженных приложений, были собраны метрики использования ресурсов сервера компании.

В пике нагрузки суммарное количество запросов к микросервису ApiGateWay достигало показателя в ~ 37000 запросов (см. рисунок 1). Показатели нагрузки снимались каждые 15 минут. При этом видно, что до начала тестирования и после его окончания, ресурсы сервера были задействованы в штатном режиме. Чтобы посчитать среднее количество запросов к системе за единицу времени нужно разделить общее количество запросов за время проведения нагрузочного тестирования на время выполнения всего теста.

1 (1)

где:

ARPS – averagerequestpersecond (среднее количество запросов к системе в секунду);

STI – snippettimeinterval (временной интервал сбора статистики в минутах);

TIQ – timeintervalcount (количество временных интервалов за время проведения теста).

Следующим шагом были определены показатели среднего времени выполнения запроса к системе (см. рисунок 2). Для наглядности они были разведены по двум таблицам и сгруппированы по конкретным микросервисам для двух разных платформ. Исходя из этого рисунка, можно определить, что процент уменьшения среднего времени выполнения запроса к системе составил ~ 7,65 %.

1

Рис. 1 – Суммарное количество запросов к микросервисуApiGateWay за каждые 15 минут времени

1

Рис. 2 – Сравнение среднего времени выполнения запросак системе под управлением двух разных платформ

При этом в расчётах не учитывался показатель для микросервиса tn-fbl-notemanagement, который составил ~ 79,4 %. Такое сильное уменьшение не может быть связано с переводом проекта на новую платформу, и, скорее всего, имели место какие-то другие особенности работы системы, которые предстоит исследовать в дальнейшем.

 1 (2)

где:

ART – averageresponsetime (среднее время ответа сервера);

N – количество микросервисов, задействованных в тестировании и участвующих в итоговом расчёте.

Если говорить о конфигурации инфраструктуры, на базе которой проводилось нагрузочное тестирование, то в рамках данной работы промышленная система работала под управлением:

  • 4 VM под ~ 20 микросервисов (16 % от всей системы)
  • OS Rocky (Centos 8) на каждой VM
  • 12 GBRAM на каждую VM
  • 6 vCPU на каждую VM

Заключение

После перевода части микросервисов промышленного приложения на новую платформу .NET 6 и проведения нагрузочного тестирования, результаты по показателям среднего времени ответа от сервера соответствуют заявленным ожиданиям. Единственное, в дальнейшем нужно разобраться с данными, которые сильно выходят за границу среднего значения. Определить, что вызвало такие изменения.По итогу принято решение о дальнейшей миграции системы, используя выработанный шаблон перехода. В .NET 6 есть и собственный сервер GRPC на языке C#, и улучшенная работа технологии ReadyToRun, и keepalive пинги. С точки зрения эффективности работы нашей промышленной системы на разных платформах понятно, что платформа .NET 6 выглядит более привлекательно для дальнейшего исследования и изучения.

Конфликт интересов

Не указан.

Conflict of Interest

None declared.

Список литературы / References

1.Fowler M. Patterns of Enterprise Application Architecture. / M. Fowler. – Boston: Addison-Wesley Longman Publishing Co., Inc.,                 2002.– 576 p.

2.Evans E. Domain-Driven Design: Tacking Complexity in the Heart of Software. / E. Evans. –Addison-Wesley Longman Publishing Co., Inc.,2003. – 592 p.

3.Flygare R. Performance characteristics between monolithic and microservice-based systems. / R. Flygare. A. Holmqvist. // Bachelor’s Thesis, Faculty of Computing at Blekinge Institute of Technology. – 2017. – pp. 165–176.

4.Kubernetes as an availability manager for microservice applications. / L. A. Vayghan M. A. Saied, M. Toeroe et al. // arXiv preprint arXiv:1901.04946. – 2019.

5.JamshidiP. Pattern-based multi-cloud architecture migration. / P. Jamshidi, C. Pahl, N.C. Mendonca. // Softw.Pract.Exp.47. – 2017.

6.BalalaieА. Microservices architecture enables DevOps: migration to a cloud-native architecture. / A. Balalaie. A. Heydarnoori, P. Jamshidi. // IEEE Softw. 33. – 2016.

7.Mauro. T. Adopting Microservices at Netflix: Lessons for Architectural Design. [Electronic resource] URL: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/. (accessed: 10.06.2021).

8.Rodriguez M.A. Containers orchestration with cost-efficient autoscaling in cloud computing environments. / M. A. Rodriguez, R. Buyya // arXiv:1812.00300. – 2018.

9.What’s new in .NET 6. [Electronic resource] URL:https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-1. (accessed: 23.05.2021).

10.What’s new in .NET Core 3.1. [Electronic resource] URL:https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-6. (accessed: 14.10.2021).

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.