© 1995-2022 Компания «Инфосистемы Джет»
Разработка CPA-платформы для телеком-оператора на Fuse Fabric
Программное обеспечение Программное обеспечение

Ниже мы описываем пример использования модульного подхода к разработке в одном из наших проектов. Мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Мы также скажем о том, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.

Главная>Программное обеспечение>Разработка CPA-платформы для телеком-оператора
Программное обеспечение Тема номера

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

15.06.2016

Посетителей: 120

Просмотров: 108

Время просмотра: 2.3

Авторы

Автор
Роман Кичасов В прошлом - архитектор отдела разработки Центра программных решений компании «Инфосистемы Джет»
Ниже мы описываем пример использования модульного подхода к разработке в одном из наших проектов. Мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Мы также скажем о том, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.

 

 

CPA – это платформа для организации взаимодействия с контент-провайдерами, т.е. партнерами, которые предоставляют какие-либо услуги абонентам телеком-оператора. В качестве простейшего сценария можно рассмотреть ситуацию, когда абоненту требуется узнать погоду на завтра:

 

  1. Абонент отправляет SMS-сообщение на короткий номер для получения прогноза погоды;
  2. SMS-сообщение поступает в SMS-центр телеком-оператора;
  3. SMS-центр отправляет сообщение в CPA-платформу;
  4. CPA-платформа определяет услугу, привязанную к короткому номеру, определяет стоимость услуги, проверяет наличие на счету абонента достаточного количества средств, запрашивает у партнера, предоставляющего услугу, прогноз погоды, производит списание средств со счета абонента и протоколирование бизнес-операции, передает контент в SMS-центр для отправки абоненту;
  5. SMS-центр отправляет абоненту SMS-сообщение с погодой на завтра;
  6. Абонент получает SMS-сообщение.

 

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

При этом мы рассмотрели лишь простейший сценарий, а у телеком-операторов их могут быть десятки и в них могут быть задействованы разные системы. Например, запрос может поступить с 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-приложения – это, как правило, значительное количество времени, а значит, потери для компании.

Уведомления об обновлении тем – в вашей почте

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня