Architecture

Внедрение RFID систем для розничной торговли

 

Цель данной статьи – провести обзор среды розничной торговли и определить в ней место RFID систем. Мы постарались охватить как можно больше аспектов, касающихся применения RFID систем, чтобы обеспечить эффективный анализ предложений, доступных на рынке RFID в настоящее время. Безусловно, помимо технической стороны, ряд вопросов касается окупаемости инвестиций, цен RFID меток и оборудования, что мы также учли в данной статье, проведя исследование розничного рынка RFID приложений США.

Решение проблем, связанных с окупаемостью инвестиций от внедрение RFID систем

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

Согласно статистике показатель OOS – отсутствие товаров на полке – на 70% является результатом существующих внутри магазина проблем.

Ежегодно ритейлеры США теряют порядка 50 миллиардов долларов из-за высоких показателей OOS (помимо негативного влияния на показатели чистой прибыли предприятия, OOS также занимает лидирующее место среди причин плохого обслуживания покупателей, что ведет к потере клиентов).

Также американские ритейлеры ежегодно теряют 31 миллиардов долларов из-за потери товаров.

Посредством данной статьи мы хотим познакомить ритейлеров с некоторыми инструментами, позволяющими решать бизнес проблемы, через продвижение технологии RFID, что позволяет получить больший контроль над чистой прибылью. Мы предлагаем экономически выгодное, основанное на последних технологиях решение на уровне отдельного товара для розничных продаж, которое позволяет сделать управление запасами более рациональным. Мы хотим, чтобы ритейлеры могли точно идентифицировать место нахождения товаров, т.к. считаем что это благоприятным образом сказывается на снижении показателя OOS, сокращает потерю товаров, затраты на персонал, что в конечном итоге позволяет существенно повысить качество обслуживания покупателей. Согласно проведенным исследованиям, применение технологии RFID на уровне отдельных товаров, способствует успешному решению бизнес проблем:

  • Повышает точность инвентаризации до 20%
  • Снижает показатели OOS до 50%
  • Способствует увеличению объема продаж до 10%
  • Уменьшает время циклической инвентаризации до 90%
  • Сокращает потерю товаров до 50%
  • Уменьшает время на пополнение запасов на 65%
  • Снижает издержки на набор персонала до 15-20%

Система слежения на основе RFID

В рамках использования RFID систем слежения, каждый товар оснащается меткой с индивидуальным номером, и RF антенны встраиваются в систему полок торгового зала и склада. Стоимость меток невысока, сами метки похожи на почтовые марки. Уровни запасов и размещение помеченных метками товаров постоянно отслеживаются через централизованную систему. С помощью системы интерактивного слежения ритейлеры могут точно отследить, какие продукты и насколько быстро покупают, истощен ли запас и нужно ли делать заказ на какую-либо группу товаров. Также можно легко отследить местоположение товаров, которые были переставлены, типы продуктов, которые легче всего утерять или украсть и какие рекламные предложения срабатывают.

RFID BASED ITEM TRACKING SYSTEM-FUNCTIONAL LAYOUT

Функциональный план системы слежения на базе RFID

Кроме того, данные, собранные по каждому товару могут быть помещены в унаследованные системы (такие, как например, Point of Sale), позволяя ритейлерам, используя технологические процессы, использовать преимущества RFID по всем видам товаров. Это также способствует минимизации затрат, требуемых для установки предлагаемой системы.

Преимущества RFID системы

Преимущества технологии RFID, предлагаемой ритейлерам, можно разделить на 3 основные категории:

  • Высокий доход
  • Низкие затраты
  • Высокое качество обслуживания покупателей

Технология RFID

Основные проблемы RFID связаны со сложностью и новизной технологии. Радиочастотная идентификация – сравнительно молодая технология, которая появилась в 50-х годах прошлого века и начала широко использоваться в 90-х. В настоящее время ведутся активные работы по усовершенствованию технологии.

Диапазоны частот

В RFID системах используются несколько рабочих частот. Каждая из них занимает определенную нишу на рынке и предназначена для решения конкретных проблем.

Низкочастотные системы RFID обычно используют диапазон частот от 125 кГц. Подобные системы считывают информацию с более коротких расстояний и с меньшей скоростью, чем системы, использующие более высокие рабочие частоты. В то же время низкочастотные системы имеют высокую способность считывания в условиях высокой влажности и наличия металла. Обычно подобные системы используются для контроля доступа, чипирования животных, в здравоохранении, при идентификации продукта, а ткаже в различных приложениях для платежных систем.

Высокочастотные RFID системы (13,56 МГц)работают на больших расстояниях и с большей скоростью, чем низкочастотные системы. Одни из самых дешевых среди всех RFID систем. Обычные приложения включают в себя смарт-карты, смарт-полки для отслеживания каждого товара, идентификацию продукта, багажа самолета и регистрации данных.

Ультрачастотные системы RFID используют диапазоны частот, равные 860 – 930 МГц, в зависимости от региона применения (США или Европа). Стоимость меток диапазона UHF практически равна стоимости меток диапазона HF, но при этом метки ультрачастотных систем обладают наибольшей дальностью считывания (до 3 метров) и обеспечивают более высокую скорость считывания. Недостаток заключается в проблемах считывания в условиях высокой влажности, наличия металла. Данные системы применяются в приложениях для дистрибуции и логистики и являются основой стандарта Electronic Product Code (HRI). Эти RFID метки стали стандартом для такой всемирно компании, как Wal-Mart и Министерства Обороны в США.

Микроволновые системы RFID(2.45 ГГц или 5.8 ГГц) обеспечивают наибольшую скорость считывания, однако, при этом достаточно дорогие и имеют ограничения по дальности считывания (до 1 метра).

UHF RFID-метки

RFID-метки могут быть разделены на две группы:

Активные метки оснащены собственными источниками питания для передачи информации. Метки этого типа в значительной степени независимы от условий окружающей среды и обеспечивают высокую точность считывания на максимальном расстоянии. Однако, такие метки считаются дорогими, а у батарей ограничено время работы. Более того, активные метки имеют больший размер, чем пассивные.

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

Пассивные метки компактны и удобны. Однако главное их достоинство заключается в низкой стоимости, которая составляет в среднем 0.22 доллара за набор в 1000 меток. Предполагается, что цена на них будет снижаться вместе с дальнейшим развитием данной технологии.
Существуют несколько стандартов для UHF-меток и протоколов. Признанные во всем мире стандарты опубликованы компанией Hypothetical Retailer Inc, являющейся одной из ведущих RFID вендоров. Стандарты описывают несколько классов меток. В таблице 1 представлено краткое сравнение классов HRI-меток.

Таблица 1. Классы HRI-меток

1 Легко адаптируемый к уровню помех
2 Метки класса 0 читаются только по стандарту. Некоторые вендоры предлагают также так называемые метки Класса 0+, которые позволяют проводить модификации хранимых HRI.

Ниже представлены краткие характеристики каждого класса меток.

Метки класса 0 быстрые и дешевые. Они обеспечивают сравнительно высокую скорость считывания за счет надежности и гибкости. Использование меток только для считывания класса 0 влияет на увеличение административных и логистических издержек, а также требует дополнительных усилий на добавление меток для корректировки товаров.

Некоторые вендоры меток предлагают так называемые метки класса 0+, которые позволяют перезаписывать HRI в метки. Это частично решает проблему. Также тэги класса 0 работают только в ультрачастотном диапазоне, принятом в США, поэтому стандартные метки класса 0 не могут быть использованы в Европе.

Метки класса 1 поколения 1 (C1G1) оснащены памятью WORM – однократно записываемой памятью, что облегчает процесс отслеживания товаров. Метки класса 1 используют более надежный протокол, чем тэги класса 0 и могут работать также и в европейском ультрачастотном диапазоне.

С другой стороны, метки C1G1 работают намного медленнее, чем их конкуренты.

Метки класса 1 поколения 2 (C1G2) считаются наиболее передовыми и современными. Они используют новый протокол, сортирующий метки, который существенно повышает производительность. Кроме того, метки класса C1G2 более надежны. RFID HRI метки никогда не передавались по воздуху, как одна запись. Протокол использует случайную информацию, когда метки в диапазоне считывания обмениваются 16-ти битным рандомным числом. Кроме того, канал между считывателем и меткой зашифрован.

Метки C1G2 способны предотвратить взлом пароля, прекращая считывание в случае многочисленных неудачных попыток идентификации. Также метки G2 оснащены неограниченной WORM памятью.

С точки зрения безопасности и на долгосрочную перспективу метки второго поколения более предпочтительны, чем их предшественники. При этом обычно G2 метки более дорогие. Кроме того, на рынке готовых к использованию меток G2 предлагается существенно меньше, чем прочих. Метки класса 0 обеспечивают лучшее соотношение цены и качества, но при этом они не могут применяться в Европе.

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

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

После нескольких лет после первоначального развертывания RFID системы стоимость технической поддержки для адаптации появляющихся стандартов к технологии RFID может составить до четверти первоначальной стоимости развертывания. На протяжении этого переходного периода сотрудникам компании необходимо изучать технологию и приобретать навыки по технической поддержке. После этого затраты на поддержку снова упадут. Бизнес стратегия должна заключаться в том, чтобы совокупная стоимость собственности была настолько низкой, насколько это возможно. Исходя из этого, система должна предусматривать удобные для пользователя инструменты для контроля, совершенствования гибкости ПО и технической поддержки, облегчая процесс эксплуатации.

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

Сетевое окружение

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

  • RS-232 последовательное соединение
  • RS-422/485 последовательное соединение
  • 10/100MBit сетевое соединение через Ethernet
  • USB соединение

Некоторые устройства могут поддерживать несколько типов соединений.

С точки зрения простоты использования весьма привлекательны последовательные порты и USB. Многие компьютеры имеют свободные последовательные порты, поэтому при необходимости ими можно легко воспользоваться. Преимуществом RS-485-соединений является длина (до нескольких километров). С другой стороны, эти соединения недешевы. Дополнительные последовательные порты стоят около 30-40 долларов за штуку. Поэтому для больших RFID систем они не очень выгодны.

Стандарт Ethernet широко применяется во всем мире. Практически любая компания, имеющая хотя бы несколько компьютеров, применяет сеть Ethernet. Данный факт определяет преимущества использования IP сетей для коммуникации с RFID-устройствами:

  • На рынке достаточно квалифицированных специалистов, способных запустить и управлять инфраструктурой Ethernet
  • Аппаратное обеспечение для Ethernet очень дешево. Современные свитчи стоят менее 5 долларов за порт.
  • Производительность при использовании сетей LAN выше, чем при последовательном соединении.

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

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

Рекомендации

Существует два варианта выбора вендора для считывателя. Компания Alien Technologies предлагает несколько типов считывателей по разным ценам. Компания является лидером на рынке RFID и предлагает очень хорошую техническую поддержку и обслуживание.

Второй вариант – это компания ThingMagic, продукты которой отличаются хорошей функциональностью и гибкостью, а также приемлемой ценой. Их модель считывателя Mercury 4 лицензирована несколькими крупнейшими мировыми компаниями.

Таким образом, выбор во многом зависит от ваших бизнес целей. Для небольшого или среднего развертывания применение аппаратного обеспечения Alien будет более эффективно. Для больших установок и долгосрочного использования считыватель от ThingMagic’s будет более экономически обоснован.

RFID-метки

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

Рекомендуется выбирать необходимый тип RFID метки, основываясь на полученных опытным путем результатах. Выбирать метки лучше исходя из используемых материалов стеллажей и конкретных реализуемых товаров.

Рекомендации

Как уже говорилось выше, RFID-метки должны быть протестированы на реальном окружении, а также предлагаемых типах продуктов. Однако в общем случае мы рекомендуем использовать метки HRI Generation 2 ввиду их высокой производительности и надежности.

Компания Avery Dennison предлагает большой выбор меток Gen2 нескольких форм и размеров, включая метки для товаров. Независимые эксперты указывают на высокую производительность этих продуктов. Компания Alien Technologies предлагает высококачественные Class 1 Generation 1 метки и несколько видов меток Generation 2. К сожалению, данная компания еще не начала выпуск меток для товара Gen 2.

RFID принтеры

