Переадресация ссылок

Материал из Course Orchestra
Перейти к: навигация, поиск
Showcase

Создание решений на КУРС:Showcase

Общая информация

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

Решение этой проблемы давно известно и очевидно вытекает из вышесказанного. Золотым стандартом при разработке высоконагруженных веб-систем и приложений является четкое разделение возвращаемых клиенту данных на статические и динамические, а также разделение серверов, которые эти данные отдают. Обычно считается, что сервера приложений (JBoss, GlassFish) или контейнеры сервлетов (Tomcat) должны заниматься обработкой запросов на получение динамического контента. И это они делают очень качественно и быстро. А вот отдачей статического контента должны заниматься отдельные сервера, оптимизированные для отдачи клиентам таких данных. Такие сервера разрабатывались специально и оптимизированы именно для этих задач. Наиболее известными серверами для отдачи статического контента являются Apache HTTP и nginx. Они позволяют организовать отдачу статического контента и его хранение на сервере, имеют большое количество специфических настроек, пригодных для частных случаев.

Как связать теперь два независимых друг для друга сервера - сервер статических данных (медиафайлы и прочее) и сервер динамических данных, где и находится наше веб-приложение Showcase?

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

Основная идея

Реализация данного механизма очень проста.

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

При обращении к веб-приложению Showcase, серверная часть веб-приложения выполняет следующие операции:

  • обрабатывает все запросы, приходящие на него с клиентских мест;
  • если запрос касается статического контента (файлов mp4, jpeg и др. - тип контента для перенаправления можно настраивать), то система автоматически перенаправляет этот запрос с сервера приложения на сервер, содержащий статический контент;

•если запрос не является запросом статического контента, то он поступает на сервер веб-приложения Showcase для его последующей обработки системой.

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


HrefRedirect1.png

Обработка запросов и их переадресация происходит в самом теле фильтра. Любой запрос к веб-приложению проходит через фильтр. Если запрос (url) направлен на получение статического файла с расширением, совпадающим с одним из расширений из настроек переадресации Showcase, а также путь соответствует путям переадресации в настройках, то фильтр вызывает скрипт celesta, python или хранимую процедуру. Вызываемой процедуре или скрипту на вход передается полная url-строка запроса. В своем коде скрипт или процедура анализирует запрос и возвращает в ответ адрес url, на который нужно данный запрос переадресовать. Таким образом, фильтр отправляет клиенту ответ с кодом 302 (Moved Temporarily), содержащий новый адрес для перенаправления. Все браузеры, получая ответ с кодом 302, переадресуют запрос по новому url. В нашем случае это будет сервер статического контента.

Для примера, схема переадресации потокового видео (файла с расширением mp4) представлена на рисунке ниже.


HrefRedirect2.png

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

Настройка механизма переадресации ссылок для получения статического контента с другого сервера

Основным файлом для настройки свойств переадресации Showcase является файл redirect.properties, который должен лежать в корне папки пользовательских данных (рядом с generalapp.properties).

В процессе старта происходит чтение настроек этого файла и активация фильтра для переадресации.

В случае, если данный файл не найден, в консоль выдается соответствующее предупреждение и Showcase стартует в обычном режиме, фильтр переадресации не активируется.

В дистрибутив платформы включен шаблон данного файла redirect.template.properties.

Файл имеет следующее содержимое:

  path.to.redirect = lectures, video
  extension.to.redirect = mp4, jpg
  redirection.proc = edu.webtext.webtextFile.webtexttest.cl

Свойство path.to.redirect содержит в себе части пути, которые могут быть переадресованы. Это нужно для оптимизации, чтобы не происходила проверка всех путей (может значительно замедлить работу сервера), а только тех, которые определены разработчиком для статического контента. В примере выше, все запросы в url которых присутствуют "lectures" или "video" (например, http://localhost:8080/Showcase/video/file.mp4) будут проверяться на необходимость переадресации, то есть для них будет активирован фильтр переадресации.

Свойство extension.to.redirect определяет через запятую список расширений запрошенного контента, для которых будет вызываться хранимая процедура, python или celesta скрипт с именем, заданным в redirection.proc. В своем ответе данная процедура возвращает ссылку для переадресации. Название процедуры redirection.proc указывается в соответствии с принципом универсальных источников Showcase.

Пример celesta-скрипта для переадресации:

   def webtexttest(context, initUrl):
       return "http://172.16.1.132/anafilaxy/data/video1.mp4"

где initUrl - это полный url запроса, пришедшего на сервер Showcase, context - контекст вызова celesta.