плохих» каналов связи

ОПТИМИЗАЦИЯ СТРУКТУРЫ РОЗНИЧНОГО
МОДУЛЯ АВТОМАТИЗИРОВАННОЙ
БАНКОВСКОЙ СИСТЕМЫ ДЛЯ РАБОТЫ В
УСЛОВИЯХ «ПЛОХИХ» КАНАЛОВ СВЯЗИ
Магистерская диссертация
Студента МФТИ (ГУ), 518 гр.
Бычкова Александра Сергеевича
Научный руководитель,
Кандидат технических наук
Майданюк Роман Андронович
На примере АБС «SNOVA»
ОСНОВНЫЕ ЗАДАЧИ
 Максимальное снижение требований к каналам
связи
 Поддержка частичного функционирования ПО при
отсутствии связи с сервером приложений
 Увеличение скорости развёртывание и настройки
рабочего места
 Увеличение надёжности клиентского приложения
за счет минимизации сетевого обмена
 Снижение репутационных рисков, связанных с
отказом IT подсистем банка
ВЫБОР СРЕДСТВ
РАЗРАБОТКИ
Основные факторы, повлиявшие на выбор средств разработки
 Минимизация затрат на разработку графического
интерфейса
 «Дружелюбная» среда разработки
 Поддержка платформы со стороны разработчика
 Плотная интеграция с MS Office
 Широкий функционал библиотеки для работы с СУБД
 Простота разработки веб-сервисов
ИСПОЛЬЗУЕМЫЕ ТЕХНОЛОГИ
В качестве программной платформы для разработки была
выбрана технология компании Microsoft .NET Framework 4.0
 Пользовательский интерфейс реализован на WPF
 Подсистемы сервера приложений – VB.NET и C#
 Взаимодействие с СУБД – собственная библиотека,
использующая ADO.NET в качестве провайдера СУБД
 Разработка бизнес-логики - Windows Workflow Foundation
(WF)
 СУБД – Microsoft SQL Server 2008 x64
ОБЩАЯ СХЕМА ВЗАИМОДЕЙСТВИЯ
СОСТАВ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ
СЕРВИС ПРОВЕДЕНИЯ ОПЕРАЦИЙ
Этапы online проведения
Этапы offline проведения

Сохранение параметров операции в
глобальном буфере операций
•
Сохранение параметров операции в
локальном буфере операций

Синхронный запуск проведения
•

Ожидания результата проведения
Доставка параметров операции в
глобальный буфер операций
средствами транспортного модуля

Получение статуса проведения
•
Асинхронный запуск проведения

В случае успеха, получение данных
•
Проверка не проведённых операций
•
Удаление из глобального буфера
тех операций, которые не удалось
провести за определённое
количество попыток
РЕАЛИЗАЦИЯ СЕРВИСА ПРОВЕДЕНИЯ ОПЕРАЦИЙ
• Сервис проведения платежей реализован как набор веб-сервисов.
• Каждый запрос на проведения операции обрабатывается в
отдельном потоке.
• Все сервисы описаны с помощью языка WSDL
• Каждый запущенный поток непрерывно протоколируется, что
позволяет в реальном времени отслеживать состояние системы
• Поддерживаются синхронный и асинхронный режим проведения
• Сервис имеет набор гибких настроек, позволяющих
минимизировать вмешательство разработчиков в работу системы
• В сервис проведения интегрирована система протоколирования
ОРГАНИЗАЦИЯ ТРАНСПОРТНОГО МОДУЛЯ
Параметры любой операции или запроса сериализуются в XML
документ.
XML документ передаётся шлюзу транспортного модуля
посредством HTTP - протокола метод POST, используя метод
сжатия zlib.
Аналогичным образом реализована передача данных,
являющихся результатом выполнения операции или запроса.
После получения данных происходит преобразование XML
документа во внутренние объекты клиентского приложения.
В результате размер отправляемого пакета не превышает 3kb,
размер получаемого пакета (в среднем), не превышает 7kb.
ПОДДЕРЖКА ЛОКАЛЬНЫХ СПРАВОЧНИКОВ В
АКТУАЛЬНОМ СОСТОЯНИИ
Обновление локальных справочников происходит
централизованно при помощью программного модуля,
размещенного на выделенном сервере.
Поддерживаются следующие режимы
 Синхронное разностное обновление
 Разностное обновление по расписанию
 Полное обновление справочника
 Разностное обновление по запросы из клиентского приложения
Любая попытка обновления и результат обновления справочника
протоколируется. Система оповещает о неоднократных неудачных
попытках обеления справочников, что обеспечивает контроль в реальном
времени
ПРЕДВАРИТЕЛЬНАЯ АВТОРИЗАЦИЯ ОПЕРАЦИЙ
В случае отсутствия доступа к центральному серверу
существует возможность получить код авторизации на
конкретную операцию.
В случае запроса авторизации на стороне АБС регистрируется
факт запроса авторизации, после чего генерируется
уникальный код. Клиентское приложение при получении
корректного кода авторизации позволяет исполнить в
«локальном» режиме операцию, требующую для исполнения
доступа к центральному серверу.
Как только связь с сервером будет установлена, операция
будет доставлена в шлюз проведения автоматически.
Процесс авторизации операции
ОБЪЕМЫ И СРОКИ
•
На проектирование архитектуры приложения ушло 2 месяца
•
На программирование было отведено 14 000 человеко-часов
•
Было написано более 100 000 строк кода на .NET и более 5 000 на T-SQL
•
Количество объектов в СУБД около 2 000 штук
•
Отладка приложения заняла 3 недели + 2 недели функционирования в
«облегченном» варианте
•
В разработке приложения участвовали 4 человека
•
На данные момент система обрабатывает 20 000 операций в сутки
•
В результате внедрения было автоматизировано более 100 бизнес – процессов
розничной сети банка
•
Расчетная нагрузка при сохранении текущих бизнес-процессов – 150 000
операций в сутки
РЕЗУЛЬТАТЫ
После внедрения данной разработки были получены следующие результаты
1.
Количество отказов, вызванных проблемами с каналами связи, сократилось на
60 процентов
2.
Нагрузка на центральный сервер СУБД снизилась на 15 процентов
3.
Значительно снизилась нагрузка на ЛВС банка
4.
Время развертывания и настройки нового рабочего не превышает 10 минут
5.
Значительно снизилась трудоёмкость интеграции различных IT подсистем в
операционный день банка
6.
Суточный IP трафик на одно рабочее место не превышает 10 мегабайт
7.
Сократилось время, затрачиваемое на выявление ошибок, благодаря системе
логирования сервиса проведения операций