Производители предлагают принтеры этикеток штрих кодов, RFID-ready принтеры и RFID принтеры. В приложениях RFID стандартный принтер этикеток штрих кодов, оборудованный модулями для чтения/письма, используется для печати считываемых человеком меток, данные при этом хранятся в чипе RFID. Для того чтобы передать данные чипу, принтер оснащается UHF модулем для чтения/письма и антенной. Принтеры выпускаются в двух формах: как настольные принтеры и как аппликаторы RFID этикеток, что удобно для покупателя, т.к. он может выбрать вариант, наиболее ему подходящий. Т.к. спецификации принтеров этикеток штрих кодов не менялись в течение продолжительного периода времени, мы можем сравнить их основные характеристики: скорость, разрешение, медиа-поддержка, сервисы и техническая поддержка.
Очень важным фактором является разнообразие поддерживаемых меток. Существует много типов меток, работающих в рамках ультрачастотного диапазона. Между собой они различаются по скорости считывания, возможностях использования товаров в картонной упаковке и протоколов. Метки доступны из многочисленных конвертеров, использующих RFID этикетки, основанные на различных комбинациях чипов RFID и моделях антенны. Принтеры, поддерживающие все это разнообразие, обеспечивают наибольшую гибкость. Мультирегиональная поддержка также иногда важна.
Скорость печати – это второй важный параметр. Компании с большим товарооборотом используют принтеры для того, чтобы быстро производить готовые для использования этикетки. Также требуется, чтобы принтер подтверждал результат печати и разделял напечатанные без изъянов этикетки. К другим параметрам отбора принтеров относятся затраты на техническую поддержку и стоимость интеграции. Принтеры должны иметь легкий и удобный API и программное обеспечение для управления.
Некоторые производители принтеров RFID предлагают модели, отличающихся только размером поддерживаемых медиа и ценой. В таком случае будут предоставлены описания всего семейства принтеров.

Рекомендации

В настоящий момент мы не владеем всеми тонкостями внедрения системы, поэтому достаточно тяжело рекомендовать какую-то определенную модель принтера. Выбор зависит от объемов, которые вам нужно будет ежедневно печатать, типа товаров, с которыми вы будете работать и других факторов. В общем случае мы рекомендуем принтеры марки Zebra RFID. Данная компания предлагает широкий выбор моделей, совместимых с RFID. Принтеры данной марки легки в управлении и отличаются хорошей совместимостью с другими устройствами. Таким образом, выбрать модель, удовлетворяющую вашим требованиям и бюджету, реально.

Архитектура программного обеспечения

Мы предлагаем создавать систему, используя стандарты EPCGlobal Inc. Стандарты этой организации считаются ведущими. Практически все лидеры рынка являются участниками данной организации и предлагают товары, соответствующие стандартам и спецификациям EPC. В будущем принятие единых стандартов EPC позволит взаимодействовать с поставщиками RFID без каких-либо дополнительных усилий. Компания EPCGlobal предлагает большой выбор стандартов, касающихся различных аспектов системы RFID. Помимо этого компания предлагает инфраструктуру для EPC обмена данными между партнерами и управления числовым пространством EPC. Так как мы разрабатываем инфраструктуру системы отслеживания товара, в спецификации могут отсутствовать некоторые глобальные услуг EPC. К таким услугам относятся информационные услуги EPC (EPCIS), применение специальной системы ONS и некоторые другие. Эти услуги могут быть добавлены в систему программного обеспечения на более поздней стадии, если возникнет необходимость управлять каналами поставок и назначением функции EPC. Вместо этого может понадобиться подключение клиентов к услугам глобальной сети EPC, таких как, например, ONS распознаватель.
В настоящее время индустрия RFID находится в стадии развития, поэтому многие аспекты дорабатываются и изменяются. Даже компания EPCGlobal Inc подтверждает то, что гибкость – это один из основополагающих принципов при разработке стандартов. Следовательно, в дизайне архитектуры гибкость тоже имеет важное значение. Гибкости можно достичь, используя слабую связность между компонентами, что также позволяет сделать процесс разработки программного обеспечения более быстрым и повысить качество кода. Кроме того, система не должна блокировать отдельных поставщиков программного и аппаратного обеспечения, а, напротив, должна быть совместима с новыми считывателями, принтерами или типами меток, поэтому особое внимание должно быть уделено изоляции интерфейсов аппаратного обеспечения.
По своей сути RFID системы управляемы событиями. Объекты генерируют события, регистрируемые аппаратным обеспечением RFID , после чего эти события должны быть обработаны промежуточным программным обеспечением. Поэтому модель функции низкого уровня должен быть выстраиваться вокруг процессов передачи и обработки данных.
В модулях высокого уровня используются синхронные структурные запросы и техники обработки событий. Исходя из этого для хранения текущего состояния системы и ускорения процесса обработки событий необходимо долговременное хранилище данных.
Т.к. RFID система является важной частью компании, программное обеспечение RFID должно быть очень надежным. Перед вводом в действие система должна быть очень хорошо протестирована. Однако в реальных условиях написать идеальное программное обеспечение невозможно, поэтому система должна минимизировать время вынужденного бездействия.

