Торговая платформа НП РТС: задачи, архитектура

и подход к тестированию

14/11Кострома

Сергей Замолоцких

НП РТС

НП РТС основано в 1995 году и до декабря 2011 года было частью биржевой группы РТС.

Члены НП РТС – более 100 компаний, в том числе ведущих брокеров и дилеров на российском рынке.

НП РТС ставит своей целью развитие инфраструктуры российского финансового рынка.

2

НП РТС

К концу 2012 года НП РТС подготовила инфраструктуру для создания биржевой группы - ОАО «Санкт-петербургская биржа» и ОАО «Клиринговый центр МФБ».

В начале 2013 года НП РТС начала работу над созданием межброкерской торговой системы с функцией best execution.

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

3

Проект по созданию платформы

В сентябре 2013 года стояла задача запуска в опытную эксплуатацию за 9 месяцев версии с функционалом Best Execution. В целом она была решена - в июне 2014 года были запущены торги на первой версии системы и дан доступ тестовым участникам.

Далее шел процесс доработок под пожелания пользователей и покрытию системы полноценной системой тестов.

В ноябре 2014 планируется обновление версии платформы и запуск рынка иностранных ценных бумаг с расчетами в долларах США.

4

Архитектура платформы

1. Операционная система Linux. Быстрые модули написаны на C++. Управляющие и некритичные к скорости на Java. Тестовые скрипты пишутся на python.

2. Архитектура модульная. Большинство модулей работают как преобразователи данных - получают входящие потоки данных, обрабатывают и выдают исходящие потоки. Есть модули имеющий под собой БД.

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

5

Модульное тестирование 1

Архитектура платформы позволяет

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

создать внутри контейнера прототип модуля (например на python) внешне идентичный промышленной реализации

6

Модульное тестирование 2

Широкое покрытие функционала модульными тестами написанными разработчиками.

Автоматизированное тестирование путем ручного формирования как тестовых входящих данных, так и выходных данных. Применяется для логически самых простых модулей.

7

Модульное тестирование 3

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

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

8

Case 1. Отладка многопоточной бизнес логики. На примере модуля расчета рисков.

В основе система массового обслуживания: N=5 потоков обрабатывают изменения состояния от 100 до 1 млн портфелей.

Данные относящиеся к разным портфелям изолированы.

Отсутствие одновременного доступа к данным из разных потоков.

Доступ к общим данным только на чтение.

9

Case 1. Отладка многопоточной бизнес логики 2

Выполняются задачи- Онлайн обработка входящих приказов- Изменение входящих параметров и соответствующий пересчет

всех портфелей под непрерывной нагрузкой.

10

Case 1. Отладка многопоточной бизнес логики 3

Система тестирования состоит из- Прототипа для проверки расчета по одному портфелю с

данным набором входящих параметров.- Набора тестовых примеров для тестирования алгоритма.- Регрессионного механизма сверки результата обработки

потока операций с результатом восстановления по срезу позиций и заявок.

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

11

Комплексное тестирование

Тестирование жизненного цикла системы.

Комплексное тестирование функциональных блоков.

Комплексные тесты с точки зрения клиентов.

Тестирование восстановления при нештатных ситуациях.

12

Case 2. Восстановление

Главное требование: При сбое отосланная клиентам информация должна остаться валидной. Это касается сделок, а

также операций с заявками.

Другие требования к восстановлению:Гарантия возможности.Надежность.Быстрота.

13

Case 2. Восстановление 1

В ходе проектирования рассматривались разные варианты архитектуры, различные в части восстановления:

1. Единая шина данных. Единый упорядоченный основной поток торговых данных. Каждый модуль системы имеет один вход и восстановление тривиально.

Плюсы - простота восстановления. Минусы - производительность, ограничения в масштабировании.

2. Модульная архитектура с произвольными связями.Плюсы - масштабирование, гибкость в конфигурировании, минусы - сложность

восстановления.

Был выбран вариант 2.

14

Case 2. Восстановление 2

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

В процессе восстановления используется механизм отсечек - checkpoints от которых клиент потока может проводить восстановление в режиме штатной работы.

Отсечка создается один раз в день в каждом торговом потоке. При создании отсечки заявки снимаются и выставляются заново, отсылаются нужные для восстановления значения внутренних переменных.

15

Case 2. Восстановление 3

В исходящий поток пишутся ссылки на исходные сообщения.

Также сохраняются срезы данных - заявок и позиций, для ускорения восстановления.

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

16

Case 2. Восстановление 4

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

Сложная матрица тестовых случаев - много комбинаций состояний входных линков.

Восстановление не было запрототипировано, поэтому большой расход труда на формирование тестовых примеров.

17

Case 2. Восстановление 5

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

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

18

СПАСИБО ЗА ВНИМАНИЕ!

E-mail: misha@rts.ruwww.nprts.ru