Путь к эффективной работе и обслуживанию 900 миллионов активных пользователей WeChat в месяц

Микросервисы WeChat Docker Эксплуатация и техническое обслуживание

Эта статья составлена ​​на основе речи станции GOPS 2017. Пекин «Путь к эффективной эксплуатации и обслуживанию 900 миллионов активных пользователей WeChat в месяц».

Об авторе:

У ЛэйМенеджер по эксплуатации и обслуживанию базовой платформы WeChatВ 2010 году он присоединился к команде QQ по эксплуатации и обслуживанию почтовых ящиков, и с момента появления первой версии WeChat он поддерживал варварский рост с нуля до сотен миллионов одновременных подключений к сети. В настоящее время отвечает за основные операции и обслуживание бизнеса, такие как отправка и получение сообщений, круг друзей и т. Д., Сосредоточив внимание на построении автоматической системы эксплуатации и обслуживания.

Сегодняшняя тема в основном касается упругого масштабирования, расширения и сжатия.

Когда объем бизнеса WeChat растет, нас больше заботит эффективность. На начальном этапе он мог удвоиться за два-три месяца. Как мы можем обеспечить нашу операционную эффективность? Последнее может быть в основном связано с затратами. Наш рост немного замедлился после 2014 года, поэтому основное внимание будет уделено затратам.

Делится на четыре части:

  • Эксплуатационные характеристики

  • облачное управление

  • Управление мощностями

  • автоматическое планирование

1. Эксплуатационные характеристики

1.1 Спецификация файла конфигурации

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

Спецификация профиля разделена на следующие элементы:

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

  • Почему это упоминается в одном и том же управлении элементами конфигурации в разных службах? Некоторые элементы конфигурации могут понадобиться вам в этой службе, а эти элементы конфигурации — в другой службе. Если вы измените этот элемент конфигурации, отправите ли вы услугу A и услугу B снова? У нас есть набор механизмов. Каждая машина и каждый каталог будут иметь глобально общий элемент конфигурации. Здесь мы будем контролировать выпуск с помощью некоторых автоматизированных методов в градациях серого. Этот элемент выбирается отдельно.

  • Различное управление элементами конфигурации разных экземпляров в одном и том же сервисе не уверено, что вы столкнетесь с похожими проблемами при работе, даже если вы используете Docker, ваше управление образами хорошее. Когда вы развертываете экземпляр, вашему бизнесу может потребоваться внести некоторые коррективы в экземпляр 1. Конечно, вы также можете использовать сценарии для управления им. Но мы думаем, что это более сложное состояние, мы будем извлекать в него все эти различия единообразно, и постараемся сделать MD5 его конфигурационного файла согласованным во всех средах.

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

Для нескольких экземпляров одной и той же версии в одной и той же службе md5 файла конфигурации строго согласован во всех средах.

1.2 Спецификация службы именования

Название этой услуги важнее, разделено на три слоя:

  • LVS-подобная реализация уровня доступа

  • Реализация etcd класса логического уровня

  • Автоматизация конфигурации маршрутизации уровня хранения

Масштабирование службы — это проект эксплуатации и обслуживания, не зависящий от выпуска изменений НИОКР.

И уровень доступа, и уровень логики реализованы одинаково, и мы выполнили некоторые внутренние разработки на основе наших бизнес-характеристик.

Слой хранения немного похоже на QQ, QQ, кажется, логический слой, а слой хранения достигается с одинаковым названием, мы не сделали это в конфигурации слоя хранения здесь.

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

Масштабирование службы — это проект эксплуатации и обслуживания, и мы не хотим учитывать другие факторы при масштабировании службы, независимо от выпуска изменений R&D. У нас есть особенность.Наши исследования и разработки - это система изменений, обеспечиваемая эксплуатацией и обслуживанием.В принципе, ему не нужно ничего делать на ней, и вся цепочка открыта.Эксплуатация и обслуживание не должны заботиться о выпуске изменений , но нужно только управлять масштабированием службы.

1.3 Спецификация хранения данных

  • Уровень доступа без данных

  • Логический уровень с кешем с коротким циклом, со статическими данными, запретить динамическую посадку данных

  • Посадка данных на уровне хранилища на основе протокола paxos с кешем с длинным циклом

Масштабирование службы уровня доступа и уровня логики не требует учета переноса данных и частоты попаданий в кэш.

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

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

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

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

1.4 Краткое изложение эксплуатационных характеристик

  • Вехи

    • Сервис можно эксплуатировать и обслуживать

  • Реализовать меры

    • Изменить системный перехват

    • Сканировать всю сеть на наличие нерегулярных услуг

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

Чтобы реализовать работу и обслуживание сервиса, мы сделали некоторые перехваты в системе изменений.Следующие изменения могут не соответствовать нашим спецификациям работы или есть места, которые не соответствуют нашим спецификациям работы ранее.Мы остановим их и Требуются изменения для реализации нашей операции Спецификация размеров.

2. Облачное управление

Далее поговорим об облаке. Облаком все пользуются много, и в последние годы оно стало более популярным. Может быть, все больше используют Docker. Мы не используем Docker в WeChat, и о том, почему он бесполезен, мы поговорим позже.

2.1 Зачем переходить в облако

  • Общее количество микросервисов составляет почти 5 тыс.

  • Проблема вытеснения ресурсов для нескольких сервисов на одной физической машине

Давайте сначала поговорим о том, почему мы хотим перейти в облако. В 2013 и 2014 годах количество наших микросервисов достигло почти 5000. На самом деле, я только в последние годы узнал, что это называется микросервисами. Наш предыдущий метод реализации рассматривался как микросервисы для много лет.

На самом деле, когда я впервые говорил о микросервисах, я помню, что некоторые курсы по массовым операциям на QQ упоминали об этом, я думаю, что эта идея полностью соответствует микросервисам.

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

Развертывание нескольких услуг придется захватить ресурсы, основанные на этом факторе, мы находимся в облаке.

2.2 Какая часть облака на

  • Уровень доступа Исключительная физическая машина, достаточная мощность, несколько изменений

  • Логический уровень Гибридное развертывание, неконтролируемая емкость, частые изменения

  • Уровень хранения Эксклюзивная физическая машина, контролируемая емкость, меньше изменений

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

В логическом слое более 5000 упомянутых ранее микросервисов, поэтому это сбивает с толку, изменений много, а емкость неуправляема, поэтому эта штука в облаке.

На уровне хранения нет облака, но есть отдельное управление емкостью и миграция данных.

2.3 Облако на базе Cgroup

  • Настройка виртуальной модели

    • VC11 = 1 ядро ​​​​процессора + 1 ГБ памяти

    • VC24 = 2 ядра процессора + память 4G

  • Шардинг физической машины

Наш облачный метод — прямая Cgroup.Некоторые люди могут не знать название Cgroup.Мы используем механизм ядра Cgroup.

В существующей сети используйте аналогичную простую виртуальную модель для настройки, например 1 ЦП + 1 Гб памяти. На начальном этапе мы также учитывали некоторые факторы трафика, а позже отменили его.Трафик, гарантированный архитектурой нашей системы, не кажется проблемой.

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

2.4 Docker не включен онлайн

  • Фреймворк svrkit покрывает 100% всей сети и достиг стандартизации.

  • Сама структура в значительной степени зависит от взаимодействия IPC.

  • Ненавязчивый саморазвитый против навязчивого Docker

Вот список причин, по которым мы не использовали Docker.

Docker настолько популярен, что мы также запустили небольшое количество онлайн-раундов в 2014 и 2015 годах.

Наш фреймворк svrkit — это набор фреймворков, разработанных нами в рамках WeChat. Он покрывает 100% всей сети. Что значит 100%? Вообще нет открытого исходного кода, включая nginx, который вы можете использовать чаще всего. исследования и переключение, включая хранилище сзади, MySQL использовался на ранней стадии, а на более поздней стадии он был заменен собственными компонентами.

Текущая сеть на 100% покрыта нашей собственной структурой, и наша стандартизация и нормализация относительно хороши.

Возможно, некоторые из проблем, которые решает Docker, не являются проблемами для нас.

  • Во-первых, наша потребность в Docker не очень велика.

  • Второй момент — мы используем очень много IPC-взаимодействий в самом фреймворке, эти вещи на самом деле строго регламентированы в Docker, если мы будем использовать Docker, то мы можем разрушить различные механизмы в этих Dockers. Если это так, вы можете не использовать Docker.

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

2.5 Система планирования частного облака

Исходя из вышеперечисленных пунктов, мы разработали комплект системы Docker для управления облаком. Это наша частная облачная система планирования:

  • Самостоятельная разработка на основе svrkit framework

  • Преимущества основных систем планирования, таких как борг / пряжа / k8s / mesos

  • Покрытие 80% микросервисов

Основываясь на структуре svrkit + самоисследовании, о которой я упоминал ранее, система планирования, конечно, должна быть покрыта нашей собственной системой планирования, которая в настоящее время охватывает 80% микросервисов и покрыта почти на 100%.

2.6 Архитектура системы планирования частного облака

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

2.7 Краткий обзор управления облаком

  • Вехи

    • Изоляция ресурсов между службами

    • Пейджинговые операции масштабирования службы

  • Реализовать меры

    • Система развертывания перехватывает сервисы, которых нет в облаке

    • Активно трансформируйте основной бизнес

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

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

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

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

3. Управление мощностями

3.1 Как поддержать развитие бизнеса