Отказ от ответственности

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

 

Архитектура ПО для веб-приложений высокой степени сложности

Автор: Александр Третьякевич

Задачи архитектуры

Архитектура приложения должна строиться исходя из следующих задач:

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

 

Высокоуровневое определение архитектуры

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

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

Для хранения данных приложения система будет использовать основную базу данных, но отдельным службам также допустимо иметь свои собственные БД для уменьшения нагрузки на основную БД и оптимизации производительности.
Архитектура приложения позволяет его владельцам размещать раздельные службы на одном совместном хосте (физическом или виртуальном), на раздельных хостах или в кластерных конфигурациях. Для обеспечения большей гибкости и удобства обслуживания система использует реестр служб и диспетчер (как часть архитектуры шины ESB) вместе с централизованной системой управления/слежения (являющейся частью административного приложения). Также архитектура позволяет системе продолжать работу в случае отказа одной из вторичных служб (с частичной потерей функциональности).
Реализация технологии планируется на Java с широким использованием готовых модулей (желательно бесплатных и с открытым исходным кодом).

Компоненты архитектуры

Высокоуровневая схема архитектуры представлена ниже:

Подробное описание архитектуры элементов и модулей представлено ниже в тексте документа.
Обратите внимание на то, что некоторые службы не описаны в явном виде, т.к. являются функциональной частью набора служб ядра.

Синхронная шина ESB

В приложении будет использован ESB-подобный тип коммуникации между отдельными службами, формирующими цельное приложение. Все службы имеют открытый публичный интерфейс (через реестр служб), и используют системную синхронную транспортную шину для связи между собой по типу точка-точка. Синхронная свяязь используется для запроса данных и выполнения процессов по запросу.
Архитектура обеспечивает службам возможность использования различных средств связи, в т.ч. веб-сервисов (Java Axis и др.), XML-RPC вызовов, RPC-вызовов (Corba и др.), собственных протоколов. Самое очевидное решение – привязка к одному транспорту (например, к веб-сервисам) для уменьшения избыточности. Реализация ESB может основываться и на проприетарном облегченном протоколе собственной разработки, и на уже имеющихся решениях с открытым исходным кодом (типа Mule Java).

Реестр служб

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

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

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

Асинхронная шина событий

Приложение будет использовать асинхронную шину событий для обмена асинхронными событиями между компонентами системы (как локальными, так и удаленными). Обработка событий начинается с получения их службами (хотя время обработки того или иного события определяется только самой службой) и заканчивается либо формированием новых событий, либо обработкой в режиме “тихого” процесса.
Шина событий имеет следующие режимы работы:

  • широковещательная рассылка события всем получателям
  • адресная посылка события определенному получателю
  • Р2Р-обмен между двумя службами

Асинхронный транспорт

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

  • JMS (сервер+брокеры, напр. Apache MQ) – стандарт де-факто в настоящее время
  • AMQP (напр. RabbitMQ) – быстро набирающая популярность альтернатива
  • любой проприетарный легковесный протокол обмена сообщениями (меньше вероятность дополнительных расходов на разработку)

База данных приложения

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

Клиентское приложение

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

  • слой DAO (может быть основан на Hibernate)
  • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
  • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

Клиентское приложение с самого начала должно быть готово к установке в кластере (несколько веб-серверов + Apache Balancer).

Административное приложение

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

  • слой DAO (может быть основан на Hibernate)
  • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
  • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

Служба контроля доступа (СКД)

В состав системы входит централизованная СКД, обеспечивающая всем остальным службам возможность контроля доступа. Учитывая кластерную организацию системы, СКД может использовать следующие способы упрощения системы и повышения её производительности:

  • единый сервис авторизации, включенный в состав службы (все контексты пользователя сохраняются в самой службе, клиентские службы и приложения работают только с токенами)
  • каждая служба может использовать кэш разрешений (через интеграцию с универсальным узлом СКД на сервере) для уменьшения нагрузки на сеть; дальнейшим архитектурным усовершенствованием может стать использование распределенного пула памяти/кэша (напр. Terracota) для увеличения производительности и упрощения процедуры синхронизации кэша.

