Создание микросервисов

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

Отравление кэша: предостережение

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

Однажды, почти сразу после обычного планового выпуска, начали происходить весьма странные вещи. Была допущена ошибка, при которой к небольшому поднабору страниц в коде вставки кэш-заголовка применялось логическое условие, в результате чего заголовок вообще не изменялся. К сожалению, незадолго до этого изменили и само нижестоящее приложение и в него был вставлен HTTP-заголовок постоянной свежести Expires: Never. Ранее это не производило никакого эффекта, поскольку заголовок переписывался. А теперь никакой перезаписи не происходило.

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

Как уже упоминалось, кэширование может проводиться в нескольких местах. Когда дело касается обслуживания контента для пользователей общедоступного веб-приложения, между вами и клиентом может быть несколько средств кэширования. Перед сайтом может быть не только что-нибудь вроде CDN-сети — кэширование может использоваться также некоторыми поставщиками интернет-услуг. Можете ли вы контролировать такие средства кэширования? И даже если можете, остается еще одно средство кэширования, над которым у вас нет практически никакого контроля, — это кэш в браузере пользователя.

Страницы со свойством постоянной свежести Expires: Never застревают в средствах кэширования многих ваших пользователей и никогда не будут аннулированы, пока кэш не будет заполнен или пользователь не очистит его вручную. Понятно, что мы не можем инициировать ни то, ни другое событие; единственное, что можно сделать, — изменить URL-адреса таких страниц, чтобы инициировать их повторное извлечение.

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

Автоматическое масштабирование

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

Например, у вас также может применяться масштабирование, запускаемое при известных тенденциях. Вам может быть известно, что пиковая нагрузка на систему наблюдается между 9:00 и 17:00, поэтому вы подключаете дополнительные экземпляры в 8:45 и выключаете их в 17:15. Если вы пользуетесь такими средствами, как AWS, в котором имеется очень хорошая встроенная поддержка автоматического масштабирования, выключение ненужных экземпляров поможет сэкономить деньги. Чтобы узнать, как изменяется нагрузка в течение дня и недели, понадобятся соответствующие данные. У некоторых разновидностей бизнеса имеются также вполне очевидные сезонные циклы, поэтому, для того чтобы сделать правильные выводы относительно объема вызовов, вам нужны ретроспективные данные.