WebClub - Всероссийский Клуб Веб-разработчиков
WebClub.RU » Советы » Опыт проектирования и разработки банковской системы для трехуровневой архитектуры клиент-сервер. Какие подходы использовались

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


Дата публикации: 26-09-2010

1. Обеспечение максимальной надежности

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

Общий принцип состоял в том, чтобы критические участки комплекса использовали по возможности готовые решения. Так обстоит дело в обеспечении физической целостности базы данных (это задача СУБД) и в механизме передачи сообщений (тут работает монитор транзакций и протокол TCP/IP). К сожалению, пока у использовавшегося нами монитора транзакций отсутствует библиотека сопряжения со средой Java (хотя BEA SYSTEMS ведет работы над этой библиотекой), поэтому нам пришлось самим написать программные демоны для сопряжения программ на Java с сервером приложений и использовать эти демоны как временный вариант сопряжения.

Некоторое сомнение, с точки зрения надежности, у нас длительное время вызывала способность OpenIngres, в качестве опции, завершать транзакцию только в оперативной памяти и в журнале транзакций, откладывая реальную запись в область данных "до удобного случая" (режим FastCommit). Это примерно в 2 раза ускоряет работу быстрых транзакций (OLTP), но при внезапном отключении питания или сбое операционной системы (события, конечно, в нормальной конфигурации совершенно гипотетические), как мы подозревали, могло бы привести к потере последних завершенных транзакций или даже к нарушению целостности данных. Для исследования были искусственно вызваны многочисленные "падения" системы при различных условиях. Единственным следствием включенного режима FastCommit было несколько большее время, затрачиваемое системой при следующем после сбоя старте, так как при старте СУБД автоматически восстанавливает целостность баз данных, используя журнал транзакций, а в режиме FastCommit восстановление является более сложной задачей. В общем, мы пришли к выводу, что режим быстрых транзакций не ухудшает надежность системы.

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

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

На крайний случай, когда ничего не помогло и база данных непоправимо разрушена, обязана присутствовать страховая копия базы данных на независимом хранителе информации. Например на ленте. Система автоматически создает такую копию в ночное время. Мы считаем, что для коммерческого банка разумно иметь по отдельной копии на каждый день недели.

Что касается клиентского приложения, то, поскольку бесполезно добиваться надежной работы от программы, работающей под управлением MS Windows, вопрос надежности в этой области был решен радикально. Сбой клиентского приложения вообще не влияет на целостность базы данных и на работу остальных пользователей, так как клиентское приложение не взаимодействует напрямую с СУБД. Программа-клиент все необходимые манипуляции с данными осуществляет через "посредника" - сервер приложения. Контекст конкретного пользователя в СУБД не ведется, поэтому сбой в клиентском приложении никак не влияет на работу СУБД. В сервере приложения контекст клиента существует только в момент обработки запроса. Если клиентская программа перешла в ненормативный режим, следует просто осуществить ее перезагрузку.

Конечно, версии клиентского приложения для Win95 и, особенно, NT, работают заметно более стабильно. Значительно устойчивее клиентская программа работает и под управлением OS/2.

2. Обеспечение "прозрачного" выполнения всех корректных банковских операций

Для удовлетворения этого требования разработчикам пришлось погрузиться в детальный анализ алгоритмов бухгалтерии. Некоторые сложившиеся к тому времени стереотипы по поводу построения базы данных пришлось пересмотреть. Особые сложности возникли с внесением изменений в базу данных задним числом. Удалось построить структуру данных таким образом, чтобы подобные изменения корректно отрабатывались без всяких "откатов", что особенно важно в валютной части программы из-за усложнений, вносимых переоценками. Как следствие, система позволяет работать любому количеству пользователей в любом количестве операционных дней параллельно (конечно, "задним числом" могут работать только пользователи с достаточными полномочиями).

