Как реализовать Socket.IO с ASP.Net, IISNode, Node.JS и SQL Server для push-уведомлений на основе событий?

Question

Для проекта уведомлений хотелось бы выдавать уведомления о событиях. Это такие вещи, как вход в систему, изменение профиля и т. Д., Которые должны отображаться соответствующему клиенту. Я хотел бы обсудить некоторые идеи по его объединению и получить совет относительно наилучшего подхода.

Я заметил здесь , что изменения, внесенные в CouchDB, могут быть обнаружены с помощью потока _changes, обнаруженного Node, и процесс запускается. Я хотел бы реализовать что-то вроде этого (я использую SQL Server, но точка входа на этом уровне может быть не лучшим решением).

Вместо того, чтобы следовать примеру CouchDB (обнаружение событий на основе базы данных, я думаю, что это только усложняет вещи, так как мы заинтересованы в клиентских событиях), я подумал, что когда происходит событие, такое как вход пользователя в систему, то сообщение отправляется на сервер Node с некоторыми подробностями события (запрос RESTful?). Это сообщение затем обрабатывается и передается всем подключенным клиентам; соответствующий клиент отображает уведомление.

Предлагаемая экосистема:

• .Net 4.0
• IIS
• IISNode
• Socket.IO
• Node.js
• SQL Server 2008

Он будет построен поверх существующего проекта с использованием платформы .Net (IIS и т. Д.). Многие из браузеров клиентов не поддерживают веб-сокеты, поэтому использование Socket.IO является хорошим вариантом (резервная поддержка). Однако из того, что я вижу , Socket.IO по-прежнему поддерживает только длинный опрос через IISNode (что на самом деле не проблема).

Можно указать конечную точку Socket.IO/Node для всех клиентов, чтобы клиентские уведомления можно было отправлять через JS на сервер Node, который транслирует сообщение. (следует базовым примерам чат-сервер / клиент / сервер).

Альтернативно, конечная точка IIS может использоваться, но может поддерживать только длительный опрос (через Socket.IO). Это может предложить дополнительную внутреннюю обработку .Net, но может усложнить архитектуру.

Доступно ли уведомление Node о событии на базе SQL Server?

Какой будет наилучший подход?

Если я не правильно понял терминологическую конфигурацию экосистемы, уточните.

Спасибо.

Answer 1

Я бы порекомендовал вам сначала проверить SignalR , прежде чем подумать о добавлении iisnode / node.js в набор технологий вашего уже существующего приложения ASP.NET.

Что касается веб-сокетов, независимо от того, используете ли вы ASP.NET или node.js (socket.io), вы можете использовать длинный опрос HTTP только для уведомлений с малой задержкой, поскольку веб-сокеты не поддерживаются HTTP.SYS / IIS доWindows 8. iisnode в настоящее время не поддерживает веб-сокеты (даже в Windows 8), но такую ​​поддержку можно добавить позже.

В последнее время я провел некоторые исследования, касающиеся доступа к MSSQL из node.js.Существует несколько проектов OSS, некоторые из которых используют собственные, специфичные для платформы расширения, некоторые пытаются реализовать протокол TDS исключительно в JavaScript.Я не знаю ни одного, который позволил бы вам получить доступ к функциональности уведомлений SQL.Тем не менее, сама команда MSSQL инвестирует в первоклассный драйвер MSSQL для node.js, так что за этим стоит следить (https://github.com/tjanczuk/iisnode/issues/139).

Если вы планируете использовать SQL-уведомления для поддержки низкого уровняУведомления о задержках, я настоятельно рекомендую начать с тестов производительности, которые имитируют желаемый уровень трафика на уровне сервера SQL. Уведомления SQL предназначались главным образом как механизм, помогающий поддерживать в кеше памяти согласованный с содержимым базы данных, поэтому он может илиможет не соответствовать требованиям вашего сценария уведомления. Как минимум, эти измерения помогут вам начать с лучшего дизайна.

Answer 2

Я настоятельно рекомендую использовать Pusher . Это то, что мы используем, и это облегчает реализацию, поскольку является размещенным решением. Так что подключить его и заставить его работать действительно легко. Это не будет стоить дорого, если вы не собираетесь распространять сумасшедшее количество сообщений через него в массовом масштабе.