Применение WebSocket клиента на практике

Всем привет! Пару слов о том, что я делаю и зачем WebSocket, чтобы понимать контекст, ведь пример будет на рабочей системе.

Область финтех, управление финансами. Учетная система для Портфельного управления (когда "менеджер" планирует операцию и она должна быть выполнена на всех аккаунтах под управлением). Все управляемые аккаунты компании отражены в системе.

Чтобы это реализовать, нужен набор интеграций:

1. Терминал (рабочее место) для планирования операций и он должен быть приближен к привычному для трейдеров терминалу.

2. Отправка "команд" на выполнение операций (ордеров), получение актуальных данных о состоянии ордеров и позициях, а также балансах аккаунтов. В отраслевые дебри вдаваться не буду, все методы доступны и интеграция не является чем то необычным. Библиотека HttpConnector существенно облегчает жизнь, за что Владимиру Бондаревскому искренняя благодарность.

Возникновение проблемы

Каждый метод со стороны сервера (биржа OKX в нашем случае) имеет ограничение на количество вызовов. Например, метод возвращающий актуальную информацию о позициях ограничен Пятью вызовами в секунду с одного IP (схемы с проксированием запросов и попыткой обхода запрета не являются темой обсуждения), что становится проблемой, если нужно управлять хотя бы 20-30 аккаунтами... а система должна справляться с куда большим количеством. 

Решение - интеграция через веб-сокет, которая позволяет получать данные фактически "онлайн". Базовую информацию пересказывать не буду - для меня отправной точкой в исследовании вопроса WebSocket в 1С стала публикация Дмитрия Сидоренко. Расскажу как такая интеграция выглядит на практике и с какими проблемами столкнулся.

Общая схема интеграции со стороны WebSocket-клиента:

- получаем ВебСокет клиента (из метаданных). В нем может быть сразу могут быть описаны адреса, явки и пароли... но не всегда авторизация выглядит так просто. Вебсокет, так же как и http-сервис имеет свои EndPoint, они могут быть публичными или требовать авторизации (тут ничего нового по сути). 

- авторизуемся (если требуется), через отправку серверу сообщения заданного формата

- подписываемся на получение данных (так называемая подписка на каналы)

- данные начинают поступать.

ВебСокет клиент может работать как на клиенте, так и на сервере. В моем случае работа на сервере.

Что непривычно - это асинхронность. Вы отправили сообщение серверу (авторизация или подписка не важно) и ничего не получили в ответ. Ответ приходит в обработчик события "При получении сообщения" в модуле объекта клиента веб-сокета. 1 эндпоинт - 1 канал входящих сообщений обо всём, мы сами должны их "читать", классифицировать и понимать, что куда. 

Вот так это выглядит 

// ОМ биг_ОКХ_ВебСокет_КлиентСервер

Процедура ПриПолученииСообщения(Соединение, Сообщение) Экспорт 
	Параметры = ПараметрыСоединения(Соединение); 
	Параметры.Вставить("Сообщение",Сообщение);
	
	Если Сообщение <> "pong" Тогда
		биг_ВебСокет_ВызовСервера.ЗаписатьВЛог("ПриПолученииСообщения",Соединение.Ключ,Параметры);	
	КонецЕсли;	
	
	биг_ОКХ_ВебСокет_ВызовСервера.ПриПолученииСообщения(Соединение, Сообщение);	
КонецПроцедуры

// ОМ биг_ОКХ_ВебСокет_ВызовСервера
Процедура ПриПолученииСообщения(Соединение, Сообщение) Экспорт
	
	биг_ОКХ_ВебСокет_Сервер.ПриПолученииСообщения(Соединение, Сообщение);	
		
КонецПроцедуры

// ОМ биг_ОКХ_ВебСокет_Сервер
Процедура ПриПолученииСообщения(Соединение, Сообщение) Экспорт
	
	Если Сообщение = "pong" Тогда
		Возврат;
	КонецЕсли;
	
	Ответ 		= биг_ВебСокет_КлиентСервер.ЧтениеДанныхИзJSON(Сообщение);
	
	Если Ответ.Отработал = Ложь Тогда
		//Сообщить(Ответ.ТекстОшибки);
		ЗаписьЖурналаРегистрации("WebSocket-Client", УровеньЖурналаРегистрации.Предупреждение, Метаданные.WebSocketКлиенты.биг_ВебСокет_ОКХ,, "Ошибка = " + Ответ.ТекстОшибки + " ТекстСообщения = " + Сообщение);
		
	Иначе
		
		Результат 	= Ответ.Результат;
		
		Если Результат.Свойство("data") Тогда
			
			Данные 	= Результат.data;
			Канал	= Результат.arg.channel;
			
			Если Канал = "mark-price" Тогда
				// ничего не делаем пока что
				
			ИначеЕсли Канал = "orders" Тогда		
				ОбработкаОтветов_КаналОрдеров(Соединение, Сообщение, Данные, Канал);
				
			ИначеЕсли Канал = "positions" Тогда			
				ОбработкаОтветов_КаналПозиций(Соединение, Сообщение, Данные, Канал);
				
			ИначеЕсли Канал = "balance_and_position" Тогда			
				ОбработкаОтветов_КаналБалансыИПозиции(Соединение, Сообщение, Данные, Канал);			
			КонецЕсли;
			
		ИначеЕсли Результат.Свойство("event") И Результат.event = "subscribe" Тогда		
			
			КлючСоединения 	= Соединение.Ключ;
			Канал 			= Результат.arg.channel;
			
		ИначеЕсли Результат.Свойство("event") И Результат.event = "login" Тогда
			
			ОбработкаОтветов_Авторизация(Соединение, Сообщение, Результат);	
		КонецЕсли;		
	КонецЕсли;
	
