Третья сторона потоковой библиотеки против доморощенных - PullRequest
4 голосов
/ 30 декабря 2011

Мне известен ряд сторонних поставщиков потоковых компонентов (Kaazing, Lightstreamer, WebSync), однако мне было интересно, каково общее преимущество использования стороннего поставщика по сравнению с домашним поставщиком.

Сценарий, который я рассматриваю, заключается в том, что пользователь отображает в Интернете около 100 объектов, где свойства обновляются со скоростью до 3 обновлений в секунду. Я мог бы создать относительно простой компонент JavaScript, который опрашивает сервер на предмет обновлений 3 раза в секунду, динамически обновляя HTML-интерфейс на основе полученных результатов. С этим относительно простым сценарием, было бы какое-нибудь существенное преимущество использования сторонней библиотеки?

Ответы [ 2 ]

4 голосов
/ 09 января 2012

@ ColinE: причина, по которой у вас возникают проблемы с получением большего количества ответов, заключается в том, что у вас есть немного загруженный вопрос. Я думаю, у вас есть как минимум два вопроса:

1.) "Зачем покупать сторонние программные компоненты?" (широкий и расплывчатый вопрос) и
2.) «Учитывая мой конкретный вариант использования, я должен купить сторонний компонент обмена сообщениями в реальном времени?» (специфично для ваших условий и меньше - для общих знаний)

Я попытаюсь разобраться в этом, пытаясь сбалансировать широкие знания для всех, кто мог бы прочитать это, чтобы извлечь уроки, а затем рассмотреть ваш конкретный вариант использования. Я работаю в компании, которая публикует реализацию Comet / Bayeux для WebSync, поэтому у меня большой опыт в этой области. Ради равенства я постараюсь быть очень независимым в своей терминологии, но справедливо предположить, что перечисленные мною особенности / возможности / преимущества обмена сообщениями в реальном времени основаны на моем обширном опыте работы с WebSync. Я не знаю много о реализациях Java и Apache.

Зачем покупать компоненты сторонних производителей?

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

Когда вы покупаете сторонний компонент, вы редко покупаете только основную идею. Вы покупаете:

  • расширенная многофункциональная реализация, проверенная и проверенная сотнями клиентов
  • с солидной историей и планом на будущее
  • все завернуто с обещанием отличной технической поддержки
  • и наличие контрактов от опытных разработчиков, если вам в конечном итоге понадобится

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

Конечно, тогда вы должны подумать о рисках и будущем: насколько многократно будет моя собственная реализация будущих проектов? Какие риски я беру на себя, если масштаб проекта увеличивается? Может ли мое бюджетное время удвоиться или утроиться в случае изменения объема? Сколько времени я могу потратить на настройку производительности для масштабируемости или тестирования систем балансировки нагрузки? Что мой босс / клиент рекламирует в качестве еще одной платформы для нашего проекта?

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

Дифференцирующая комета от Ajax Polling

Ваш вопрос также ускользает от опроса ajax с фиксированным интервалом как альтернатива комете. Я хочу немного уточнить различия, чтобы помочь принять окончательное решение.

Определения

Одна из проблем отрасли - люди, которые путают Комету, Байе и Стриминг. Изначально Comet ссылался конкретно на long polling и теперь стал своего рода общим термином для доставки сообщений в режиме реального времени по обычному HTTP (независимый от протокола). Bayeux - это спецификация того, как эти данные должны выглядеть «по проводам» (протокол). Потоковая передача - это идея отправить что-то в режиме реального времени через Интернет. Люди часто используют их взаимозаменяемо, подразумевая одну систему со всеми тремя характеристиками / возможностями. Некоторые "кометные" системы не используют отраслевой стандарт " bayeux protocol ". Они не одно и то же, но вы обнаружите, что «bayeux» поддерживается рядом крупных игроков отрасли и определяет способ общения с нашими серверами для кометоподобных приложений. Bayeux - это также то, что делает реализации отраслевых стандартов хорошими вместе (хорошая вещь). Я сам могу даже немного смешать эти термины, но, по крайней мере, теперь вы понимаете, о чем я говорю, когда говорю «Байе».

Дублирование данных по проводам против начального состояния + дифференциальные обновления

Используя механизм опроса с фиксированным интервалом, вы получите именно то, что звучит как фиксированный интервал. С Bayeux идея состоит в том, чтобы избежать дублирования данных по проводам. Если данные не изменились, зачем отправлять их снова? Это экономит затраты на пропускную способность и затраты на обработку на вашем сервере. Обе очень реальные финансовые затраты, чтобы учесть ваше решение. С другой стороны, если данные изменяются 3 раза в секунду, у кометы не возникнет проблем с ее доставкой.

Делая этот шаг дальше, Байе допускает концепцию « начальное состояние + дифференциальные обновления ». Это означает, что когда ваш клиент javascript запускается, вы подписываетесь на канал, который возвращает начальное состояние для ваших 100 сущностей (возможно, объекта с тяжелыми данными), а затем механизм Comet продолжает доставлять инкрементные дифференциальные обновления. Пример: сущность 1 была только что удалена, сущность 7 была только что отредактирована, мы просто вставили другую сущность в список и т. Д. ... это дифференциальные обновления исходного состояния. Вы никогда не отправите полную коллекцию из 100 сущностей (если только все 100 сущностей действительно не изменились за последнюю 1/3 секунды).

