Об авторе:Луо Йи, системный архитектор ИТ-среды и бэк-офиса GF Securities. Он присоединился к Tencent в начале 2013 года и в основном отвечает за логический уровень и уровень хранения пересылаемых комментариев Tencent Weibo, а позже отвечает за разработку основных компонентов серверной части Weibo. Он присоединился к Департаменту информационных технологий GF Securities в 2016 году и в основном отвечает за проектирование системной архитектуры, а также за исследования и разработки в мид- и бэк-офисах, таких как рыночные котировки и транзакции. Богатый опыт проектирования высокопроизводительной и высокодоступной фоновой системной архитектуры. В настоящее время основное внимание уделяется применению финансовых ИТ-систем, FinTech и других связанных технологий, а также глубокой интеграции интернет-технологий и финансовых систем.
содержание
-
Архитектура сервиса системы котировок и торговли ценными бумагами
-
Как добиться высокой параллелизма и высокой производительности?
-
Как добиться качественного пуша?
-
Как добиться высокой доступности и масштабируемости?
-
проблемы, с которыми столкнулись
GF Securities — один из первых брокеров, использующих язык Go в своей собственной системе, и у нас есть почти 3-летний опыт его использования. В настоящее время распределенные системы, разработанные Guangfa, и некоторые высокопроизводительные системы или системы, требующие отличной производительности, в основном реализованы на Go.
Системы, разработанные нашей командой на языке Go, включают в себя:
1. Облачная система рынка требует высокой производительности.
2. Система промежуточного офиса с распределенными транзакциями требует безопасности и стабильности.
Сегодня я в основном общаюсь с вами об этих двух системах на базе Go.
Характеристики котировок акций и торговых систем
• Одновременный пик подключений пользователей на рынке высок
• Высокие требования к своевременности рыночных данных
• Большие рыночные данные толкают трафик
• Большой объем расчета рыночных индикаторов
• Безопасный, стабильный и быстрый
Котировки и торговые системы имеют свои особенности:
1. Количество одновременных подключений пользователей на рынке велико. В период работы с 9:00 до 11:30 пользователи находятся в сети длительное время, а это длинная ссылка.
2. Своевременность рыночных данных высокая. Пользователи требуют, чтобы наши рыночные данные обновлялись как можно быстрее. Рыночные данные с бирж (Шэньчжэньская фондовая биржа, Шанхайская фондовая биржа) обновляются примерно за 3 секунды. Брокерская система должна предоставлять последние рыночные данные биржи. к пользовательскому терминалу как можно скорее. То, что мы хотим использовать, — это то, как рыночные данные активно подталкиваются фоном.
3. Пуш-трафик рыночных данных большой. GF Securities — компания, занимающаяся ценными бумагами первого уровня, имеет около 18 миллионов пользователей, а наибольшее количество одновременных онлайн-пользователей составляет около 500 000–800 000 во время бычьего рынка. Пользователь подписывается в среднем примерно на 10 акций, выбранных самостоятельно, так что количество внешних рыночных толчков одновременно очень велико, около 2 миллионов запросов в секунду, что на самом деле составляет около 1 миллиона запросов в секунду. Трафик очень высок в часы пик, когда рынок открывается в 9:30 и 13:00.
4. Объем расчета индикаторов рыночных данных велик. От биржевых моментальных рыночных данных до данных рыночных индикаторов требуется много вычислительной работы. Возьмем в качестве примера десять расчетов K-линии, количество ценных бумаг составляет около 2W, рынок открыт 4 часа в день, а рынок обновляется каждые 3 секунды, всего требуется 720 миллионов расчетов. В дополнение к реальному времени, с разделением времени, соотношением цены и прибыли, соотношением цены и прибыли, соотношением цены и прибыли, соотношением цены и прибыли, коэффициентом комиссии, разницей комиссий и другими расчетами более дюжины показателей, ежедневный объем расчета превышает 1 млрд.
5. Компетентные органы осуществляют более строгий контроль над компаниями по ценным бумагам. Безопасность и стабильность торговой системы очень важны. Хотя мы используем интернет-мышление для решения этих проблем, нам все равно нужно адаптироваться к среде компаний, занимающихся ценными бумагами.Мы не можем быть такими же гибкими, как Интернет.Например, пользователи могут обновляться без ощущения, например, расширение емкости, сервер и сетевые расходы. На самом деле будет несколько сбалансированных компромиссов по таким показателям, как гибкость, стоимость, безопасность и стабильность. Как только пользователь не может разместить заказ или размещает неправильный заказ, наша система должна сообщить пользователю, был ли заказ успешным или нет, как можно скорее, и не должна пытаться снова, чтобы система не разместила неправильный заказ. Кроме того, скорость транзакций должна быть быстрой, во время бычьего рынка многие брокеры не могут выставлять ордера, то есть возникают проблемы со скоростью обработки и стабильностью. Нам необходимо принять такие меры, как защита от перегрузок, пока скорость транзакций высока.
1. Архитектура сервиса рынка ценных бумаг и торговой системы
БытьБыть
Облачная система GF перешла от аутсорсинга к самостоятельной разработке.Что мы делаем, так это меняем архитектуру фонового дизайна, чтобы соответствовать стабильным и надежным системным требованиям с высокой степенью параллелизма и большим трафиком push-уведомлений. Сначала разбираем и разделяем весь рынок и торговый бизнес:
Один горизонтальныйрасколоть, для разделения бизнеса на основе микросервисов или распределенных связанных концепций. В соответствии с принципами полной функции, изоморфизма данных и единой ответственности, он делится по горизонтали на рынок в реальном времени, рынок K-линии, рынок с разделением времени, рынок транзакций за билетом, рынок секторов, поток капитала, цепочка кодов. , служба аутентификации, служба транзакций, опционы и фьючерсы, облигации фонда и котировки Lv2.
Второй вертикальный сплит, в соответствии с принципом разумной стратификации, удаления логики и хранения, рыночная облачная система вертикально разделена на шлюз доступа, уровень логики чтения, уровень хранения данных, уровень логики записи и уровень транскодирования рынка. Система транзакций делится на уровень доступа, логический уровень, уровень доступа к счетчику и уровень счетчика транзакций.
Схема архитектуры сервиса системы котировок и торговли ценными бумагамиБытьБыть
Архитектура торговой системы
Быть
Сначала мы смотрим на это со стороны пользователя, а затем со стороны рыночного источника (Шэньчжэньская фондовая биржа, Шанхайская фондовая биржа). На стороне пользователя требуется высокопроизводительный уровень доступа с высокой степенью параллелизма для защиты крупномасштабных пользовательских соединений и передачи пользовательских запросов в соответствующие модули бизнес-логики через длинные соединения. Уровень доступа также может выполнять балансировку нагрузки, аварийное восстановление маршрутизации и обнаружение сервисов для определенных модулей бизнес-логики уровня логики. Индекс дизайна уровня доступа заключается в том, что процесс поддерживает 50 000 подключений и 100 000 QPS (рыночных небольших пакетов) при условии четырех ядер и 1 ГБ памяти, а размер пакета запроса составляет около 200 байт. Нам необходимо рассмотреть следующие вопросы:
1. Как уровень доступа обеспечивает около 500 000 одновременных подключений к сети? Подавляющее большинство TCP-соединений исходят от приложений, а веб-пользователи подключаются с использованием протокола WS.
2. Как уровень доступа поддерживает различные протоколы доступа (tcp/ws/http).
Уровень логики чтения имеет рыночные модули, такие как разделение времени, K-линия, поток капитала и режим реального времени.Ему нужно только взаимодействовать с уровнем доступа, не касаясь каждого пользовательского соединения, чтобы уровень логики чтения мог сосредоточиться на обработке своя бизнес-логика.
Чтобы передавать крупномасштабные рыночные данные, необходима система push для управления подписками пользователей на самостоятельно выбранные акции, чтобы передавать рыночные данные, которые ему интересны, пользователю и управлять сопоставлением между пользовательскими подключениями, уровнем доступа. процессы и машины доступа. Система push подписывается на полные стандартные рыночные данные из уровня логики записи, а затем выталкивает их в соответствии с отношениями подписки пользователя.
Слой данных в основном используется для хранения рыночных данных. Первоначальное решение использует хранилище Redis с высокой частотой чтения и записи и моментальным снимком каждые 3 секунды.Основному Redis необходимо продолжать запись с высокой степенью параллелизма, а резервный Redis продолжает синхронизироваться, что легко может вызвать проблему плохого Redis. чтение производительности. В то же время, из-за самостоятельно построенного компьютерного зала и соображений соответствия, мы не можем настроить крупномасштабный кластер Redis, поэтому мы, наконец, приняли метод рынка хранения файлов с хорошей производительностью, но с более сложной разработкой.
Напишите логический слой, отвечающий за расшифровку исходных рыночных данных Шэньчжэньской фондовой биржи и Шанхайской фондовой биржи. Данные с биржи — это исходные данные, а то, что мы показываем пользователям, — это стандартизированные рыночные данные, такие как разделение времени, K-линия, ручки и данные о движении капитала.
Система поддержки периферийных устройств, включая HttpDNS, обнаружение служб, балансировку нагрузки, мониторинг сигналов тревоги, службу журналов и т. д.
Кроме того, данное архитектурное решение также применяется к торговой системе после стабильной работы рыночного сервиса. Система транзакций имеет требования к шифрованию и безопасности.Во-первых, данные связи должны быть зашифрованы, а данные транзакций должны быть строго зашифрованы.
Горизонтальное разделение логического слоя торговой системы, который можно разделить на проверку позиций по акциям, доверенную торговлю, проверку фондов и подписку, внебиржевую торговлю (биржевую торговлю), маржинальное финансирование и кредитование ценными бумагами и т. д. Логический модуль использует схему разделения чтения-записи.Например, некоторые пользователи постоянно обновляют свои позиции и запросы, но могут не размещать заказ.Схема разделения чтения-записи может сделать доверенный заказ и интерфейс запроса независимыми друг от друга. Уровень доступа к счетчику берет на себя унифицированную функцию доступа счетчика Hang Seng, счетчика Jinzheng и счетчика Vertex и отделяет доступ различных счетчиков от бизнес-логики.
2. Как добиться высокого параллелизма и высокой производительности?
Уровень доступа является ключом к решению проблемы высокой параллелизма и высокой производительности.Мы используем TCP-доступ для предоставления рыночных услуг с наибольшим трафиком в системе GF Securities.
Первая проблема, которую необходимо решить, — это управление большим числом одновременных TCP-соединений.Как процесс может достичь 50 000 одновременных TCP-соединений и общего количества запросов в секунду, равного 100 000? На самом деле она написана на обычном Go, то есть писать Socket listener.На каждое соединение выбрасывается сопрограмма чтения, а потом выбрасывается сопрограмма записи.Посередине может понадобиться сопрограмма управления координацией, а потом разбираться с этим делом. Это возможно? Мы сделали это в начале, но результат теста таков, что мы можем достичь 10 000 TCP-соединений, от 20 000 до 30 000 запросов в секунду, и если мы увеличим давление, мы не сможем работать. Так что этот способ трудно удовлетворить нашим требованиям к дизайну, нам нужно улучшить.
Во-первых, в Go трудно запланировать количество сопрограмм уровня 100 000, что в основном превышает его возможности планирования.Как только прикладная программа сборщика мусора входит в короткую паузу, накапливается большое количество задач, после чего сборщик мусора взорвется. , легко иметь проблемы. Управление пользовательскими соединениями и пул бизнес-сопрограмм равны, поэтому 100 000 сопрограмм, сгенерированных 50 000 соединений, и N бизнес-сопрограмм (постоянный уровень) равны, поэтому 100 000 сопрограмм должны участвовать в N службах в целом. сложите эти 100 000 сопрограмм в единое целое.
Во-вторых, функции каждого модуля должны быть едиными и сфокусированными: есть процесс конвертера, предназначенный для приема пользовательских подключений, модуль netcgo, предназначенный для управления пользователями, модуль бизнес-логики, предназначенный для пересылки запросов, и логика push для пересылки push-данных. tcpClient предназначен для Он отвечает за соединение с бизнес-системой и пересылку данных, так что запрос бизнес-модуля объединяется в длинное соединение, которое может обрабатывать данные более эффективно.
БытьБыть
Когда мы разрабатываем собственный протокол, нам необходимо учитывать следующие вопросы:
Быть
Чтобы более эффективно передавать данные рыночных небольших пакетов, мы добавили процесс установления связи, который может значительно сжать информацию заголовка пакета, передаваемую бизнес-запросом, и повысить эффективность передачи. В то же время мы разделяем протокол доступа и внутренний протокол, чтобы обновление и выпуск протокола внутреннего модуля не повлияли на запросы внешних пользователей.
БытьБыть
Это тест производительности, который мы провели для уровня доступа перед подключением к сети. Клиент -> уровень доступа -> сервер, сервер отвечает эхом.
Картина мониторинга в это время такова, и он длился около часа. БытьБыть
3. Как добиться качественного пуша?Быть
Основная обязанность push-системы — управление подписками пользователей и отправка рыночных данных. PushManager отвечает за связь с уровнем доступа, управление запросом пользователя на подписку и сопоставление пользователя и идентификатора процесса уровня доступа, отправку отношения сопоставления на прокси-сервер, а прокси-сервер проталкивает рыночные данные через UDP. Для данных, передаваемых пользователем в одном и том же процессе доступа, PushProxy объединит их, чтобы их можно было передавать более эффективно.
4. Как добиться высокой доступности и масштабируемости?
4.1 Обнаружение службы
Быть
Для достижения неограниченной масштабируемости бизнес-модуль должен реализовать механизмы обнаружения сервисов и балансировки нагрузки. Наше решение для обнаружения сервисов реализовано с использованием компонента Consul с открытым исходным кодом, основанного на контейнерном развертывании докеров. Например, для бизнес-модуля K-line с именем kline.gf.com служба развернута в кластере из 2 машин, на каждой машине развернуто 2 процесса, и на каждой машине есть регистратор для реализации службы автоматической регистрации, так что в консуле kline.gf.com будет соответствовать процессам, идентифицируемым четырьмя парами IP:PORT. Когда клиенту нужно позвонить, он получит 4 IP:PORT от консула, а затем свяжется с ними. Устанавливаются четыре соединения, после чего пакет запроса может быть отправлен соответствующему процессу. Так как же маршрутизируются эти четыре процесса? Это то, что должна решить балансировка нагрузки.
4.2 Компоненты динамической балансировки нагрузки
БытьБыть
Этот компонент сочетается с обнаружением службы, и из обнаружения службы берутся 4 записи IP: PORT Как распределять запросы при поступлении бизнес-запросов? Бизнес-модуль должен передать kline.gf.com для вызова GET API.Компонент балансировки нагрузки вернет соединение с лучшим качеством в соответствии с весом, а затем бизнес-модуль может отправить пакет запроса. После того, как бизнес-логика получит ответный пакет, ей необходимо вызвать интерфейс отчета, чтобы сообщить о состоянии вызова. Компонент балансировки нагрузки оценивает соединение на основе такой информации, как количество успешных вызовов, время обслуживания и состояние соединения, а затем выбирает оптимальное соединение на основе результатов оценки. Состояние подключения возвращается в режиме реального времени, поэтому решение для балансировки нагрузки может удалить неработающий процесс из планирования в течение десятков миллисекунд и добавить новые процессы в расписание за считанные секунды.
4.3 Система декодирования и пересылки
Быть
С точки зрения биржи, как декодирование может обеспечить высокую доступность? Поскольку VDE является прокси-сервисом Шанхайской фондовой биржи или Шэньчжэньской фондовой биржи, вы можете понять, что моментальный снимок рынка пересылается сюда и размещается в нашем компьютерном зале. Фактически мы развернули три набора декодирования: один для аварийного восстановления, один для аварийного восстановления и другие. Отметка времени ставится, когда происходит обмен, и повторитель может выполнять избыточную дедупликацию для двусторонних рыночных данных.
4.4 Мониторинг данных и сигнализация
БытьЕсли мы хотим говорить о высокой доступности, очень важны не только балансировка нагрузки, удаленное развертывание, кластерные сервисы, избыточность данных и т. д., но также мониторинг и оповещение. Бизнес-процесс вызывает API-интерфейс мониторинга и отчетности, чтобы сообщить об индикаторах. Сопрограмма API каждые 10 секунд подводит итоги и сообщает об этом монитору в локальной компьютерной комнате через UDP. Монитор пересылает данные мониторинга в influxDB через Tcp. Пользователи могут просматривать отчет о мониторинге в Интернете через Grafana.
5. Возникшие проблемы
1. Планирование горутин не имеет приоритета
В некоторых сценариях с высоким уровнем параллелизма большое количество горутин запросов и других рабочих горутин имеют большую разницу в порядке величины. Ранее они были запланированы без приоритета, поэтому иногда планирование является необоснованным.
2. Несбалансированное планирование горутин на 100 000 уровней.
Если количество Горутин в процессе равно 10^3 уровня, Go не проблема. Если это уровень 10 ^ 4, планирование Go не обязательно эффективно. Количество горутин на уровне 10^4 распределено неравномерно.
3. Большое количество горутинобъектСоздавать и уничтожать, GC влияет на скорость отклика системы
При наличии большого количества Горутин влияние GC особенно очевидно, потому что, как только он остановится на некоторое время, он заблокирует многие задачи, а когда его выпустят, он придет как наводнение.
4. Неэффективность механизма связи cgo
Быть
Процесс доступа Converter специально используется для того, чтобы принять соединение, а затем отправить его менеджеру Epooll через UnixDoma in. Соединение управления Epoll устанавливается горутиной и находится в процессе, поэтому количество горутин сходится.
Пользователи часто подключаются к сети и офлайн, и им нужно часто выделять память. Мы проектируем 50 000 подключений и одновременно создаем 50 000 сегментов Hash и размещаем их там. Когда пользователь появляется, объект памяти получается. После того, как пользователь выходит из сети, объект памяти будет освобожден и помечен как свободный.
При открытии незаблокированной очереди язык C и язык GO совместно используют адрес очереди, а связь CGO заменяется связью с памятью.
Быть
Уровень доступа отвечает за множество сервисов, а ниже находятся различные распределенные модули. Бизнес-модули не могут влиять друг на друга, а модули бизнес-логики лучше изолированы, то есть разные системы и разные модули развернуты в разных кластерах. Уровень доступа предназначен для различных сервисов.Мы используем разные чан внутри через разные командные слова и разные служебные модули.Преимущество этого в том, что переадресация разных сервисов не будет влиять друг на друга. Например, кодовая цепочка — относительно тяжелый бизнес, а бизнес в реальном времени — относительно легкий, так что у них могут быть разные приоритеты и методы обработки. Еще одним преимуществом Чана является срезание пиков и заполнение впадин.Возможно, что объем запросов в определенное время относительно велик и бьет волнами. Такие волны недружественны для вашей системы, а для программы такие волны будут вызывать граничные значения. После того, как у вас есть Чан, как только ударит такая волна, она сначала будет сохранена в Чане. , а затем медленно обрабатывайте его в режиме ожидания, поэтому он будет иметь эффект сглаживания.Бизнес-система выглядит как относительно гладкая кривая, и волн не будет.
Пакет SDK для программирования объединяет балансировку нагрузки, обнаружение сервисов и асинхронные сеансы, а также согласованные пакеты протоколов и механизмы пульса при управлении динамическими пулами бизнес-соединений. Разработчикам нужно сосредоточиться только на бизнес-логике, каждая программа может быть высококонкурентной и высокодоступной, и в то же время решить проблему связи и взаимодействия между модулями распределенной системы.
Gopher Meetup 2018 состоится вХанчжоуначать турВторая остановка,нажмитечитать оригиналзарегистрироваться