Необходимость исключить особые режимы работы и периоды технологических работ привела к построению сложной системы блокировок базы данных. Все действия в базе данных были разбиты на три крупные группы ("не требующие никаких блокировок", "требующие блокировки на чтение", "требующие блокировки на запись"), и в дальнейшем производилась настройка конкурентности запуска процессов из разных групп для исключения взаимного влияния. В результате все административные работы в СУБД выполняются на фоне обычной ежедневной работы.

CA-OpenIngres обладает развитыми системами блокировок, индексации и оптимизации. Имеется возможность для приложения динамически менять условия блокировки таблиц (уровень блокировки и ее степень, причем разные для разных таблиц), что позволяет программисту настраивать режимы работы приложения для обеспечения оптимальной конкурентности доступа. Кроме того, важным качеством является предоставление выбора наиболее оптимальных структур хранения данных для каждой из таблиц и для каждого вторичного индекса в базе данных: BTREE, ISAM, HASH или HEAP, а также средства прозрачного для приложения и для администратора сжатия хранимых на диске данных.

Недостаток использованной разработчиками СУБД - отсутствие средств для блокировки отдельной строки таблицы. Однако эта возможность на практике оказалась не очень нужна. Очень часто в банке различные пользователи блокируют на короткое время в исключительном режиме одни и те же данные. Например, при приеме документов от клиентов все операционисты одновременно переводят деньги со счетов клиентов на очень ограниченное множество промежуточных счетов (их не более, чем несколько). Поэтому часто различные операционисты пытаются заблокировать один и тот же счет. В таком случае попытка достичь конкурентности доступа путем блокирования на уровне строки не только ничего не дает, но и повышает вероятность создания условия для взаимной блокировки. Таких режимов работы в коммерческом банке большинство. Разработчики добивались конкурентности доступа путем особого проектирования сервера приложений. Однотипные запросы, которые, с большой вероятностью, будут мешать друг другу, выстраиваются сервером приложения в строгую очередь. Такие запросы максимально оптимизируются. Время их выполнения настолько мало, что для пользователей, например, вводящих документы, создается иллюзия одновременности обработки.

В ожидаемой в ближайшее время версии OpenIngres 2.0 возможность блокировки по строке уже будет реализована.

Ниже мы перечислим дополнительные приемы обеспечения максимальной независимости пользователей друг от друга.

а. Тщательное проектирование схемы данных. Это наиболее важный компонент. За счет совершенствования аппаратной платформы, СУБД, системного программного обеспечения можно добиться ускорения работы отдельных операций на десятки процентов, в лучшем случае - в несколько раз. А оптимизация структур данных может дать ускорение работы на порядок, а то и больше.

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

Поясним это на примере. Возьмем таблицу, содержащую документы системы. При создании модели хранения данных было принято решение включить в таблицу документов все поля, необходимые для основных типов документов. Т.е. в одной таблице хранятся данные и для, например, простых мемориальных ордеров, и для документов по конвертации валют (но, конечно, с разными значениями в поле "класс документа"). Каковы плюсы данного подхода? Во-первых, для программиста упрощается реализация простых однотипных операций над документами (проведение документа, разноска, отмена, удаление и т.п.). Эти операции делают просто одни и те же участки кода (или, в объектной модели, одни и те же методы корневых классов). Во-вторых, и для администратора упрощается процесс создания новых классов (на уровне средств run-time). Ему не нужно создавать новую таблицу для каждого класса, с большой вероятностью необходимые для нового класса элементы (столбцы) уже присутствуют в основной таблице. В-третьих, более эффективным становится процесс создания отчетов, и вот почему. В реляционной модели процесс соединения больших таблиц отнимает огромные ресурсы компьютера. Конечно, с помощью первичных и вторичных индексов можно оптимизировать эту операцию. Но тогда на администратора системы ложится тяжелая задача оптимизации схемы индексирования таблиц для конкретного набора созданных и используемых отчетов, от чего создателям системы хотелось бы максимально избавить администратора по соображениям гуманности. Поэтому схема индексирования была один раз подобрана для одной большой таблицы, и администраторам системы предложено пользоваться ей. Кроме того, в таком ненормализированном подходе уменьшается сама необходимость использования запросов с соединением таблиц. Несмотря на накладные расходы, связанные с необходимостью поддерживать и просматривать избыточные поля (столбцы) в таблице, это все же небольшая плата за исключение во многих случаях операции соединения больших таблиц.

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