Служба массовых уведомлений (СМУ)

СМУ обеспечивает системе возможность отправки уведомлений по e-mail (в зависимости от ситуации, служба может быть сделана максимально независимой от канала связи для обеспечения поддержки возможно большего числа способов уведомления, таких как внутренние сообщения, SMS и т.д.). СМУ решает следующие проблемы:

  • балансировка нагрузки на систему в случае необходимости отправки большого числа e-mail сообщений
  • использование нескольких хостов SMTP для обхода ограничений на число отправляемых сообщений (в т.ч. ограничений спам-фильтра) и увеличения пропускной способности системы в целом
  • отложенная обработка заданий на уведомление (полностью асинхронный режим работы клиента)

Служба статистики

Служба статистики предназначена для обработки сырых данных из приложения и генерирования рассчитанной и подготовленной статистики (в системах большого масштаба немедленная обработка статистики по каждому запросу является крайне неэффективной). Статистические данные могут сохраняться как в главной БД, так и в выделенной БД статистики (для повышения производительности и облегчения резервного копирования). Служба статистики также ответственна за контроль целостности данных в БД статистики.
Т.к. служба статистики является асинхронной, пользователь может выделять записи основной БД типа “только чтение” в качестве источника для сбора статистических данных (незначительная латентность БД в данном случае не представляет серьезной проблемы).

Служба оплаты

Служба оплаты обеспечивает необходимый уровень абстракции для работы с различными платежными системами в интернете и предоставляет интерфейс для оплаты в режиме оффлайн. Ядро службы оплаты предоставляет стандартный набор платежных инструментов, в т.ч. комбинированные платежи (по картам и т.д.), возвраты / Net30, периодическое пополнение, отчеты и т.д.

Служба рекламы

Служба рекламы предоставляет возможность размещения баннерной рекламы раличных типов (PPC/PPI) и осуществляет отслеживание баннеров для службы статистики.

Служба поиска

В системе предусмотрено 2 способа поиска: полнотекстовый (основан на внутреннем индексировании данных, индексах из внешних источников и тэгах) и бизнес-поиск (специфический поиск для бизнеса с расширенными возможностями). Полнотекстовый поиск может быть реализован на поисковом движке Lucene (например, в форме интеграции Compass / Hibernate Search). Реализация бизнес-поиска зависит от его конкретного придназначения.

Служба индексирования / веб-обходчик

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

Вам понравилась статья и Вы хотите заказать у нас приложение? Свяжитесь с нами прямо сейчас!

Видео в Интернете: хранение, доступ, варианты развертывания системы

 

Постановка задачи

Основная задача заключается в создании системы для обеспечения работы с видеоподкастами (совокупность видео файлов, которые распространяются через Интернет, используя настройки RSS-потока для воспроизведения на переносимых медиа проигрывателях и персональных компьютерах), записанных пользователями и загруженных на сервер. Доступ к видео должен быть предоставлен по запросу пользователя или через подсоединение пользователя к широковещательному каналу в реальном времени. Ряд пользователей (привилегированных) должны иметь возможность создавать подкасты (например, загружать оцифрованное видео стандартных форматов (AVI, MPEG2), записанные на персональную видеокамеру). Все пользователи должны иметь возможность просматривать подкасты через веб-браузеры как часть веб-страницы.

Способы доступа к видео:

Загрузка

Чтобы воспроизвести видео на вашем компьютере, вам необходимо полностью его загрузить. Используется HTTP протокол.

Прогрессивная загрузка

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

Потоковая передача данных

Данный метод публикации требует дополнительного ПО: необходим сервер потоковой передачи данных. Видео информация подается пользователю в форме потока, для просмотра необходим видео проигрыватель потоковой передачи данных. Несмотря на то, что сервер потоковой передачи данных имеет свой собственный формат для потоковых медиа, некоторые из них поддерживают формат MPEG-4 (Darwin Streaming Server/QuickTime Streaming Server, Helix Server, например).

Потоковая передача данных в режиме реального времени

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

Основные задачи сети потоковой передачи видео

Реализация потоковой передачи видео

