Джош Вэнс знакомится с хаотичным и красочным миром микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами, и их преимуществ.
Основываясь на этом фундаменте, он исследует культурные, архитектурные и эксплуатационные практики, которые ведут к мастерству микросервисов.
Конференция QCon. Освоение хаоса: Руководство Netflix по микросервисам.
Часть 1 Конференция QCon. Освоение хаоса: Руководство Netflix по микросервисам.
Часть 2 Группы автомасштабирования помогут восстановить сеть.
Я уверен, что вы с ним знакомы, но я должен подчеркнуть, насколько это фундаментально и важно для запуска микросервисов в облаке.
У вас есть минимум и максимум, а также метрики, которые вы используете по мере роста своей группы.
Если вам нужен новый экземпляр, вы просто вытягиваете и вращаете любой образ из S3. В этом есть ряд преимуществ.
Во-первых, это эффективное использование мощности компьютера, поскольку вы меняете ее по требованию.
Вышедшие из строя агрегаты легко заменяются новыми.
Но самое главное, что при скачках трафика, например, во время DDoS-атак или из-за ошибок производительности, автомасштабирование позволяет поддерживать работу системы, пока вы понимаете причины и устраняете неполадки.
Я настоятельно рекомендую использовать это масштабирование, поскольку оно неоднократно спасало нас от серьезных сбоев.
И, конечно же, вы хотите быть уверены, что он всегда работает с Хаосом.
Chaos Monkey Chaos Monkey — это наш инструмент, который случайным образом уничтожает экземпляры или процессы AWS на серверах, обслуживающих сервис Netflix. Этот инструмент подтверждает, что если один из узлов умирает, то все остальное продолжает работать без проблем.
После внедрения Chaos Monkey мы смогли круглосуточно убедиться в том, что все узлы имеют избыточность, падение одного узла не приводит к каким-либо последствиям, а каждая проблема документируется, чтобы в дальнейшем можно было применить готовое решение для исправления.
это.
Давайте посмотрим, что такое Stateful-сервисы.
Это базы данных, кэши и пользовательские приложения, использующие внутренние кэши с большими объемами данных.
Когда мы реализовали многорегиональную архитектуру и попытались использовать общие стратегии репликации данных, такие приложения создали большую проблему.
Поэтому я настоятельно рекомендую по возможности избегать хранения вашей бизнес-логики и состояний в одном приложении.
Stateful-сервисы характеризуются тем, что потеря одного узла является значимым событием для системы.
Замена данного устройства на новое может занять несколько часов.
Существует два разных подхода к кэшированию.
Как я уже говорил, в нашу команду вошли бывшие сотрудники Yahoo, имевшие большой опыт работы с ha-proxy-кэшами.
Они использовали схему выделенных серверов для пользователей.
То есть пользователь всегда попадал на тот же узел, где находился кэш с единственной копией данных.
Проблема заключалась в том, что при выходе из строя этого узла пользователь терял доступ ко всему сервису.
На раннем этапе существования сервиса, еще до появления HYSTRIX, возникали ситуации, когда выход из строя одного узла приводил в негодность весь сервис Netflix. Исправление проблемы заняло 3,5 часа, в течение которых мы ждали, пока кеш заполнится сам, чтобы запрос можно было выполнить.
На следующем слайде показана схема Dedicated Shards, которая представляет собой отказ от использования пользовательского шаблона выделенного сервера.
Возвращаясь к биологии, избыточность является фундаментальным фактором.
У нас две почки, и если одна откажет, мы сможем жить за счет другой, у нас два легких, но мы можем выжить и с одним.
Netflix подошел к проблеме, используя принцип архитектуры человеческого тела.
Увеличить нагрузку мы не сможем, но сможем жить на одном из «органов».
Основная технология в этом сценарии — совместное использование записей в EVCache. Данные записываются не только на несколько узлов, но и в несколько зон доступности.
Чтение из них происходит локально, но опять же при необходимости приложение может читать из нескольких зон.
Это очень успешная модель, которую использует почти каждый виртуальный сервис Netflix.
Давайте поговорим о гибридных сервисах, которые представляют собой комбинацию сервисов без отслеживания и с сохранением состояния.
В этом случае очень легко использовать EVCache как наиболее подходящую технологию отказоустойчивости.
Он позволяет обрабатывать 30 миллионов запросов в секунду, это 2 триллиона запросов в день.
EVCache может хранить сотни миллиардов объектов и десятки тысяч экземпляров класса memcash. Огромным преимуществом этой архитектуры является ее линейная масштабируемость, поэтому запросы возвращаются в течение миллисекунд независимо от нагрузки.
Конечно, вам нужно создать достаточное количество узлов, но сам процесс масштабирования предельно прост. 
Несколько лет назад мы столкнулись со сценарием, когда наша служба подписчиков полагалась на EVCache в несколько большей степени, чем это было необходимо, т. е.
существовал антишаблон, который мы уже обсуждали.
Практически все остальные сервисы доступны Абонентам.
Я имею в виду, что все хотели об этом знать, все хотели узнать идентификатор клиента, как получить доступ к учетным записям и другую информацию.
Все оффлайн и онлайн звонки приходили в один кластер.
Во многих случаях к одному и тому же приложению выполнялось несколько вызовов, поэтому вы могли вызывать EVCache так часто, как захотите, и на пике его активности мы наблюдали от 800 тысяч до миллиона запросов в секунду.
Откат имел бы смысл, если бы вы подумали об этом прямо сейчас: если кеш выйдет из строя, дайте мне возможность вызвать службу.
Однако возникла проблема с Fallback: при выходе из строя всего слоя EVCache все запросы шли к сервису и базе данных и возник антипаттерн — сервис с базой данных не справлялся с нагрузкой, которую брал на себя EVCache. Оказалось, что, казалось бы, правильный подход тоже привел к провалу — сбой EVCache стал причиной выхода из строя всей службы «Абоненты».
Решение этой проблемы сложное:
- перестаньте «прочищать» один и тот же системный кластер офлайн-запросами и звонками в режиме реального времени, разделяя рабочую нагрузку на онлайн- и офлайн-сегменты;
- организовать кэширование на уровне запроса, то есть всегда привязывать жизненный цикл записи к текущей области запроса, чтобы стало невозможным вызов одного и того же сервиса снова и снова;
- встраивание резервных токенов безопасности в пользовательские устройства.
Если клиент обращается к службе подписчиков, когда она недоступна, будет выполнен возврат к данным, хранящимся в этом зашифрованном токене.
Токен содержит достаточно информации, чтобы идентифицировать пользователя и позволить ему выполнять основные операции по использованию нашего сервиса.
Рассмотрим вариации — разные варианты архитектуры сервиса.
Чем больше таких вариантов, тем больше проблем возникает при увеличении масштаба системы, операционных отклонениях, при которых эксплуатационные показатели отличаются от базовых показателей сервиса, или при внедрении новых языков или контейнеров.
Операционный дрейф — это неизбежное старение различных факторов, поддерживающих сложную систему, которое происходит непреднамеренно.
Отклонения выражаются в периодическом возникновении пороговых нагрузок, таймаутов, задержек и падении производительности при добавлении нового функционала.
Однако ручная работа по устранению проблем в этой области не отличается особой эффективностью и зачастую требует повторения одних и тех же манипуляций с небольшими различиями в исходных данных.
Можно сказать, что этот процесс основан на чистом энтузиазме команды разработчиков.
Если вернуться к биологии, то можно провести аналогию с нервной системой человека.
Он автономен и автоматизирован, поэтому вам не придется беспокоиться о жизненно важных процессах, таких как пищеварение или дыхание.
Поэтому мы хотели создать среду, в которой мы могли бы автоматически внедрять лучшие практики, не думая о том, как это сделать.
В Netflix мы добиваемся этого за счет постоянного обучения персонала и быстрого изучения инцидентов по мере их возникновения, а также автоматизации внедрения лучших практик по устранению проблем в инфраструктуру.
Непрерывное обучение и автоматизация — это цепочка последовательных действий: инцидент — регистрация события — комплексное рассмотрение причин инцидента — восстановление функциональности — анализ — поиск лучшего решения — автоматизация — внедрение.
Таким образом, «знание становится кодом», который интегрируется непосредственно в микросервисную архитектуру.
За несколько лет мы накопили лучший опыт и сформулировали общие принципы, которые мы назвали «Готовое производство», или «Готовый продукт».
Это контрольный список или план действий Netflix. Каждый из принципов основан на автоматизации и постоянном совершенствовании модели взаимодействия с сервисом:
- Оповещения
- Апач и Томкэт
- Автоматический канареечный анализ
- Автоматическое масштабирование
- Модель хаоса
- Последовательные, последовательные имена
- Конфигурация ELB
- Проверка функциональности Healthcheck
- Неизменяемые образы машин
- Сжимаем – тестируем.
Он состоит из запуска определенных тестов или тестов, чтобы увидеть изменения в производительности и рассчитать критическую точку приложения.
Затем он проверяет, было ли последнее изменение неэффективным, или определяет рекомендуемые параметры автомасштабирования перед развертыванием.
- Развертывания Red/Black состоят из выпуска, который сокращает время простоя и риски за счет запуска двух идентичных производственных сред: Red и Black. В любой момент времени только одна из сред «работает» и обрабатывает весь трафик.
- Тайм-ауты, повторные попытки, откат.
Немного рекламы
Спасибо, что остаетесь с нами.Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, облачный VPS для разработчиков от $4,99 , уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от 19$ или как правильно раздать сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только здесь 2 x Intel TetraDeca-Core Xeon, 2 x E5-2697v3, 2,6 ГГц, 14C, 64 ГБ DDR4, 4 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТВ от 199 долларов США в Нидерландах! Dell R420 — 2x E5-2430, 2,2 ГГц, 6C, 128 ГБ DDR3, 2 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТБ — от 99 долларов США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки? Теги: #ИТ-инфраструктура #Конференции #Микросервисы #Анализ и проектирование систем #oracle #netflix #Javaweb #Javaweb
-
Поиск По Ключевым Словам В Pdf
19 Oct, 24 -
Как Найти Идеи Для Скрытых Статей
19 Oct, 24 -
Примечания По Миграции На Java 10
19 Oct, 24