КонецПроцедуры

Как обеспечить "онлайн" данные постоянно?. Соединение закрывается WebSocket сервером, если 30 секунд не активно. 

А мне нужно мониторить все операции по управляемым аккаунтам, допуская, что операции по ним могут быть инициированы в веб-браузере (не будем здесь вдаваться в бизнесовую логику, почему такое допускается). Мы открываем соединение, авторизуемся, подписываемся на данные по позициям и радостно ждем... А оно закрывается :( 

Решение: в целом очевидное, нужно фоновое задание, которое будет собирать все управляемые аккаунты, находить по каждому ВебСокет клиент и... посылать туда "пинг" :) 

Само решение вроде простое, но реализация вызывает трудности, ведь, оказывается, нужно знать, какой клиент от какого аккаунта. ОЙ! А это что же, надо на каждый аккаунт по ВебСокет клиенту? И с каждым новым аккаунтом лезть в конфигуратор? Хорошо, что не так... но клиентов нужно создавать программно. У меня получился такой подход:

Клиент на один эндпоинт (каждый эндпоинт позволяет подписываться на много разных каналов).

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

Пришлось эту информацию хранить (так как она в общем-то статична, то я её захардкодил и при создании ВебСокет-клиента получал, передавая флаг Демо). Один клиент - это один набор обработчиков событий. Конечно, при создании клиента можно указать обработчики программно, но мне показалось это лишним. 

Итак, под каждый Аккаунт мы создаем свой ВебСокет клиент. Если это канал, требующий авторизации - сразу отправляем авторизационное сообщение (содержимое, конечно, завязано на аккаунт). Заметьте, ответ мы не знаем и должны либо предполагать, что всё успешно, либо обработать его в событии "При получении сообщения" и уже там запускать дальнейшие шаги. Подписываемся на каналы (набор каналов я захардкодил, потому что для каждого аккаунта он статичен... а иначе пришлось бы еще и это организовывать). 

Ага, клиенты создаются, авторизация идёт, на каналы подписываемся. Но надо, что бы это всё само запускалось. Окей, еще одно фоновое задание, которое при старте системы будет собирать все аккаунты, создавать по ним ВебСокет-клиенты, поднимать соединение, авторизовываться (если нужно) и подписываться на каналы. При этом запоминать, какой канал для какого аккаунта по каким вопросам... И это всё надо хранить. Пилим регистр сведений.

Слушатель - это биржа или аккаунт. Например, данные о ценах мы получаем по бирже в целом, а не для каждого аккаунта.

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

Ключи клиента и соединения - это websocketклиент.Ключ и WebSocketКлиентСоединение.Ключ

А ключи мы им задаём сами при создании.... и в тот же момент фиксируем в регистр.

Теперь, когда нам надо отправить Пинг по всем открытым соединениям - мы обращаемся к этому регистру. Флаг "Требуется авторизация" родился потому, что бывает соединение падает (одно из всех например) и тогда вместо пинга - его нужно снова открыть, а значит понимать требуется ли авторизация в конкретном эндпоинте или он "публичный". 

А почему бы нам просто не получить все соединения, обойти их в цикле и отправить пинг? Зачем все танцы с бубном? - Потому что у нас могут быть соединения, открытые временно и не требующие поддержания. Избыточное количество соединение дополнительно грузит сервер и он лимитирует их.

В итоге это объединилось в одно фоновое, которое получает аккаунты, пробегает и проверяет все соединения. Если соединения нет - отрывает, если есть - отправляет пинг, и выполняется каждые 25 секунд. 

Вторая проблема, которая для меня пока не критична, но которую стоит держать в голове - это скорость обработки данных. ВебСокет по сравнению с HTTP- или Web-сервисом это ультра быстрый механизм. Обратите внимание, как часто могут поступать сообщения:

Это накладывает требования на производительность... и если она не справляется, то придется организовывать "очередь обработки сообщения".

А еще важно не забыть задание, которое будет очищать логи веб-сокет интеграции... они очень нужны для отладки, но очень быстро надувают базу до космических размеров :)

Ну и напоследок покажу, как выглядит сам торговый терминал в исполнении "темной темы на 1С"