Торговая платформа НП РТС: задачи, архитектура
и подход к тестированию
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
