26
Сервера отделений не имеют доступа в интернет на прямую. Все действия по
внешнему взаимодействию происходят в защищенной сети VPN и через
специальные шлюзы. Весь трафик блокируется, кроме трафика JMS-сообщений.
Сервера в целях безопасности работают не прямыми запросами, а через
технологию JAVA EE – JMS. Так как аппаратным обеспечением занимается
компания IBM, то JMS реализован через IBM MQ.
BM MQ – Является частью промежуточного программного обеспечения,
обеспечивающее обмен сообщениями между клиентами. Сообщения – бинарные
данные, текстовые данные, содержащих некоторый смысл для приложений. При
передаче через MQ служебная информация удаляется.
ПТК «Клиентская служба» защищена с использованием защиты сервера
приложений и использованием нестандартного реестра пользователей. Защита
реализована как enterprise-приложение «Безопасность и управление доступом» и
состоит из двух частей. Первая часть является менеджером пользователей и
позволяет создавать и редактировать пользователей, их роли. Вторая часть
является непосредственно надстройкой защиты сервера приложений IBM
WebSphere AS 7. Сервер приложений при доступе к любому ресурсу проверяет
идентификатор пользователя, если он отсутствует перенаправляет на страницу
входа, где после ввода пользователем логин / пароля, передает управление
надстройке. Надстройка проверяет логин/пароль по своей базе данных, в таблицах
которой хранятся данные о пользователе, извлекает его роль. После того как
пользователь прошел аутентификацию, проверяется авторизация пользователя к
данному ресурсу. Политика доступа хранится в файле web.xml, где указывается
доступ на уровне ролей пользователя.
1.3 Анализ существующих разработок и выбор стратегии автоматизации
«КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Как было указано выше за помощь в приеме заявлений отвечает подсистема
«Учет обращений». В данной подсистеме происходит регистрация обращений
граждан. Данные записываются в региональную базу данных. Регионы не имеют
27
доступа к базам данных других регионов, и даже если бы имели, то на поиск
обращения гражданина, было бы потрачено слишком много времени.
Следует рассмотреть на аналитическо-техническом уровне структуру
подсистемы «Учет Обращений»:
База Данных. База данных состоит из огромного числа таблиц. При
сохранении используется по меньшей мере шесть таблиц, связанных между
собой. Для создания новой регистрационной экранной формы используется
девять таблиц, не считая запросов к справочникам, количество которых может
достигать двадцати. Таблицы баз данных не способны к секционированию [16],
поэтому выборка из таких баз данных затруднена. Ошибка! Источник ссылки
не найден.
Минусы такой структуры очевидны:
При сохранении используется много таблиц запись в которые происходит в
рамках одной транзакции. При неудачном стечении обстоятельств такой подход
может вызвать (и вызывает) блокировки таблиц/строк для других процессов.
При построении новой формы регистрации используется чтение множества
таблиц. При создании формы регистрации используется сложный механизм,
построенный на конкатенации строк html-разметки и js-кода. Так как форма
регистрации насчитывает минимум 100 компонентов на форме регистрации
запрос в БД происходит для каждого компонента.
28
Рисунок 4 Структура базы данных подсистемы «Учет Обращений»
Получение данных по регистрации аналогично сохранению регистрации
затрагивает большое число таблиц на чтение. Дополнительные таблицы читаются
все сразу в попытке определить в каких содержаться данные по регистрации. При
редактировании обращения к дополнительной нагрузке относится построение
формы регистрации, описанной выше.
При большом количестве регистраций разрастается таблица
R_COMPONENTS_VALUE, что приводит к торможению выборки. Как было
сказано ранее СУБД регионов не поддерживают секционирование, из-за чего
приходится применять самодельную систему архивирования - перенос
регистрационных данных со всеми зависимостями в другую таблицу, другого
табличного пространства. Перенос очень ресурсоемкий и вызывает
взаимоблокировки, если момент архивации сопровождается параллельным
процессом регистрации.
Следует отметить метрики, снятые со стенда регистраций в процессе
тестирования. Максимальное время выполнения 8356мс. при облегченной
регистрации является недопустимым.
Так же следует отметить рассмотреть программную архитектуру приложения
изображенную на Ошибка! Источник ссылки не найден..
29
Рисунок 5 Архитектура подсистемы «Учет Обращений»
Как несложно заметить запрос каждого ресурса, статического или
динамического направляется серверу приложений. Многочисленные нити веб-
контейнера генерируют нагрузку на сервер приложений и вызывают блокировки.
Множество не систематизированных скриптов JS хранящихся в отдельных
файлах, действия которых сложно предугадать и еще сложнее отлаживать.
Сервер приложений работает на устаревшей JAVA 6. На текущий момент
Oracle представила миру JAVA 10. Обновление JAVA является критическим, так
как в обновленных версиях улучшается не только быстродействие, так и
уязвимости, и баги. Покупка обновленного сервера приложений невозможна по
экономическим соображениям.
В качестве ОРМ используется устаревшая библиотека DataNucleus.
Поддержка данной версии прекращена, переход на новую невозможен из-за
аппаратных и программных ограничений.
Запросы к БД не кэшируются. Частые обращения к БД генерируют нагрузку
на БД, вызывают взаимные блокировки и как следствие повисание всего
комплекса.
Не экономичный расход аппаратных ресурсов. HTML и JS генерируются
путем конкатенации строк. Много статических классов и переменных, которые
расходуют память, наблюдаются множественные утечки памяти, источник
которых сложно детерминировать. Непрактичный код, который сложно
поддерживать.
Сложные алгоритмы построения веб-форм использующие многочисленные
запросы к БД.
30
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Главной задачей разрабатываемого приложения должно являться
централизованная регистрация обращений граждан в ПФРФ. Следует выделить
основные требования к разрабатываемой системе:
1. Скорость обработки информации. Под скоростью обработки информации
следует понимать время работы с информацией, подлежащей сохранению в базу
данных, выборка из базы данных конкретного обращения гражданина, поиск в
базе данных граждан и их обращений.
2. Надежность. Под надежностью информации подразумевается безотказная
работа приложения. Способность сохранять информацию, хранить,
восстанавливать в случае сбоя аппаратных средств, безотказность работы с
информацией.
3. Юзабилити(Эргономичность). Способность программы быть понимаемой,
изучаемой, используемой и привлекательной для пользователя в части
регистрации заявлений.
4. Кроссплатформенность. Возможность работать с программой на любом
устройстве, любой операционной среде. Благодаря кроссплатформенности, прием
заявлений можно не ограничивать приемом лично специалистом.
Проведя исследование существующих бизнес-процессов внутри подсистемы
«Учет обращений», можно достичь увеличение скорости. Скорость обработки
информации будет достигаться за счет: избавлении системы от «паразитной»
нагрузки, оптимизируя технологические процессы внутри, подбором
архитектуры и максимально совместимого программного обеспечения.
Надежность будет достигаться правильной архитектурой и правильной
работой с базой, присущей высоконагруженным системам. Предполагается
развертывание программного комплекса на федеральном уровне. И организация
его в отказоустойчивый кластер.
Юзабилити – простота и однотипность управления призваны сделать новый
продукт более отзывчивым для пользователя. В текущей реализации «Учета
Обращений» нет понимания об интерфейсе, нет единого и ожидаемого поведения
системы, нет общей дизайн-концепции.
31
Кроссплатформенность - текущая версия «Клиентская служба» не является
кроссплатформенной, она предназначена только для той операционной системе, в
которой возможен запуск проприетарного сервера приложений IBM WebShere 7й
версии [23].
Разрабатываемое приложение должно является кроссплатформенным,
способным функционировать там, где возможен запуск JAVA, то есть это
практически все операционные системы. Клиентской часть должна запуститься в
любом браузере любого устройства.
1.3.3. Выбор и обоснование способа приобретения ИС для
автоматизации задачи
Разрабатываемое приложение, автоматизирующее прием заявок пенсионным
фондом РФ, требует:
Операционная система Linux CentOS, предназначенная для
функционирования на сервере приложений и сервере баз данных.
Операционная система Linux Ubuntu (Debian, Mint) – функционирующая на
клиентских станциях. Возможно использование купленных операционных
система Windows 7.
СУБД PostgreSql для обеспечения хранения базы данных заявлений,
справочников.
Система построена на клиент-серверной архитектуре. Поэтому подключение
к централизованному серверу является обязательным условием. На серверах
будут установлены программные сервера управления и хранения информацией.
Так на сервер будет приходится значительная нагрузка, то требуется
ограничится выбором серверной операционной системы, то есть той системы,
которая была разработана специально для этого. В данном случае предлагается
использовать Linux CentOs. Данная операционная система основана на
коммерческом дистрибутиве Red Hat и совместима с ним. CentOs предоставляет
повышенный уровень безопасности, высокую производительность, не
накладывает ограничения дискового пространства, позволяет производить тонкие
настройки, стабильна в работе, простота обновлений [13]. Дистрибутив Linux
CentOs, как зарекомендованную во всем мире операционную систему.
32
Требования к клиентским компьютерам значительно ниже и требуют любую
операционную систему позволяющую запускать окно браузера. Операционные
системы Windows или Linux.
Так как представленные компоненты являются бесплатными к
распространению, а также обладают достаточной надежностью, то
необходимость закупки дополнительного программного обеспечения
отсутствует.
В качестве сервера могут использоваться уже существующие сервера,
расположенные в крупных регионах. В клиентской части, так же существуют
установленные на рабочих места компьютеры, которые обладают
предъявленными к ним требованиями. Исходя из вышесказанного можно сказать,
что закупка новых аппаратных средств не требуется.
Единственным условием является перенос серверов на необходимые
площадки. А также настройка и установка необходимых операционных сред,
конфигурирование локальной сети.
Таким образом для разработки и внедрения новой системы автоматизации
приема заявок Пенсионным фондом РФ, не требуется производить
дополнительных закупок. Требуется только разместить сервера на площадках.
1.4. Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному
обеспечению
Программное решение предлагается выполнить согласно классическому
паттерну высоконагруженных систем «Трехзвенная архитектура» [22]. На
Ошибка! Источник ссылки не найден. изображена принципиальная схема
архитектуры приложения.
Рисунок 6 Структура архитектуры и способы взаимодействия между звеньями
Серверную предлагается реализовать в виде самостоятельных модулей, с
открытым доступом к функциональной части. Ошибка! Источник ссылки не
найден..
Клиент
Rest
Сервер
JDBC
База данных
33
В отличии от существующей структуры «Клиентской службы», архитектура
проектного приложения делит контент на статический и динамический.
Статический контент запрашивается из кэша легковесного сервера, который легко
разворачиваться в отделениях. Динамический контент запрашивается с
централизованного сервера, по средствам rest-запросов. Сервер обращается к
кэшу библиотеки реляционного маппинга и извлекает все справочники из кэша,
тем самым еще больше снижая нагрузку на базу данных. Ошибка! Источник
ссылки не найден. иллюстрирует архитектуру разрабатываемого решения
Рисунок 7 Архитектура проектного решения
Предлагаемое модульное разделение предполагается реализовать следующим
образом:
1. Регистрация обращений: создание, редактирование, удаление, просмотр,
аннулирование
2. Поиск: по СНИЛС, по Анкетным Данным, по Документу,
удостоверяющему личность
3. Статистика: по Регионам, по Операторам, по Тематикам
4. Интеграция: отправка в целевую подсистему, прием данных из целевой
подсистемы
5. Конфигурация и управление: настройка справочников, настройка
пользователей
6. Генерация экранных форм: менеджер форм в формате JSON
7. Работа со справочниками: просмотр, редактирование, синхронизация
8. Печатные формы: генератор печатных форм
34
1.4.2 Обоснование проектных решений по программному обеспечению
Федеральный закон "О контрактной системе в сфере закупок товаров, работ,
услуг для обеспечения государственных и муниципальных нужд" №44 от
05.04.2013[4], предусматривает: В целях защиты основ конституционного строя,
обеспечения обороны страны и безопасности государства, защиты внутреннего
рынка Российской Федерации, развития национальной экономики, поддержки
российских товаропроизводителей нормативными правовыми актами
Правительства Российской Федерации устанавливаются запрет на допуск
товаров, происходящих из иностранных государств, работ, услуг, соответственно
выполняемых, оказываемых иностранными лицами, и ограничения допуска
указанных товаров, работ, услуг для целей осуществления закупок. В случае, если
указанными нормативными правовыми актами Правительства Российской
Федерации предусмотрены обстоятельства, допускающие исключения из
установленных в соответствии с настоящей частью запрета или ограничений,
заказчики при наличии указанных обстоятельств обязаны разместить в единой
информационной системе обоснование невозможности соблюдения указанных
запрета или ограничений. Порядок подготовки и размещения обоснования
невозможности соблюдения указанных запрета или ограничений в единой
информационной системе, а также требования к его содержанию устанавливаются
Правительством Российской Федерации. Определение страны происхождения
указанных товаров осуществляется в соответствии с законодательством
Российской Федерации.
Для реализации вышеописанных полномочий Правительство и Министерство
экономического развития установили запреты и ограничения при закупке
некоторых категорий товаров. В этот список входит и программное обеспечение.
Исходя из вышесказанного предполагается отдать приоритет продуктам,
произведенным на Российском рынке или продукты российских разработчиков.
База данных. Требования к СУБД являются основополагающими к качеству
системы. СУБД должна выдерживать работу с большим количеством
пользователей, уметь осуществлять выборку среди миллионов записей,
гарантировать сохранность данных. Исходя из этих требований стоит выделить
35
ключевые моменты: надежность, скорость работы, возможность
секционирования.
Рассмотрим данные тестирования СУБД [21], приведенные компанией
«Индиго-ИТ» изображенные на Ошибка! Источник ссылки не найден..
Рисунок 8 Данные тестирования современных СУБД
PostgreSQL распространяется по модели open-source, то есть свободно
распространяемое программное обеспечение. Исходя из этой модели, становится
возможным обновлять данную СУБД без дополнительных затрат. PostgreSQL
считается отличным импортозамещением. В развитии PostgreSQL существенную
роль играют отечественные специалисты. Согласно оценкам компании Postgres
Professional, на их долю приходится более 10% строк в исходных текстах,
благодаря их усилиям были созданы или развиваются важнейшие подсистемы
СУБД.
PostgreSQL поддерживает два различных типа секционирования, для
хранения большого объема данных: Декларативное секционирование и
секционирование с использованием наследования [19].
Для скорости построения экранных форм, предполагается хранить данные
структуры формы в формате JSON. PostgreSQL предоставляет тип данных JSONB,
которые позволяет хранить и индексировать JSON данные [23]. При этом выборка
из таких данных превышает по скорости NOSQL базы данных [7].
Исходя из стоимости (точнее ее отсутствия), скорости, надежности,
поддержки секционирования и ФЗ №44 вышесказанного предлагается
использовать PostgreSQL в качестве СУБД.
Так как архитектура предполагает наличие двух серверов, для клиентского
приложения и сервера приложений (слой бизнес-данных), стоит рассмотреть
выбор обоих.
К серверу клиентского сервера предъявляются требования скорости, умение
кешировать запросы на статические ресурсы. Под статическими ресурсами