Это кривая роста объема бизнеса, это кривая нашей мощности.

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

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

Второй момент-эффективность обработки.При недостатке мощностей кривая размечается.Сколько времени нужно для расширения емкости?Если это несколько дней или несколько минут,то эффективность разная.

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

Эту кривую нетрудно получить, если расширение происходит достаточно часто, именно кривая оптимальной мощности точно соответствует этому.

Вы обнаружите, что его емкость недостаточна в минутах, и ее расширение емкости тоже в минутах, тогда вы можете нарисовать такой набор одинаковых кривых.

3.2 Оценка производительности с использованием показателей оборудования

Мы бы сказали, откуда вы знаете, что сервис исчерпал свои возможности? Как правило, наша первая реакция — использовать аппаратные индикаторы, в том числе степень использования ЦП, объем дискового пространства, емкость сетевой карты и память. Это также решает проблему, но не решает всех проблем.

3.3 Использование ЦП для оценки производительности

Емкость обслуживания = текущая пиковая/испытательная нагрузка на ЦП.

Это способ использования ЦП для расчета пропускной способности службы.

Это простой пример.Например, если ваш текущий пик загрузки ЦП составляет 40%, по вашему собственному опыту это может достигать 80% загрузки ЦП, а простое удаление составляет 50% мощности.

3.4 Надежны ли аппаратные индикаторы

Эта вещь летает это? Я нарисовал два диаграмма здесь:

Некоторые из них, как на картинке слева, надежны, и их емкость в основном продолжает увеличиваться вместе с процессором.

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

3.5 Реальные случаи

Это пример трафика в действующей сети.Если вы увеличите трафик вручную, вы обнаружите, что некоторые сервисы всегда на 80%, а некоторые сервисы на 60%, поэтому они не могут подняться.

3.6 Ограничения аппаратных показателей

Аппаратные метрики, по нашему мнению, имеют некоторые ограничения:

  • Во-первых, разные сервисы зависят от типа оборудования, некоторые привязаны к ЦП, некоторые к памяти.

  • Во-вторых, качество критической точки невозможно предсказать.Когда ЦП близок к 80% или 100%, мы заметили, что качество некоторых услуг невозможно предсказать и оно нестабильно.Некоторые услуги могут работать до 80%, а процессор еще может быть стабильным.Обслуживание идет долго,какое-то до 80%,и некоторые запросы могут не возвращаться.

Действительно, после того, как появилось больше онлайн-сервисов, то, что вы делаете, становится не очень контролируемым.

Мы считаем, что для получения более точной модели производительности следует использовать опрессовку.

3.7 Метод измерения давления

Есть два способа нажатия сбоку:

  • Один из них — имитация трафика.

  • настоящий поток

Существует два типа сред:

  • тестовая среда

  • Живая сетевая среда

Четыре метода измерения давления.

ПервоеКогда смоделированный трафик воспроизводится в тестовой среде, команда тестирования выполняет некоторые внутренние проверки качества.Этот метод тестирования является обязанностью группы тестирования, и мы не слишком вовлечены.

секундаМоделирование трафика в реальной сети немного похоже на полносвязное стресс-тестирование. Например, Taobao часто делает это на Double Eleven. Для WeChat мы делаем это только во время китайского Нового года. WeChat New Year, похоже, похож на Double Eleven на Taobao. Одиннадцать, что является сравнением.Безумное состояние, поэтому мы будем использовать смоделированный трафик, чтобы попасть в живую сеть до нового года, это не очень распространенный метод стресс-тестирования.

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

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

3.8 Стресс-тест сети в реальном времени

It is very simple to implement the stress test on the live network. When your name service is relatively standard, it is a unified process, that is, the pressure side process. You can constantly adjust the weight of one of the services and observe the последствия.

3.9 Существующие испытания сети под давлением могут привести к аномалиям

В чем проблема с этим давлением?Каждый может придумать.Когда вы остановите службу,как вы можете гарантировать,что ничего не произойдет. Мы считаем, что здесь есть три момента:

  • Во-первых, вызовет ли испытание давлением неисправность, и сможете ли вы ее вовремя обнаружить.

  • Во-вторых, может ли стресс-тест вызвать какие-то глубинные проблемы, на самом деле ваш мониторинг не может их обнаружить.

  • В-третьих, как быстро восстановиться после настоящей неудачи.

Я думаю, что эти три вопроса являются более важными.

3.10 Самозащита служб

Хорошо ли себя защитили ваши различные службы? Мы ввели концепцию быстрого отклонения. Когда эта служба работает нормально, при подключении к Интернету может быть возможно обслужить 1 миллион запросов в минуту. Когда вышестоящая служба дает вам 5 миллионов, вы можете обработать только 1 миллион. Можете ли вы отклонить остальные 4 миллиона запросов — это то, что реализует наш фреймворк.

