Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

crdoo
November 15, 2014
31

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

crdoo

November 15, 2014
Tweet

More Decks by crdoo

Transcript

  1. Торговая платформа НП
    РТС: задачи, архитектура
    и подход к тестированию
    14/11
    Кострома
    Сергей Замолоцких

    View full-size slide

  2. НП РТС
    НП РТС основано в 1995 году и до декабря 2011 года
    было частью биржевой группы РТС.
    Члены НП РТС – более 100 компаний, в том числе
    ведущих брокеров и дилеров на российском рынке.
    НП РТС ставит своей целью развитие инфраструктуры
    российского финансового рынка.
    2

    View full-size slide

  3. НП РТС
    К концу 2012 года НП РТС подготовила инфраструктуру для
    создания биржевой группы - ОАО «Санкт-петербургская
    биржа» и ОАО «Клиринговый центр МФБ».
    В начале 2013 года НП РТС начала работу над созданием
    межброкерской торговой системы с функцией best execution.
    В сентябре 2013 года задача была расширена до создания
    универсальной многофункциональной биржевой платформы
    с поддержкой широкого спектра рынков и внешних
    площадок.
    3

    View full-size slide

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

    View full-size slide

  5. Архитектура платформы
    1. Операционная система Linux. Быстрые модули написаны на
    C++. Управляющие и некритичные к скорости на Java.
    Тестовые скрипты пишутся на python.
    2. Архитектура модульная. Большинство модулей работают как
    преобразователи данных - получают входящие потоки
    данных, обрабатывают и выдают исходящие потоки. Есть
    модули имеющий под собой БД.
    3. В разработке используется универсальный контейнер,
    позволяющий абстрагировать логику от работы с
    интерфейсами и сильно облегчающий разработку и
    тестирование модулей системы.
    5

    View full-size slide

  6. Модульное тестирование 1
    Архитектура платформы позволяет
    тестировать модули системы с помощью задания данных во
    входных и выходных потоках за счет абстрагирования
    реализации ПО от специфики связей в системе
    создать внутри контейнера прототип модуля (например на
    python) внешне идентичный промышленной реализации
    6

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. Case 1. Отладка многопоточной бизнес
    логики. На примере модуля расчета
    рисков.
    В основе система массового обслуживания: N=5
    потоков обрабатывают изменения состояния от 100
    до 1 млн портфелей.
    Данные относящиеся к разным портфелям
    изолированы.
    Отсутствие одновременного доступа к данным из
    разных потоков.
    Доступ к общим данным только на чтение.
    9

    View full-size slide

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

    View full-size slide

  11. Case 1. Отладка многопоточной бизнес
    логики 3
    Система тестирования состоит из
    - Прототипа для проверки расчета по одному портфелю с
    данным набором входящих параметров.
    - Набора тестовых примеров для тестирования алгоритма.
    - Регрессионного механизма сверки результата обработки
    потока операций с результатом восстановления по срезу
    позиций и заявок.
    - Нагрузочного стенда для проверки корректности
    многопоточной обработки по итогам выполнения различных
    тестовых сценариев. При этом суммарная пропускная
    способность одного экземпляра модуля должна быть не
    менее 50 тыс операций в секунду.
    11

    View full-size slide

  12. Комплексное тестирование
    Тестирование жизненного цикла системы.
    Комплексное тестирование функциональных блоков.
    Комплексные тесты с точки зрения клиентов.
    Тестирование восстановления при нештатных ситуациях.
    12

    View full-size slide

  13. Case 2. Восстановление
    Главное требование:
    При сбое отосланная клиентам информация
    должна остаться валидной. Это касается сделок, а
    также операций с заявками.
    Другие требования к восстановлению:
    Гарантия возможности.
    Надежность.
    Быстрота.
    13

    View full-size slide

  14. Case 2. Восстановление 1
    В ходе проектирования рассматривались разные варианты
    архитектуры, различные в части восстановления:
    1. Единая шина данных. Единый упорядоченный основной поток
    торговых данных. Каждый модуль системы имеет один вход и
    восстановление тривиально.
    Плюсы - простота восстановления. Минусы -
    производительность, ограничения в масштабировании.
    2. Модульная архитектура с произвольными связями.
    Плюсы - масштабирование, гибкость в
    конфигурировании, минусы - сложность восстановления.
    Был выбран вариант 2.
    14

    View full-size slide

  15. Case 2. Восстановление 2
    Восстановление проводится в первую очередь на основе
    содержимого исходящих потоков модулей, затем
    содержимого входящих потоков.
    В процессе восстановления используется механизм отсечек -
    checkpoints от которых клиент потока может проводить
    восстановление в режиме штатной работы.
    Отсечка создается один раз в день в каждом торговом потоке.
    При создании отсечки заявки снимаются и выставляются
    заново, отсылаются нужные для восстановления значения
    внутренних переменных.
    15

    View full-size slide

  16. Case 2. Восстановление 3
    В исходящий поток пишутся ссылки на исходные сообщения.
    Также сохраняются срезы данных - заявок и позиций, для
    ускорения восстановления.
    При восстановлении модуль сначала восстанавливает
    внутреннее состояние, а потом начинает обработку входящих
    сообщений. Это достигается конфигурированием контейнера,
    но все равно нуждается в тестировании.
    16

    View full-size slide

  17. Case 2. Восстановление 4
    Казалось возможным создать не слишком сложную систему
    восстановления на таких принципах. Однако на практике из-
    за большого числа и различного характера связей некоторых
    модулей возникли нюансы и отладка восстановления такой
    системы оказалась сложнее чем ожидалось.
    Сложная матрица тестовых случаев - много комбинаций
    состояний входных линков.
    Восстановление не было запрототипировано, поэтому большой
    расход труда на формирование тестовых примеров.
    17

    View full-size slide

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

    View full-size slide

  19. СПАСИБО ЗА ВНИМАНИЕ!
    E-mail: [email protected]
    www.nprts.ru

    View full-size slide