На текущий момент существует четыре крупные компании, занимающиеся широковещательной потоковой передачей видео. Это такие компании, как: Apple, Real Networks, Adobe и Microsoft. Apple представлена коммерческим QuickTime Streaming Server и его аналогом с открытым исходным кодом – Darwin Streaming Server. Компания Adobe усовершенствовала Macromedia Flash Communication Server и выпустила его под брендом Flash Media Server. Кроме этого, они имеют FLV сервер Red5 с открытым исходным кодом. Real Networks поддерживает сервер Helix. Пользователи Microsoft Windows Server 2003 могут использовать бесплатный Microsoft Video Server, который может транслировать потоковое видео и аудио в специальном формате Microsoft: Windows Media Format.

Конвертация форматов

Не все видео форматы имеют возможность потоковой передачи. Поэтому необходимы специальные инструменты для конвертации видео файлов из формата пользователя в формат, подходящий для потоковой передачи данных. Существует несколько приложений, которые могут выполнить данную задачу весьма эффективно. Одно из них – это ffmpeg – приложение, которое может конвертировать видео файлы в различные форматы. У данного приложения есть еще одно несомненное преимущество – возможность запуска в режиме пакетной обработки для автоматической конвертации форматов. Основным недостатком приложения является некоторая сложность регулирования, дополнительных преобразований и установки библиотек. Данное приложение также может быть скомпилировано в форме статической или динамической библиотеки для дальнейшего использования в проектах C/C++. Также необходимо упомянуть Windows Media Encoder для систем Windows, т.к. данный продукт принадлежит Windows Media Series и позволяет конвертировать видео в несколько форматов. Существует возможность разрабатывать свои собственные компоненты на базе Microsoft Windows Media 9 Series благодаря возможностям совершенствования Windows Media SDK. Этот пакет программ для Windows 2003 Server абсолютно бесплатен.

Adobe Flash Media Encoder представляет собой другой инструмент для кодирования видео, позволяющий конвертировать файлы в формат FLV (Sorenson or кодеки on2). Он может быть запущен из командной строки или в режиме GUI.

Встраивание видео в веб-страницу

Встраивание видео реализуется с помощью объектов ActiveX (для IE) или плагинов. Для каждого из представленных серверов реализуется отдельный вариант встраивания видео в веб-страницу. Потоковая передача видео с помощью серверов Apple (Darwin/QuickTime Streaming Server), также как и посредством сервера Helix совместимого с Apple формата (RealNetworks) транслируется с помощью встроенной стандартной панели инструментов, которую можно скрыть, и своего рода API, чтобы контролировать воспроизведение и текущее состояние видео. Широчайший спектр различных проигрывателей используется с FLV (Flash Media Server, Red5) из-за легкости разработки Flash приложений для взаимодействия FMS/Red5 и широких возможностей среды разработки Flash (фактически, существует только один Flash FLV проигрыватель, но он «завернут» в различные Flash приложения). Но высокая цена сервера Flash Media является безусловным недостатком (особенно для большого количества соединений). Одной из особенностей формата FLV (Flash Live Video) является возможность постепенной загрузки видео с сервера без использования FMS. В таком случае видео не будет передаваться поточно. Воспроизведение потоковой видео трансляции с сервера Windows Media возможно посредством плагинов ActiveX или Windows Media Player. Другие платформы используют сторонние проигрыватели, такие как, например, Starbak Embedded Streaming для Линукса. Также требуется встроенный компонент VBrick для проигрывания потокового видео в форматах Windows Media. Необходимо также встроить RealPlayer или схожий сторонний проигрыватель в страницу, чтобы проигрывать видео в формате RealVideo с сервера Helix.

Варианты развертывания системы

Система потокового видео, базирующаяся на Apple Darwin Server

Сервер: бесплатный сервер Darwin 5.5.1 с открытым исходным кодом для потокового вещания.

Проигрыватель:QuickTime 6 встроенный в веб-страницу.

Конвертер видео: ffmpeg (реализация для Windows или Linux).

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодировки подкастов в формат MP4 или HINTED MOV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы.

Преимущества:бесплатный сервер потокового вещания, готовый использовать встроенный в веб-страницу проигрыватель.

Недостатки: отсутствие возможности изменять дизайн проигрывателя, необходимость ресурсоемкого конвертирования формата файлов подкаста после добавления.

Система потокового видео, базирующаяся на Flash Media Server 2

Сервер:Flash Media Server 2.

Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файла.

