Успешно завершен очередной этап разработки "Концентратора услуг"

Планы 2015

В 2015 году планировалось запустить уже семь услуг в дополнение к одной реализованной (запись в детские сады). Поэтому в рамках развития “Концентратора услуг” перед командой стояла задача увеличить масштабирование системы, но сохранить при этом обратную совместимость с уже поддерживаемой функциональностью и региональными системами.

Автодиагностика и автоматические оповещения

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

Еще одно значимое улучшение – автоматическая система оповещений. В версии “Концентратора услуг” 2014 года в продуктивном контуре было подключено приблизительно 120 региональных систем на одну услугу. В 2015 году услуг должно было стать в 7 раз больше, что могло привести к подключению до 800 внешних систем. Если учесть, что региональная система приема заявок и региональная система предварительной записи это, по факту, две независимые подсистемы, то количество подключений могло достичь 1500 систем. 

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

Повышаем масштабируемость: база данных 

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

В базе данных было выявлено, что аудит трафика (требование по ТЗ) существенно нагружал узлы PostgreSQL, участвовавшие в репликации, поэтому при достижении некоторого порога скорость работы опускалась до критических значений. Согласно требованиям, модуль аудита должен сохранять каждый входящий и исходящий пакет из “Концентратора услуг”, большая часть которых занимает размер от 1 до 10 Мб. Такой трафик замедлял работу всей реляционной БД, так как буфер для репликации единый. Для решения это задачи мы добавили в архитектуру инсталляцию Basho RIAK (key-value NoSQL DB), оптимизированную под хранение контента требуемого объема. В результате модуль аудита при превышении размера пакета (>50Кб) сохраняет пакет в RIAK, а в таблицу (PostgreSQL) аудита – ссылку на запись в RIAK. Такой подход позволил значительно разгрузить реляционную БД.

Сервер очередей: повышение нагрузок

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

Командой разработки были протестированы многие современные решения очередей и по сумме всех критериев было принято решение использовать Apache ActiveMQ. Миграция на новый сервер прошла безболезнено, так как большая часть работы с HornetQ шла через абстракции Java Spring и весь функционал был покрыт юнит- и интеграционными тестами. Также было разработано утилитарное приложение для миграции данных существующей очереди из HornetQ в ActiveMQ с учетом специфики типов серверов.

Обработка очередей 

Еще одно значительное улучшение масштабируемости – изменение алгоритма обработки очередей. Стандартное поведение JMS приводило к ситуации, когда все узлы кластера приложения конкурируют за все очереди одновременно, что снижало эффективность работы всей системы (с учетом факта, что большинство очередей должны быть обработаны в строгом соответствии с порядком поступления заявок).  В худшем случае, один узел кластера мог захватить все очереди и не давать обрабатывать пакеты остальным. Для решения этой задачи команда разработки создала новый механизм балансировки поверх механизма работы с очередью. Отличительной особенностью реализации является возможность активной ребалансировки при потере одного из узлов – heartbeat timeout. Такое решение позволило поддержать справедливую и предсказуемую балансировку с равномерным распределением задач по ресурсам с учетом специфики “Концентратора услуг”.

Эксплуатация

Благодаря слаженной командной работе с эксплуатацией РТЛабс новая версия была выведена на продуктивный контур в короткие сроки. Миграционные инкрементальные SQL скрипты, обратная совместимость с предыдущей версией и полное покрытие функциональности авто тестами позволило значительно снизить риски установки очередного обновления.

Технологический стек “Концентратора услуг”:

Core: Java, Tomcat, Spring, Flyway

Security: Spring Security, CryptoPro JCP

DataAccess: JPA, Spring Data, Hibernate

Storage: PostgreSQL, Basho RIAK KV

JMS: Apache ActiveMQ

Web UI: Spring MVC, Thymeleaf, jQuery, Bootstrap 3+

Testing: JUnit, Mockito, Hamcrest

Build: Maven

CI: TeamCity

Monitoring: Zabbix

Компания WaveAccess специализируется на аутсорсинге и разработке программного обеспечения, в т.ч. сложных, интегрированных информационных систем федерального масштаба. 
Если вам требуется разработка похожего проекта, или на текущем проекте возникли сложности с интеграцией и масштабируемостью систем, напишите нам на hello@wave-access.com.