3.11 Защита от повторных попыток для восходящих служб

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

3.12 Стереоскопический мониторинг

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

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

3.13 Мониторинг второго уровня

Сможете ли вы быстро найти свою аномалию? Для этой проблемы мы модернизировали мониторинг минутного уровня до мониторинга второго уровня, и все аномалии можно найти в течение 10 секунд.

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

Вышеупомянутое все еще в минутах.

3.14 Динамический контроль скорости разряда

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

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

后面我们调了一下，其实这个也跟我们服务框架提供的能力相关，我们整个服务框架会有一个入队/出队的机制，每个微服务本身都会有这样的机制。 The backlog of the queue here is a key indicator. We will monitor the team delay. It is out of the team. It is found that it has a backup, and the performance has been able to keep it. The effect is this picture on право.前期是比较快的权重，当观察到队列已经有积压有延迟，就开始放缓，一直达到一个点，可能最后那个点是有一点点压测失败，实现这么一个效果，整个过程中可能只有几秒钟，就得到性能模型，得到压测真实的值。

3.15 Влияние измерения стресса на действующую сеть

Это результат нашего реального онлайн-сжатия.

Наклон, напечатанный на этом рисунке, заключается в том, что сначала он увеличивается относительно быстро, а затем медленно увеличивается на более позднем этапе, а затем останавливает точку измерения давления.

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

3.16 Резюме управления мощностями

Вещи, которые мы сделали, что есть несколько преимуществ:

  • Службы спроса на ресурсы могут точно определить количество только что упомянутых нескольких сотен микросервисов, как рассчитывается каждый из них.

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

4. Автоматическое планирование

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

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

Обычно мы позволяем ему работать в диапазоне от 50% до 60%, а 66% зарезервировано для аварийного восстановления.Сначала мы развертываем три IDC.Если вы хотите сбой двух, другой не будет ненормальным.Может быть, эти два пределы.

Мы оставим некоторое время, чтобы дать нам машину для покупки и будем контролировать трафик некоторых сервисов на 50%.

4.2 Автоматическое расширение в нештатных ситуациях

Есть также некоторые исключения:

  • Внезапное увеличение объема бизнеса не уведомило нас о некоторых действиях с продуктом. Мы будем использовать некоторые грубые методы для решения этой проблемы, включая ЦП. Мы установим для этого точку. Когда ваш ЦП пересечет эту точку, мы начнем расширение. автоматически.

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

4.3 Обоснованная оценка снижения производительности программы

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

4.4 Замкнутый цикл управления эффективностью

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

4.5 Несколько бизнес-форм

Это некоторые бизнес-формы нашей текущей сети.Возможно, будет больше верхней картины, которая открыла свой пик с 9:00 до 10:00 вечера.

Картинка посередине обычно связана с работой, например с WeChat, и чаще используется в рабочее время.

Есть еще нижняя.Типичным примером является событие WeChat.Событие WeChat кажется шагом в 22 часа ночи. Есть также некоторые более старые предприятия, такие как дрейфующие бутылки, в которых используется много мозгового порошка, и они будут охранять время 0 часов.

4.6 Снятие пиков и заполнение впадин

Что мы хотим делать с этими кривыми бизнеса?

Во-первых, пик такой высокий, и все наше снаряжение рассчитано на то, чтобы справиться с высочайшим пиком.Можно ли с этим пиком обращаться с особой осторожностью, чтобы не дать им опасное снаряжение.

Есть второй, после полуночи, при таком малом объеме работы оборудование весьма расточительно.

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

4.7 Пиковое сокращение онлайн-бизнеса

  • Регулярные ресурсы выпуска услуг после часов пик

  • Ресурсы приобретения западных услуг

4.8 Автономные вычисления для заполнения долины

  • Время выполнения автономных задач

    • 01:00 ~ 08:00 Неограниченное количество задач

    • 08:00 ~ 20:00 Контроль постановки задач в очередь

  • Ресурсы офлайн-задач занимают cpu.shares + memory.limit_in_bytes + blkio

  • Офлайн-задачи имеют самый низкий приоритет

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

С точки зрения занятости ресурсов конфигурация этих мест в основном контролируется Cgroup более строго.

Затем отрегулируйте приоритет автономных задач и используйте автономные задачи, чтобы заполнить наши низкие пики и долины.

4.9 Краткий обзор автоматического планирования

Это одна из наших целей в автоматическом планировании:

  • Получите полный контроль над всеми онлайн-сервисами и максимально эффективно используйте свои ресурсы

  • Для автономных задач вам не нужно подавать заявку на вычислительные ресурсы отдельно, просто используйте часть нашей онлайн-памяти процессора напрямую и храните ее отдельно.

END

Категории