Конечно, не стоит любую идея доводить до абсурда. Если в большой таблице, содержащей миллионы записей, необходимо хранить всего лишь тысячу документов, имеющих одно уникальное поле, не стоит расширять этим полем огромную таблицу. В системе имеется механизм "присоединенных таблиц", с помощью которого администратор может создать таблицу, содержащую дополнительные поля для какого-либо нового типа документа. Фактически, серверная программа эмулирует таблицу с переменным набором полей для различных строк таблицы. Для реализации такой сложной структуры данных применялся аппарат объектного программирования.

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

В общем, для определения структуры хранения данных было подобрано компромиссное решение, обеспечивающее, по нашему мнению, простоту, универсальность и эффективность.

Модель нижнего уровня хранения и обработки данных документооборота показана на рис. 2. Из рисунка видно, что программа-клиент и программа-сервер взаимодействуют с базой данных через интерпретатор модели документооборота (ИМД). Его работа базируется на определениях, записанных в специальных таблицах описаний классов документов (это таблицы классов, переходов, состояний, различных прав доступа, таблиц макросов и экранных форм). Этим достигается высокий уровень абстракции, позволяющий вынести конкретные правила поведения документов за пределы кода программы. Для такой модели естественно, что внешний вид различных документов тоже не "зашит" в код клиентской программы, она только использует спецификации, записанные в таблицы определений. Для работы с таким сложным механизмом у администратора системы имеется удобный графический инструментарий, позволяющий изменять содержимое таблиц определений классов и тестировать новые конфигурации.

 

В состав функций ИМД входит и поддержание логической целостности таблиц документооборота. Здесь появилась возможность отказаться от использования триггеров СУБД в их классическом виде, поскольку интерпретатор документооборота имеет монопольное право на обращение к таблицам СУБД, связанным с хранимыми документами. Триггеры удобны в многопользовательской среде, здесь же имеется лишь один "пользователь" - ИМД, несущий в себе все правила взаимодействий таблиц данных. Фактически, аналоги триггеров содержатся в таблицах описания документооборота, средства манипулирования ими вынесены на уровень клиентского места администратора системы. При этом мы ни в коем случае не считаем, что такое решение обязательно подходит для каких-либо других задач. Просто для данной конкретной задачи, на наш взгляд, такой подход оптимален. Отказ от использования собственных триггеров СУБД для поддержания логической целостности данных в случае двухуровневой архитектуры клиент-сервер мы считаем безусловной ошибкой. Да и в случае трехуровневого клиент-сервера мы бы не рекомендовали кому-либо сразу отказываться от поддержания логической целостности базы данных средствами самой СУБД. Наш вариант усложняет разработку и повышает вероятность ошибок в конечном продукте. Мы пошли на такой вариант ради повышения скорости работы серверного комплекса и для упрощения администрирования системы. Но это потребовало тщательного тестирования программы для избавления от ошибок поддержания целостности.

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

Еще следует заметить, что название "интерпретатор" не следует воспринимать "интерпретатор программного кода". Это обычная программа на С++, откомпилированная в машинные коды, эффективно использующая многопроцессорные конфигурации и являющаяся интерпретатором в том же смысле, в каком программа DOOM является интерпретатором "методики уничтожения живой враждебной силы". Поэтому не возникает вопроса об эффективности работы такой программы.

На рис. 3 показана логическая модель организации документооборота. Фактически эта модель соответствует тому, как работа с документооборотом выглядит для клиентской программы и для администратора системы.

 

