Разработка CPA-платформы для телеком-оператора

При этом мы рассмотрели лишь простейший сценарий, а у телеком-операторов их могут быть десятки и в них могут быть задействованы разные системы. Например, запрос может поступить с USSD-центра, IVR-центра, web-портала и т.д. Либо это может быть не разовый запрос на получение услуги, а подписка на услугу (в том числе в рассрочку), отписка от нее и т.д.

Когда мы начинали проект по созданию CPA-системы, то рассматривали несколько вариантов архитектуры платформы. При проектировании приложений такого масштаба в первую очередь нужно учитывать следующие моменты:

• Нагрузка на систему будет очень большой, т.е. она должна обрабатывать сотни достаточно сложных бизнес-сценариев в секунду. К этому следует добавить возможность простого горизонтального масштабирования системы при увеличении нагрузки.
• Класс систем такого типа – это business critical или mission critical, т.е. время простоя системы должно быть минимальным даже при внесении каких-либо изменений в нее (например, добавление новой функциональности или исправление каких-либо дефектов).
• Система должна легко и централизованно управляться. Должны быть четкие метрики, говорящие о ее текущем состоянии.
• Компоненты системы должны легко заменяться: в мобильной связи происходят настолько быстрые изменения, что сегодня вы взаимодействуете с одной системой по одному протоколу, а завтра с другой – по другому.
• Время разработки нового функционала и его тестирования должно быть минимальным, т.к. решающую роль играет такая вещь, как time to market.

Мы быстро осознали, что создание традиционной монолитной J2EE-архитектуры нам не подходит, т.к. не дает требуемой гибкости и не закрывает все потребности заказчика. Наш выбор остановился на модульной архитектуре на основе OSGi – Red Hat Jboss Fuse в конфигурации Fuse Fabric.

Нам нужно было построить такую архитектуру, в основе которой лежало бы взаимодействие различных автономных модулей на основе четко определенных интерфейсов, т.е. создать микросервисную архитектуру в текущем понимании этого термина (правда, на момент начала работ по созданию CPA-платформы слово «микросервисы» не было таким модным, как сейчас).

Отметим, что неправильно выбранная архитектура для систем такого уровня может привести к буквально катастрофическим последствиям как на этапе разработки и эксплуатации, так и на этапах дальнейшей доработки системы для расширения её функциональных возможностей. Нам требовалось как можно раньше показать заказчику так называемый proof of concept выбранной идеи и её жизнеспособность. И здесь на помощь пришла поддержка модульности в OSGi.

В основу проектирования системы мы положили API модулей, из которых она должна состоять, и BPM-процессы (бизнес-процессы, описанные с помощью стандартной нотации BPMN). Последние описывали бизнес-сценарии, которые выполняет CPA-платформа, в виде вызовов API модулей. Т.е. на начальном этапе мы имели модули (OSGi-наборы), которые, по сути, представляли собой микросервисы в виде «заглушек», выполняющие примитивные операции, и BPM-процессы, которые максимально приближенно к бизнес-сценариям телеком-оператора описывали последовательность вызовов OSGi-сервисов для достижения требуемого результата.

При этом мы понимали, что создаваемые нами OSGi-наборы будут вызываться как в BPM-сценариях, так и из других мест. Так, например, сервис для работы с каталогом услуг не только непосредственно вызывается из BPM-процессов, но и используется в back-office-системах для обеспечения возможности контент-менеджерам заводить, удалять, редактировать услуги. Также API сервисного каталога используется для предоставления списка услуг на сайте телеком-оператора. Сервис работы с биллинговой системой сначала использовался только в CPA-платформе, а сейчас, благодаря тому что он также доступен в виде REST-сервиса, его услугами пользуются и другие системы в инфраструктуре телеком-оператора.

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

Т.к. API наборов был согласован и зафиксирован, это дало нам возможность распараллелить процесс разработки каждого OSGi-набора. Т.е. отдельные команды могли заниматься разработкой какого-либо OSGi-набора. При этом одна команда разработки никак не влияла на другую, т.к. работала со своей кодовой базой и предметной областью. Все, что должно было быть соблюдено, – это ненарушение согласованного API-набора. Одна команда могла сосредоточиться на разработке партнёрского каталога, другая – сервиса бизнес-логирования и т.д. При этом архитектор следил за целостностью системы на основе согласованных API.

Для облегчения процесса отслеживания изменений API мы взяли на вооружение семантическое версионирование наборов OSGi. Этот подход предлагает использовать версии компонент в виде X.Y.Z, где X – мажорная версия, Y – минорная версия, Z – патч-версия. При этом версии увеличиваются по следующим правилам:

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

Это позволило нам видеть изменения API сервисов в рамках всей системы и управлять ими при выстраивании совместной работы сервисов.

При разработке сложных систем также требуется разрабатывать тесты на реализованный функционал. Т.к. взаимодействие компонентов в среде OSGi организовано путем вызова интерфейсов, это в значительной степени упрощает модульное тестирование. Если какой-либо сервис в нашем приложении обращается к другому сервису, на этапе тестирования тот сервис, к которому происходит обращение, мы можем легко заменять «заглушкой» для тестов. При этом при тестировании каждого модуля мы сосредотачиваемся именно на его специфике работы.

В процессе разработки мы понимали, что любой сервис в зависимости от характера нагрузки может стать узким местом всего приложения. Поэтому каждый вызов API какого-либо OSGi-набора был обернут метриками, которые были доступны по JMX-интерфейсу. Это позволило нам видеть максимальное время вызова какого-либо метода сервиса, усредненное за промежуток времени значение и характер изменения метрики. Данные метрики позволили нам сразу идентифицировать узкие места приложения во время нагрузочного тестирования, кроме того, они дали возможность наблюдать за продуктивной системой в режиме online и при деградации производительности оперативно принимать какие-либо решения по стабилизации системы. Например, мы можем перенести сервис на другой узел среды выполнения или вынести его в отдельную виртуальную машину Java. При этом OSGi позволяет нам выполнять все эти действия на работающей системе без влияния на остальные части приложения.

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

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

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