РАЗРАБОТКА МИКРОСЕРВИСА ИНТЕГРАЦИИ СИСТЕМЫ САМООБСЛУЖИВАНИЯ АБОНЕНТОВ СОТОВОЙ СВЯЗИ И ЦЕНТРА НОТИФИКАЦИЙ В РАМКАХ ПЕРЕХОДА ОТ МОНОЛИТНОЙ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ К МИКРОСЕРВИСНОЙ

DEVELOPMENT OF MICROSERVICE FOR INTEGRATION OF SELFCARE SYSTEM FOR MOBILE USERS AND NOTIFICATION CENTER AS PART OF TRANSITION BETWEEN MONOLITHIC- AND MICROSERVICE-STYLED APPLICATION ARCHITECTURES

Nadezhda Osipova

junior QA engineer, ALM Works Ltd,

Russia, Saint-Petersburg

АННОТАЦИЯ

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

ABSTRACT

The article discusses the pros and cons of monolithic and microservice styles to software development and decision criterion for transition to microservice architecture through the example of developed integration microservice.

Ключевые слова: микросервисы; монолитная архитектура.

Keywords: microservices; monolithic architecture.

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

В то время, когда начали создаваться первые системы самообслуживания, такое понятие как «микросервис» еще не существовало в словаре информационных технологий (впервые термин «микро-веб-сервис» был употреблен Питером Роджерсом на конференции Cloud Compution Expo в 2005 году [2]). Когда проект по разработке программного обеспечения доходил до стадии проектирования архитектуры программного кода, практически единственным вариантом выбора являлась монолитная архитектура приложения. В чем же ее особенности и почему понадобилось изобретать новые виды архитектуры?

Монолитное приложение – это один большой связанный модуль, в котором все компоненты спроектированы для работы друг с другом. У этих компонентов общие ресурсы, общая память и основной задачей разработчиков таких приложений является правильная организация доступа каждого из компонентов к памяти и ресурсам. Как правило веб-приложения на основе монолитной архитектуры построены на трёхзвенной архитектуре – сервер приложений обрабатывает HTTP-запросы и выполняет доменную логику, база данных по запросу сервера приложений отдает или обновляет данные, а затем заполненные сервером приложений HTML-страницы отправляются браузеру клиента.

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

Первой – и, пожалуй, основной для современного разработчика, - проблемой является то, что иногда возникает необходимость передать работу над проектом другой команде. Что происходит? Есть команда, которая много лет своими руками растила это приложение, добавляла килобайт за килобайтом новую функциональность и знает о каждом подводном камне и тонкостях разработки новых функций и их взаимодействия со старыми. И есть команда, которая получает в свое распоряжение массу непонятного программного кода, в котором за эти годы полностью пропала обоснованная структурность, используемые технологии устарели и на анализ того, что вообще нужно сделать в рамках текущей разработки, уйдут недели труда даже самого опытного разработчика. И несмотря на то, что менеджеры по подбору персонала будут утверждать, что хорошему разработчику любой код – не помеха, переход к этому приложению для новой команды будет большим (и абсолютно неоправданным) стрессом. Таким образом образуется простой в работе над приложением, который может принести большие убытки компании-разработчику.

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

Третье проблемой (которая вытекает из второй) является абсолютное отсутствие масштабируемости монолитного приложения. Любые изменения, пусть даже самые небольшие, требуют полной пересборки и развертывания новой версии серверной части приложения (крупные компании не могут себе позволить часто устраивать такой «простой» приложения; это несет за собой огромные убытки). Одновременно маленькие изменения одного модуля этого приложения могут привести к необходимости вносить крупные изменения в смежные модули.

Все эти проблемы привели к созданию нового вида архитектуры программных приложений – микросервисной архитектуре.

Микросервисная архитектура приложения представляет собой набор сервисов, каждый из которых работает независимо в своем собственном процессе, сообщаясь с остальными при помощи различных легковесных механизмов, например, через HTTP. Каждый из этих сервисов строится вокруг бизнес-потребностей приложения [1] и выполняет определенную роль, не пересекающуюся с ролями остальных сервисов. Микросервисы разворачиваются независимо друг от друга с использованием полностью автоматизированной среды. У каждого микросервиса имеются свои ресурсы и данные. Эти сервисы настолько независимы друг от друга, что могут с легкостью быть написаны на разных языках программирования. Более того, разрабатывать их могут разные команды.

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

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

Проект включает в себя следующие задачи:

• Проведение анализа предметной области, выявление плюсов и минусов монолитной и микросервисной архитектур применительно к этой области и в случае значительных преимуществ со стороны микросервисной архитектуры, принятие решения о необходимости перехода
• Разбиение системы на логически завершенные части, каждая из которых может быть реализована в виде микросервиса, выполняющего одну определенную бизнес-функцию и имеющего возможность работать независимо от других
• Составление списка требований для каждой из частей с учетом современного состава и архитектур систем, с которыми микросервисы будут проинтегрированы
• Последовательная разработка каждой из частей с учетом всех функциональных и нефункциональных требований
• Проведение тестирования на всех уровнях с уделением особого внимания нагрузочному тестированию; нагрузочное тестирование желательно автоматизировать
• Проведение пилотного внедрения для каждой из частей на мощности заказчика, сопровождая его подробным анализом с целью определения успешности повышения масштабируемости и стрессоустойчивости

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

В качестве обоснования актуальности разработки были использованы следующие аргументы:

• Монолитная архитектура для enterprise-решения сложна в использовании, поскольку каждое изменение (которых происходит не менее 10-15 за квартал) приводит к необходимости пересборки серверной части и развертывания нового экземпляра продукта, а при нарушении работоспособности одной части возникают проблемы во всех связанных частях системы. Компании, для которых системы самообслуживания востребованы 24 часа в сутки и приносят большую часть дохода, не могут позволить себе для малейшего изменения останавливать всю инфраструктуру; такие действия приводят к значительным финансовым и имиджевым потерям. Поэтому переход на систему независимых микросервисов должен обеспечить большую стрессоустойчивость и масштабируемость
• Разработка позволит существенно снизить срок, необходимый для заказанных доработок, поскольку в рамках микросервисной архитектуры проводить доработки в случае дефицита времени сможет не одна команда, отвечающая за систему, а любые специалисты предприятия-разработчика
• Переход к микросервисной архитектуре позволит значительно снизить затраты на тестирование разработки, поскольку размер микросервиса позволяет опустить unit-тестирование

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

1. Микросервисы (Microservices) // Хабрахабр. – 2015. – [Электронный ресурс] – Режим доступа. – URL: https://habrahabr.ru/post/249183/ (дата обращения 06.05.2017)
2. A Quick Primer on Microservices // Cloud Computing Expo. – 2016. – [Электронный ресурс] – Режим доступа. – URL: http://www.cloudcomputingexpo.com/node/3675288 (дата обращения 06.05.2017)