Всем привет!
Есть у кого-то опыт написания торгового бота?
Интересует архитектура, как оно должно выглядеть?

Есть. Архитектуру никто вам не раскажет ибо NDA.

jonie, а ссылкой на какие-нибудь обзоры или описания можно поделиться?
я сильно сомневаюсь, что это ноухау...

В такой формулировке вы можете и сами погуглить. Это очень широкая сфера, всё равно что спросить "есть у кого-то опыт написания компьютерной игры? какая должна быть архитектура?". 
Прежде, чем узнавать про архитектуру, надо определиться на основе чего писать. Если это просто скрипт для MT4 или NinjaTrader например, это одно, если же самостоятельная система, напрямую юзающая различные сервисы котировок и ордеров - совсем другое. И первая и вторая программы могут называться торговыми роботами. 

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

И опять же сначала конкретезируйте задачу - это будет у вас какой-то сервис, или только десктопное приложение? Или какая-то расширяемая платформа наподобие того же МТ? 
Все же попробую обозначить основные узлы: ядром любого торгового робота конечно же является код, "принимающий решения" о торговых операциях. Писать этот код нужно на абстрактном API, не зависящем от конкретных поставщиков котировок, торговой платформы, индикаторов и т.д. Т.е. для этого "ядра" все узлы, которые могут быть замещены, должны быть инкапсулированы. Но этот принцип думаю вам и так понятен. 
Далее, возможно будет расширяться сама логика этого ядра, например вы захотите поддержать подключение различных торговых стратегий со стороны, написанных другими кодерами в обнимку с трейдерами. В таком случае, ваше "ядро" становится эдакой "средой выполнения" с набором каких-нибудь стандартных инструментов, базовых классов и средств запуска всего этого. А конкретная логика принятия торговых решений - пишется уже на базе такого ядра. Главное - максимально изолировать логику принятия решения (и предоставить ей согласованный и удобный API), потому что это самая изменяемая часть подобных систем. 
Из остальных узлов можно конечно же выделить: 
Поставщика котировок - сущность, на вход получающая какие-то исходные данные по рынку, например инструмент (акцию/валюту) и время начала торгов, а на выходе  - массив котировок (грубо говоря). Реализация должна быть заменяемой, т.к. для получения котировок можно подключать разные сторонние сервисы, и у каждого может быть свой API.
Торговая платформа - сущность, принимающая на вход ваше "торговое решение" и обеспечивающее его интерпретацию доставку до конкретного торгового сервиса, торговый сервис (как правило сторонний) проводит ваш ордер дальше - вплоть до конкретной биржи, и обеспечивает фидбек и трекинг(отслеживание состояния) по этому ордеру.
Индикаторы - сущности, которые на вход принимаю рыночные данные (например котировки), а на выходе предоставляют дополнительную информацию, характеризующую рынок, которая используется для дальнейшего принятия торговых решений.  Индикаторы вы можете тупо и бодро кодить своими силами или опять же воспользоваться сторонними сервисами. Главное - не забывайте об инкапсуляции и заменяемости подобных компонентов.
В принципе "приниматель решений" тоже может являться каким-то сторонним сервисом. Всё зависит то того - что именно вы продаёте в своём продукте.
Не стоит также забывать о клиентском модуле - который должен также быть расширяем и предоставлять удобный интерфейс для наблюдения и управления состоянием вашего торгового робота/платформы.
Ну и конечно фундамент всей системы - данные. Необходимо как можно раньше решить что и где вы будете хранить. Те же акции - их набор, имена, сопоставленная индустрия т.д. - это мета информация, которая создаётся не вами, а запрашивается с сервиса котировок/торговой платформы и т.д. однако юзерам может потребоваться хранить связанные с акциями данные - например статистические показатели, вычисленные вашей системой. Возможно потребуется экспортировать/импортировать эти наборы акций с машины на машину (или с аккаунта на аккаунт) и при этом поддерживать их согласованность с используемыми торговыми платформами, чтобы например не попытаться открыть сделку по акции, которой уже нет на бирже.


Это сообщение отредактировал(а) dzaraev - 3.12.2013, 07:25

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

1) настоящие пацаны не пишут роботов на це решетке.
2) роботы вообще никогда не были десктопными
3) C# можно юзать только для управления роботом
4) работать через брокерерское API - бред - много не заработать, ибо выставление заявки в 200мсек уже неприемлемо.

jonie, 
1.чем шарп плох?
2.ну десктоп-не десктоп - какая разница, это так для эксперимента пока, может службу сделаю потом
3.ну это на вкус и цвет
4.А как работать не через брокерское API? не ну как? варианты?

jonie, 
1 Ну надо тогда сразу пояснять - на чем пишут пацаны, и обосновывать - почему. Всем же интересно.
2 Правильно, десктопными могут быть только приложения.
3 Опять же заявление в стиле "пацанов".
4 Время выставления заявки на заработок напрямую не влияет, всю зависит от того - что за торговля вообще идет, если акции на фондах нужно купить/продать и ордера могут быть 1-2 раза в день или даже в неделю, то 200 мс - не помеха совершенно. Если нужен какой-то быстрый арбиртаж или скальпинг, где количество сделок в день может достигать десятков а то и сотен, а рыночная ситуация меняется каждые несколько секунд - то тогда да, время выставления ордера критично, но только тогда.

Товарищи, а какие варианты доступа к бирже кроме ее апи существует?
Ну на вскидку?

хыы решеник над которым работаю я только за сегодня выставил на порядки больше чем вы указали заявок (и эт только по одной площадке)...


Ядро писать надо на чем-то очень-очень быстром, я например пишу ядро на С++ (+OpenMP, и оптимизации вставки ассемблера). Для некоторых алгоритмов расчета расчеты паралелятся на несколько кластеров используя MPI.

 см1


я имел в виду через посредников. Например через Quik (у них есть fix шлюз-агрегатор для некоторых площадок).

Ну тут надо учитывать что роботы бывают небольшие, конечно, но я обыкновенно веду речь о очень больших и очень сложных роботах, которые приносят $.

Ну так поэтому вы и говорите про "неприемлимость" 200мс. Понятное дело, что в ваших "решениках" это время критично. Когда-то я писал арбитраж-систему на форексе (была наивная попытка в институте), - тогда мне так и не удалось "завести" ее на реальных счетах в основном по этой же причине. 
Когда много позже писал "портфельного" трейдера уже для фондов (работал и приносил $), там количество сделок могло быть 1-2 в неделю, анализировались минутки-пятиминутки и далее. Естественно уже не было нужды ни в C++ с асмом, ни в планке в N миллисекунд. Просто разные требования к системе - соответственно разные решения и инструменты. Какие требования у автора, пока не ясно, но категорично отсекать C# как основной язык разработки я бы не стал.

с тех пор могло всё поменяться 8-)

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