Если вы потеряете соединение (пропадет Wi-Fi), клиент перепишется и начнёт заново с новым начальным состоянием, а затем продолжит дифференциальные обновления. Это гарантирует, что вы никогда не пропустите обновления. Если вы попытаетесь сделать это с помощью простого опроса Ajax, вы либо дублируете данные (используйте пропускную способность), либо рискуете «пропустить» дифференциальные обновления (ненадежные).

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

Bayeux Batching

Bayeux предоставляет «канальную систему» ​​для сегментирования данных, доставляемых клиентам. Например, если вы выполнили опрос AJAX, вы получите один большой блок данных, который вам нужно проанализировать (и сгенерировать на стороне сервера). С помощью системы каналов вы публикуете каналы, такие как "/ entityA", "/ entityB" или даже многоуровневые каналы, такие как "/ entityA / fooMessages" и "/ entityA / barMessages". Кометный сервер отправляет все опубликованные сообщения клиенту, где клиент может распространять сообщения в соответствующие обработчики JavaScript для каждого сегмента данных (каждого канала).

Поддержка на стороне сервера

Хотя это доступно не во всех реализациях Comet / Bayeux, я знаю, что в WebSync имеется отличный механизм обработки событий на стороне сервера, который позволяет вам «проверять» все сообщения, входящие или выходящие из вашего сервера. В этих серверных событиях вы можете загружать новые данные, преобразовывать существующие данные, регистрировать диагностическую информацию, оценивать состояние аутентификации, вызывать сторонний междоменный API и т. Д. Здесь много возможностей для подготовки / обработки нужных вам данных раздать своим клиентам.

Должен ли ColinE купить сторонний компонент Comet?

Хорошо, теперь у нас есть широкая основа для оценки выбора - пойти с открытым исходным кодом или купить коммерческую реализацию. Итак, давайте рассмотрим параметры, которые вы задали мне в своем вопросе.

Каждый клиент нуждается в 100 объектах с 3 обновлениями в секунду. Итак, 300 отдельных объектов / сообщений JSON разлетаются для каждого клиента. Это много данных, которые нужно публиковать. Я бы сказал, что все, что вы можете сделать, чтобы уменьшить количество дублированных данных по сети, принесет вам значительную пользу, поэтому я бы порекомендовал реализацию кометы с начальным состоянием + дифференциальные обновления. Кроме того, благодаря отслеживанию большого количества объектов, сегментация данных по каналам действительно поможет вам в кодировании и сэкономит ваше время.

Опция: Опрос сервера 3 раза в секунду с AJAX.

Плюсы:

  • Дешево и просто
  • Легкий вес JavaScript

Минусы:

  • Обновление 3 раза в секунду независимо от частоты, на которой фактически изменяются данные (возможная трата полосы пропускания и накладных расходов на обработку)
  • Необходимо реализовать 100% генерации JSON на стороне сервера и синтаксического анализа на стороне клиента большого (100-сущностного) объекта JSON. (Нет сегментации данных по каналам)
  • Вы должны построить всю логику обработки ошибок. Что произойдет, если мой Wi-Fi отключится на 3 секунды? Будут ли ваши запросы складываться? Будете ли вы «пропустить» обновления? Как вы будете догонять / перезагружать страницу? Или вы будете продолжать отправлять ВСЕ данные 3 раза в секунду?

Опция: Покупка Многофункциональная реализация кометы .

Плюсы:

  • Минимизирует использование полосы пропускания по сравнению с опросом с фиксированным интервалом (сэкономьте деньги)
  • Каналы обеспечивают легкую сегментацию данных (экономия времени благодаря реализации / анализу)
  • Пакетная обработка сохраняет HTTP-запросы (лучшая производительность / меньшая пропускная способность)
  • Превосходная обработка ошибок с логикой переподключения, настраиваемыми таймаутами (повышенная надежность)
  • Поддержка на стороне сервера для работы с событиями / сообщениями / данными (мощный и быстрый код на стороне сервера)
  • Проверенная надежность, масштабируемость и поддержка клиентской платформы
  • Профессиональная техническая поддержка, документация, контракты, если вам нужна помощь

Минусы:

  • Авансовые затраты на лицензирование
  • Функция Rich переводит в JavaScript больше, чем простой опрос AJAX
1 голос
/ 02 января 2012

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

Плюсы сторонних библиотек:

  • Может быть более стабильным, потому что у них есть отчеты об ошибках от их пользователей, вы не можете получить такую ​​поддержку, когда создаете свою собственную библиотеку и используете ее только для себя, вы единственный бета-тестер
  • У них часто больше функций, чем у домашних библиотек, потому что они хотят заманить людей в использование своей библиотеки, и они должны быть легко настраиваемыми, чтобы действительно апеллировать

Минусы сторонних библиотек:

  • У них может быть слишком много функций, чтобы быть легковесными, и это часто для меня настоящая проблема, на самом деле многие из них довольно медленные, потому что они не являются специфическими для проблемы, но действительно общими. И это становится действительно проблемой, когда вам приходится работать быстро, как 20 раз в минуту, опрашивая сервер. И если ваш сервер не отвечает достаточно быстро, что может быть в случае, если одновременно опрашивается множество пользователей, это может стать очень неловким.
  • Вы не можете знать API сторонней библиотеки наизусть, потому что есть много библиотек, которые вы используете ежедневно или еженедельно, и вы не можете их запомнить, тогда как если вы написали код, вы используете свои собственные соглашения и вы действительно знаете, как это работает за кулисами, поэтому вы действительно в лучшем положении, чтобы извлечь максимальную пользу из библиотеки.

Итак, вот мои мысли об этой дилемме, надеюсь, она будет вам полезна.

...