Как мы видим, для программы-клиента и программы-сервера эмулируется виртуальная объектная СУБД, в качестве интерфейса имеющая такие команды, как "создать объект такого-то класса", "совершить переход объекта из состояния в состояние", "удалить объект", "вернуть полное описание объекта по идентификатору", "вернуть список описаний объектов с такими-то общими характеристиками". Данная модель, по нашему мнению, очень удобна как для дальнейшего развития системы, так и для расширения системы силами работников управления автоматизации конкретного банка.

Все программные интерфейсы системы управления документооборотом открыты, все алгоритмы интерпретации документооборота доступны изменению силами работников, сопровождающих систему.

Методологическая основа такого построения системы дана в работе [4]. Мы просто применили описанные в этой работе концепции для системы платежного документооборота.

Для оптимизации и структуризации алгоритмов доступа к табличной информации все таблицы в СУБД были разбиты на три большие группы.

Группа справочных таблиц. Включает в себя примерно 50 таблиц с настраиваемой справочной информацией. Это, как правило, небольшие таблицы (до 20 тыс. записей).

Группа "больших" таблиц. Это таблицы проводок, документов, счетов и др. (примерно 10 таблиц). Количество записей в таких таблицах планируется до десятков и сотен миллионов.

Группа избыточных таблиц. Содержит оперативно обновляемую информацию, не являющуюся необходимой для извлечения данных из СУБД, но ускоряющую такое извлечение на несколько порядков. Например, имеется таблица, содержащая в себе обороты и остатки по всем балансовым счетам второго порядка за все даты. Понятно, что при подсчете баланса использование этой таблицы многократно ускоряет отчет. Все эти таблицы обновляются в режиме on-line, что потребовало разработки сложных алгоритмов.

Для оптимизации работы СУБД с большими таблицами рекомендуется разбивать их на отдельные фрагменты, располагающиеся на физически различных дисковых пространствах. Это делается администратором системы, и такое разбиение является прозрачным для программ, работающих с подобными таблицами. Это означает, что, например, таблица документов может располагаться на 10 различных дисках, но SQL-запросы будут с этими данными работать как с единой таблицей. При этом многие операции над различными физическими пространствами СУБД выполняет параллельно, с использованием различных потоков ядра СУБД. Но следует заметить, что, по нашему мнению, основанному на практическом применении СУБД, реализация многопотоковости в OpenIngres 1.1 требует доработки. К моменту написания данной статьи мы еще не протестировали в полной мере версию 1.2 этой СУБД и не можем пока сказать, что этот недостаток устранен.

б. Передача SQL-запросов от приложения к СУБД происходит в оперативной памяти компьютера-сервера, а не по сети. Это сильно снижает накладные расходы системы на обмен информацией.

Составные (multistatement) транзакции требуют неоднократного обращения приложения к СУБД. Если такое приложение находится не на том же компьютере, на котором установлена СУБД, это вызывает необходимость неоднократного обращения к компьютерной сети в ходе обработки одной транзакции. Сетевое взаимодействие сильно уступает по скорости межпроцессному взаимодействию в современных операционных системах, даже если компьютеры соединены локальной (а не обычно медленной глобальной) сетью. Разработчики данного проекта предусматривали работу и в глобальной сети. В описываемой системе на каждую, даже сложную, транзакцию по сети передается только один небольшой пакет с данными от клиентского приложения к серверному. Сервер приложения, располагаясь на том же компьютере, что и СУБД, осуществляет весь обмен запросами с СУБД и отправляет клиентскому приложению конечный результат.

в. Широко применялось такое свойство СУБД, как возможность запоминать уже один раз "разобранные" и оптимизированные запросы, и при повторных вызовах однотипных запросов использовать эту информацию. Это повышает скорость выполнения OLTP-запросов в несколько раз.

г. Широко применялась всесторонняя индексация, с сильной избыточностью, больших таблиц базы данных. Большое количество индексов несколько снижает скорость выполнения OLTP- запросов, зато на порядки повышает скорость запросов анализа данных (DSS-запросы). Задача проектировщика - разработать оптимальную систему индексации таблиц приложения. Впоследствии, при доводке приложения, требуется тонкая ручная работа по окончательной настройке системы индексации.