Конвертер видео: ffmpeg (реализация для Windows или Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для декодирования подкастов в формат FLV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы, содержащей Flash-приложение.

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

Недостатки: цена Flash Media Server.

Система потокового видео, базирующаяся на Red5 Server

Сервер: сервер Red5 с открытым исходным кодом.
Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файлов.

Конвертер видео: ffmpeg (реализация для Windows or Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодирования подкастов в формат FLV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы, содержащей Flash-приложение.

Преимущества: бесплатный FLV сервер, возможность использования собственного проигрывателя пользователя, гибкость разработки приложения благодаря Flash-технологии.

Недостатки: небольшое количество одновременных подключений (не более 15 для стабильности работы), требуется Java SDK, возможные изменения спецификации RTMP протокола компанией Adobe.

Система прогрессивной загрузки, базирующаяся на FLV

Сервер: Web сервер. Потоковый сервер не требуется.

Проигрыватель: Flash-приложение, поддерживающее проигрывание файлов.

Конвертер видео: ffmpeg (реализация для Windows или Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодирования подкастов в формат FLV для вещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в режиме постепенной загрузки внутри определенной веб-страницы, содержащей Flash-приложение.

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

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

Система потокового видео, базирующаяся на Windows Media 9 Series

Сервер: Windows Media Server для потоковой передачи данных.

Проигрыватель: Проигрыватель Windows Media Player 9/10, встроенный в веб-страницу, или в сторонний проигрыватель.

Конвертер видео: Microsoft Video Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно). Операционная система – Windows 2003 Server.

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для декодирования подкастов в формат WMV для потокового широковещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в потоковом режиме внутри определенной веб-страницы.

Преимущества: бесплатный потоковый сервер, если установлена операционная система Windows 2003 Server, готовая к использованию встроенного проигрывателя в веб-страницу.

Недостатки: отсутствие возможности изменять дизайн проигрывателя, необходимость ресурсоемкого конвертирования формата файлов подкаста после добавления, необходимость установки Microsoft Windows 2003 Server, возможные проблемы с просмотром видео на персональном компьютере с другой операционной системой.

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

 

Чего лучше избегать при разработке архитектуры?

 

В последнее время я много работаю над распределенной кластерной веб-системой, и в ходе работы уяснил для себя несколько моментов, которыми с радостью поделюсь. Всё нижеследующее добыто кровью, потом и потерянной прибылью…

Не полагайтесь на стабильность

“Это же элементарно!” – скажете Вы. И я соглашусь, мне тоже это было известно с самого начала. Но в процессе разработки и внедрения судьба не раз ударяла меня об этот угол. Любой вменяемый разработчик обязательно включит в состав распределенного решения средства восстановления/повтора. Отсутствие компонентов, ответственных за стабильность, может иметь далеко идущие последствия.

 

К примеру, представим себе сервер на 100-мегабитном канале, выполняющий 50 одновременных задач. Вы настроили систему на выполнение 50 задач и расслабились. На следующий день сетевой провайдер срезал скорость вашего канала со 100 до 10 мегабит. И всё! Сервер начинает медленно помирать…

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

Например, у нас 4 сервера: A, B, C и D. Узел D пытается пинговать узел A и не может до него достучаться. Что в таком случае он сделает? Уничтожит запись об узле А в реестре узла. Но отсутствие пинга еще не означает, что сервер не работает! Оно просто означает, что D не может связаться с А. Другие узлы (В и С) могут по-прежнему работать с А без проблем. Но теперь, когда узел D удалил из реестра информацию об А, ни один из узлов не сможет работать с А. Главной ошибкой здесь является предположение о том, что связь A-D идентична по свойствам связям А-В и А-С.

Так что будьте начеку. Не возлагайте ложных надежд на стабильность и свойства. Намного лучше сделать систему гибкой.

Не полагайтесь на систему DNS

Это дальнейшее развитие предыдущей идеи. Система DNS уже довольно стара, и её слабые места общеизвестны. В большинстве случаев сервера DNS используют UDP, что порождает проблемы с надёжностью. Даже если никому не нужно атаковать ваш DNS-сервер, он может стать источником неприятностей из-за потерь в UDP-пакетах, и т.д.

Но главным риском является распределенная сущность DNS. В большинстве случаев её невозможно контролировать полностью. Есть и сервер TLD, и DNS-сервера датацентра, и сервер регистратора доменных имен, и ещё много элементов. В случае возникновения проблем у вас может уйти не один день только на то, чтобы связаться с ними всеми и выяснить, что происходит.