Серверная архитектура обновлений в реальном времени App

Question

Я создаю биржевой тикер, который требует непрерывных обновлений в реальном времени. JavaScript на клиенте, говорящий с .NET WCF 4.5, который представил поддержку WebSockets.

Корпорации пользователей значительно различаются. Например, многие пользователи следуют популярным крупным шапкам, таким как FB, GOOG и MSFT, но каждый пользователь следует многим другим «нишевым» запасам, которые могут быть уникальными для него.

Мы все знаем, что есть несколько вариантов обновления браузера в режиме реального времени.

1. Опрос. Плюсы: Простая реализация. Минусы: не масштабируется, не примитивно, не тратит время и циклы.

2. Длинные опросы. Плюсы: эффективные, масштабируемые. Минусы: устаревшие?

3. WebSockets. Плюсы. Эффективный, масштабируемый. Минусы: Нет. Я могу думать, что большинство современных браузеров поддерживают их по caniuse.com.

Может кто-нибудь выбрать что угодно, кроме 3.?

Предполагая, что я иду с 3., как отслеживаются открытые соединения сервера? Например, если мы создаем такое, чтобы мы сохраняли пул «последователей» FB (т. Е. Клиентские соединения, заинтересованные в изменении цены FB), чтобы мы знали, кого обновлять, когда происходит изменение цены, как поддерживается этот пул? Службой, которая постоянно работает в памяти? Кроме того, если последователь FB закрывает свой браузер, нужна ли службе, чтобы поймать это событие и обновить пул последователей FB? Здесь я быстро размываюсь.

Answer 1

Посмотрите на этот пост о жестких сторонах длинного опроса: Hard downsides of long polling?

каким образом открытых соединений серверов отслеживали?

Возможно, в WCF WebSockets есть способ подключения и отключения событий. Если нет, вы определенно должны следить за другими рамками. Некоторое время назад я взглянул на веб-сайты WCF, и это выглядело не так, как хотелось бы, и я отложил в сторону Windows 8 или Windows 2012, чтобы использовать его.

Вы должны рассмотреть веб-сайты, как просто и конечные точки. Вы должны разработать программное обеспечение для управления запасами с помощью подхода, основанного на событиях, и затем предоставить конечные точки для получения/доставки событий, что будет совершенно другой частью приложения. Для управления событиями я рекомендую вам взглянуть на MassTransit project.

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

Чтобы предоставить веб-узлы .NET, WCF - это не единственный вариант, и он может быть и не лучшим. Чтобы добавить конечную точку веб-дескриптора в вашу архитектуру, я рекомендую вам взглянуть на WebSocketListener, что является очень небольшим компонентом для обеспечения возможности websocket (отказ от ответственности: я его разработал) или XSocket.NET, если вы хотите более сложное решение, которое делает много вещей. Взгляните на этот пример, сделанный с помощью XSocket.NET: https://github.com/codeplanner/Simple.StockTicker