Я люблю Netflix; Мне нравится, что в нем есть такие материалы, как «Щенячий патруль» и «Свинка Пеппа», которые делают моих двух малышей счастливыми. Рекламы нет, и мне не нужно беспокоиться об автозапуске "The Shining" после "Pups Save Christmas", как если бы я загружался бесплатно с Youtube.

Это просто работает

Это тоже просто работает! Здесь нет плачущих детей, потому что он разбился на полпути к фильму «Мистер Скиннилегс», и это подводит меня к тому, что мне больше всего нравится в Netflix; их чистый чистый инженерный пессимизм. Вместо того, чтобы ценить свой код или свою инфраструктуру, они принимают наиболее фундаментально важный экзистенциальный факт инженерии; если что-то может пойти не так, скорее всего, так и будет.

Примите хаос

С помощью таких инструментов, как обезьяна хаоса (часть их обезьяньей армии) и Гистрикс (о которых я скоро расскажу), Netflix принимает этот факт, а не убегает от него или пытается обойти его теоретическими аргументами.

За десять с лишним лет работы инженером в различных компаниях я видел больше катастроф, чем мне хотелось бы вспомнить, когда люди говорили такие вещи, как «этого просто не может случиться ... это невозможно!». Угадай, что? Это случилось, и это, безусловно, было возможно. Это также стоило больших денег и расстроило многих клиентов и заинтересованных лиц, поэтому мой опыт определенно совпадает с пессимистическим подходом, который использует Netflix.

Вперед и DOS самостоятельно

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

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

Что происходит? Гридлок. Все потоки внешнего сервера ожидают потоков внутреннего сервера, которые ждут на больной третьей стороне, которая, скорее всего, находится в той же лодке.

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

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

Сейчас 3 часа ночи ... ты на связи ... звонит телефон ... тебе лучше позвонить Саулу.

Автоматический выключатель

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

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

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

Так что же такое Гистрикс?

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

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

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

Пример использования из реальной жизни

У нас есть приложение, которое подписывается на события, связанные с порядком, из очереди сообщений. Затем он украшает эти данные заказа описаниями продуктов, чтобы мы могли информировать наших клиентов по электронной почте о любых заменах или недоступных элементах в их заказе, как только он будет выбран. Для этого мы вызываем внутренние данные о продукте api. Мы также кэшируем эти данные в Redis, поэтому нам не нужно многократно обращаться к API для наиболее распространенных продуктов; много заказов, например, на 4 пинты молока.

Но что, если наш кеш Redis отключен? Этого не должно быть, но эй, это может быть и, вероятно, когда-нибудь.

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

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

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

Самостоятельное исцеление

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

В итоге…

Когда ваша система ломается, вам не всегда нужно звонить Саулу.