вторник, 24 сентября 2013 г.

Программируемость в сети: паттерны версионности

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

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

Предположим, что на сегодняшний день сложилась подобная ситуация. Напрашивается вопрос, как организация развертывает и сопровождает несколько версии одного приложения или API, не сопровождая различные версии всей цепочки поставки приложений. Такой вариант может обойтись дорого. Лучше использовать программируемость в сети, чтобы реализовать поддержку версионности, обеспечивая соответствие клиентов, приложений или API.

Цель реализации паттерна версионности в инфраструктуре достаточно проста: запустить одновременно несколько версий, чтобы обеспечить миграцию клиентов. Существует два традиционных метода достижения данной цели:
  • Версионность на базе URI.
  • Версионность на базе заголовка HTTP.
Оба поддерживаются большинством распределяющих нагрузку прокси-серверов.



В обоих случаях, прокси-сервер должен уметь перехватывать и изучать запрос. Он выполняет функции посредника. Что касается клиента, здесь он служит конечной точкой. На самом деле, он является лишь предконечной точкой, ведь сам пункт назначения определяется, исходя из значений URI или заголовка HTTP.

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

Хотя паттерны версионности обычно используют значения URI протокола HTTP или заголовка Accept, нет никаких причин, по которым эту информацию нельзя переносить в сообщении (полезная информация) с помощью элемента XML (например, <version>3</version>).

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

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

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

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

источник

Комментариев нет:

Отправить комментарий