3. Совместная работа валютного и рублевого управлений банка

Разработчики использовали схему многовалютной базы данных, при которой имеются независимые плоскости счетов для каждой из валют и все операции совершаются в рамках одной плоскости. Но такая общепринятая международная практика вступает в противоречие с используемыми в отечественной бухгалтерии алгоритмами, например, конвертации. Для решения этой проблемы нами было использовано понятие счетов-проекций для некоторых валютных счетов (например для группы 76-х счетов). В результате была получена возможность совершать любые требуемые операции, не нарушая при этом баланса по каждой отдельно взятой валюте.

4. Связь с филиалами

В системе были реализованы три различные стратегии обмена информацией между филиалами. Ниже мы их коротко опишем, в порядке убывания оперативности.

а. Филиалы, где возможна организация надежной связи в режиме on-line, имеют единую базу данных в одной территориальной точке и образуют некий "кластер", внутри которого информация циркулирует почти мгновенно. Для повышения надежности применяется дублирование линий связи. Нам представляется оптимальной для данного приложения конфигурация для каждого филиала с основной линией связи на 64 Кбит и линией-дублером на 19 Кбит.

б. В тех случаях, когда возможность соединения филиалов по протоколу TCP/IP есть, но надежность или скорость такой связи вызывает сомнения (слишком много теряется пакетов, часты разрывы или слишком узкая полоса пропускания сигнала), разумно держать в каждом филиале (или "кластере" филиалов из предыдущего примера) свою базу данных. Обмен информацией между такими филиалами будет происходить довольно редко, например для прохождения межфилиальных документов или для подсчета консолидированного баланса.

в. Если нет возможности установления связи между филиалами по протоколу TCP/IP, обмен информацией между филиалами происходит через электронную почту.

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

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

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

Программа-сервер является, с точки зрения программы-клиента, высокоуровневым сервером базы данных. Эта "СУБД" понимает и выполняет такие высокоуровневые команды, как "создать документ", "выполнить такой-то отчет" и т.п. В результате, например при вводе документа, по сети передается только один пакет, хотя в системе эта операция может вызвать сотни обращений к СУБД в случае сложной финансовой транзакции.

По предварительным расчетам, вычислительный центр в Москве на основе ЭВМ класса SPARCServer 6000 с процессорами UltraSPARC способен обеспечить работу в единой базе данных нескольких десятков филиалов и прохождение платежей из филиала в филиал в течение долей секунды. В нижней части спектра масштабируемости SPARCServer Ultra 2 обеспечивает работу 2-3 средних филиалов или 3-5 небольших отделений.

5. Открытость алгоритмов обработки данных

Для выполнения этой задачи применялись:

схема объектной организации документооборота;

настраиваемый план счетов;

настраиваемые способы ведения счетов.

6. Безопасность и контроль прав доступа

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

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

Поскольку все сервисы TUXEDO запускаются от имени одного системного пользователя, приложение не может прямо использовать присущую каждой конкретной СУБД систему секретности. Но это нетрудно обойти, используя механизмы ролей и схем и динамически, при обработке каждого запроса, подстраивая текущую роль или схему под конкретного пользователя.

Тот факт, что затруднено использование системы контроля СУБД, накладывает особую ответственность на приложение в области контроля прав пользователя.

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

Домен продается

Популярное

Не так давно в сети появился новый сервис, под названием Dead Man Zero. Этот сервис сделал...
Рынок социальных площадок уже давно стал стабильным. Несмотря на то, что время от времени...
Artisteer 4 – единственный в своем роде продукт, позволяющий автоматизировать работу над созданием...
Октябрь 2018 (14)
Февраль 2017 (3)
Январь 2017 (1)
Август 2016 (1)
Май 2016 (2)
Ноябрь 2015 (1)

Карта сайта: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41

Друзья сайта



Случайная цитата

Alan Kay:

"Lisp — это не язык, а строительный материал."

Опрос

Как Вам новый дизайн сайта?

Отлично
Неплохо
Нормальный
Ужасно