Резюме: Эта статья в основном поможет вам понять важность стабильности обслуживания и связанных с этим стратегий. Стратегия разделена на две части. В первой части представлены общие стратегии (ограничение тока, деградация, изоляция, тайм-аут, повторные попытки и кластеризация) для обеспечения стабильности обслуживания на уровне архитектуры. Второй аспект состоит в том, чтобы объяснить, как обеспечить стабильность с точки зрения процесса (проверка кода, измерение давления, уровень серого и мониторинг).
Профиль динамика:
Синьхайлун (Хуамин Ван Лонг), имеющий более чем десятилетний опыт работы в области развития Интернета, присоединился к Alibaba в 2013 году и активно занимается электронной коммерцией и разработкой приложений и архитектуры, связанных с сообществом. Он также является разработчиком и сопровождающим многих проектов с открытым исходным кодом. Представляет работы с открытым исходным кодом, клип, расширение для обрезки изображений на основе распознавания лиц.
Это живое видео-замечательный обзор, ткните сюда! Живой обзор: https://yq.aliyun.com/live/965 Обмен PPT: https://yq.aliyun.com/download/3530 Следующий контент основан на гостевых видео и совместном использовании PPT.
Этот обмен в основном сосредоточен на следующих трех аспектах:
- Важность стабильности
- Глава Архитектура стратегии безопасности
- Раздел, посвященный Процессу разработки Стратегии гарантий
Важность стабильности
Для многих предприятий стабильность обслуживания очень важна. Во-первых, стабильность принесет предприятиям прямые экономические потери. Например, сбой в Прайм-день Amazon в тот день привел к убыткам Amazon в размере до 99 миллионов долларов. Эта потеря от сбоя может в несколько раз превышать рыночную стоимость других небольших компаний. Таким образом, стабильность обслуживания оказывает большое влияние на компанию. Для отдельных лиц нестабильность обслуживания может повлиять на производительность сотрудников и даже повлиять на личные перспективы.
Глава Архитектура стратегии безопасности
Для обеспечения стабильности на уровне архитектуры общие стратегии включают ограничение тока, деградацию, изоляцию, тайм-аут, повторные попытки и кластеризацию.
1. Ограничение по Току
Цель Ограничения Тока
Существует две основные цели ограничения тока. Первый-предотвратить работу системы при высокой нагрузке, а второй-эффективно использовать ресурсы сервера. Почему мы ограничиваем ток? Если запрос не заблокирован, это может вызвать тревогу сервера. Если сервер может обрабатывать только 100 запросов в мирное время, еще два запроса могут быть обработаны с трудом, но если внезапно появится еще 500 запросов, следующие 400 запросов будут только отложены. Когда сервер обрабатывает 500 запросов, время ожидания использования будет слишком долгим, и окончательное отставание в обработке запросов может быть просто неэффективным, потому что пользователи уже давно потеряны.
Алгоритмы Ограничения Тока
Распространенные алгоритмы ограничения тока включают алгоритм “дырявого ковша” и алгоритм “ковша токенов”. Алгоритм “дырявого ведра” показан на следующем рисунке. Пример на рисунке имеет небольшое ведро с отверстием под ведром. Каждую каплю воды можно рассматривать как просьбу войти. Скорость капания одинакова, а высота отверстия фиксирована. Алгоритм дырявого ковша может обеспечить время загрузки каждого запроса, то есть определить количество запросов, которые могут быть обработаны в секунду.
Алгоритм устранения утечки реализован следующим образом. Высота ковша может быть установлена на пять, с двумя пиками в секунду. Первые пять результатов выполнения являются истинными, а второй-ложным, что означает, что ведро заполнено, а затем вытекли две капли воды, потому что сон длится одну секунду, когда ложь, поэтому ниже приведены две истины.
Ведро для токенов
Как показано ниже, алгоритм корзины токенов также имеет корзину, но она не протекает. В ведре есть несколько жетонов. Каждый запрос принимает токен в корзине. Если жетона нет, он может подождать. Если токен заполнен, он не будет добавлять токены в корзину. Этот метод в основном может достичь цели ограничения тока. Существенное различие между алгоритмом корзины токенов и алгоритмом “дырявой корзины” заключается в том, что алгоритм “дырявой корзины” в основном протекает с одинаковой скоростью, когда он получает количество запросов на заднем конце, но внутренняя часть алгоритма корзины токенов может иметь внезапные запросы. Если ведро заполнено, все жетоны в ведре можно забрать.
Ниже приведена реализация Lua – кода алгоритма корзины токенов. Конечно, читатель также может использовать скрипт Nginx, Javascript или PHP.
2. Деградация
Случаи понижения в должности в сообществе
Обычно система будет сталкиваться с некоторыми нестабильными ситуациями после выхода в Интернет, такими как зависание redis или даже зависание базы данных MySQL. Когда возникает нестабильность, как система может гарантировать, что эти услуги будут предоставляться и впредь? Возьмем в качестве примера случай сообщества, даже если MySQL зависнет, он должен быть в состоянии гарантировать, что сообщество предоставляет базовые читаемые сервисы для пользователей. Одна из стратегий состоит в том, чтобы кэшировать некоторые горячие данные, то есть информацию, которую пользователи часто просматривают, или последнюю информацию, и показывать их пользователям, когда внутренние службы недоступны. Возможно, процесс заключается в следующем: на серверной части раздела хранения данных будет скрипт для анализа журналов в Nginx, а затем запросит Vanish, Vanish для запроса серверной части, чтобы у Vanish был срок действия, чтобы гарантировать, что данные, хранящиеся в Vanish, являются некоторыми данными, к которым пользователи часто обращаются. Второй шаг заключается в том, как обеспечить возможность перемещения данных при зависании внутренней базы данных. Как можно видеть
Цель деградации
Цель понижения рейтинга относительно проста. Первый заключается в обеспечении того, чтобы сервер был в основном доступен, а второй-в обеспечении доступности основных служб службы. В чем заключается идея понижения в должности? Как правило, каждая стратегия понижения рейтинга нацелена на определенный сценарий и предполагает, какие проблемы необходимо решить в конкретном сценарии; затем определяется, какие основные базовые услуги необходимо сохранить в этом сценарии; наконец, отбираются и систематически внедряются технические решения. Проще говоря, это определить, чего необходимо достичь, затем понять, какова ситуация, и, наконец, разработать стратегии или планы. Например, система вызовет сторонние службы, и сторонние службы могут быть приостановлены, что является типичным сценарием. Например, система сама вызывает службу рекомендаций, но служба рекомендаций повесит трубку. В этом случае невозможно не отображать данные, поскольку нет данных рекомендаций,
3. Сверхурочная работа
Дело о сверхурочных
Сообщество предоставляет интерфейсные услуги внешнему миру, и обратная связь с другой стороны заключается в том, что интерфейсные услуги работают медленно. Интерфейсная часть процесса состоит в том, чтобы найти фрагмент данных, а затем отразить данные в прошлом, проблема в том, что установленный системный тайм-аут слишком велик. Например, вызовите Memcache, но Memcache был приостановлен. Поскольку значение тайм-аута слишком велико, данные должны дождаться окончания тайм-аута перед возвращением, в результате чего интерфейс ждал. Итак, как установить разумное время ожидания? Следует отметить, что время ожидания не является фиксированным значением, но должно быть установлено в соответствии с конкретным сценарием для всего бизнеса.
Как установить тайм-аут
Общая идея заключается в следующем. Первым шагом является определение времени отклика службы, необходимого бизнесу. Например, для ответа на данные требуется 100 миллисекунд, а затем подсчитывается, сколько служб может потребоваться настроить в бизнесе. Второй шаг-подсчитать ежедневное время отклика службы. Третий шаг состоит в том, чтобы различать первичные и вторичные услуги. Поскольку после сбоя основной службы вся ссылка становится недоступной, поэтому время основной службы можно установить более свободно. Если некоторые сервисы не могут быть настроены, но не влияют на всю ссылку, можно установить относительно строгое время.
После установки тайм-аута необходимо убедиться, что порт запечатан аналоговыми средствами (как показано ниже), смоделировать неисправность, а затем проверить, соответствует ли время возврата данных указанному времени.
4. Изоляция
Случаи изоляции
Примерно в следующем году мобильный клиент начал постепенно обновляться, во многих проектах есть как ПК, так и клиент, поэтому одна и та же услуга заключается в предоставлении как ПК, так и интерфейса API для клиента. Как только возникнут крупномасштабные действия или толчок мобильного телефона, служба столкнется с нестабильностью. Нестабильность службы также повлияет на сторону ПК. Поэтому необходимо физически изолировать службу от исходных серверов, соединенных вместе с различными группами компьютеров. Цель изоляции очень проста. Необходимо ограничить риски, вызванные нестабильностью, и прекратить передачу.
Изоляция от
Распространенные формы изоляции включают в себя несколько. Первый-это второй сценарий убийства, который является очень параллельным сценарием, может вызвать больше проблем. В случае второго убийства в сценарии с высокой параллельностью необходимо отличать его от обычного бизнеса. Не рекомендуется, чтобы машина обеспечивала как второе уничтожение, так и обслуживание процесса. Кроме того, данные о точках доступа, такие как данные о продажах, будут создаваться при повторном убийстве. Обновления базы данных происходят часто, а также могут быть изолированы от уровня базы данных, изолируя горячие точки и обычные службы от ресурсов. Второй сценарий-медленная изоляция SQL, изоляция ресурсов. Медленный SQL может привести к нестабильности всей службы. Медленный SQL потребляет текущие потоки каждый раз, когда запрашивается поток, поэтому ресурсы очень дороги. Третий сценарий-изоляция компьютерной комнаты. Как правило, крупные компании будут развертывать несколько комнат, цель состоит в том, чтобы обеспечить стабильность. Не совершайте междугородних звонков для обеспечения стабильности, в противном случае
5. Кластер
Для небольших компаний машина предоставляет услугу, и если машина зависает, восстановление службы становится проблемой. Общее решение состоит в том, чтобы создать кластер, который может предоставлять услуги с одной машины на несколько машин. Цель кластеризации состоит в том, чтобы решить проблему с одной точкой. Основной формой кластера является резервное копирование, то есть только одна машина предоставляет всю службу одновременно, одна или несколько могут предоставлять резервное копирование, резервное копирование включает не только уровень кода, но и ресурсы, на которых работает вся служба. Другая форма-хозяин-раб. Основная цель-предоставить полную услугу, а вторая-предоставить часть услуги. Другой – мульти-мастер, что означает, что принятие решений каждой машиной одинаково, и она будет предоставлять некоторые услуги внешнему миру. При различных формах кластера существуют определенные требования к параллелизму написания кода. Ведущему и ведомому устройству необходимо учитывать только управление параллелизмом одного компьютера, в то время как
Глава Процесса Гарантирования Стратегии
Процесс обеспечения стратегии стабильности разделен на четыре пункта на следующем рисунке: проверка кода, измерение давления, уровень серого и мониторинг.
1.Проверка кода
Цель проверки кода состоит в том, чтобы вовремя обнаружить некоторые проблемы до того, как проект выйдет в Сеть. Люди с большим опытом могут поделиться своим опытом. Проверка кода в основном проходит через три этапа. Первый этап-мозговой штурм. Группа разработчиков проводит проверку кода вокруг кода. Хотя затраты времени высоки, а эффект не идеален, у этого метода также есть преимущества. На ранней стадии мы можем систематизировать наши мнения и сформулировать спецификации для проверки кода. Вторая форма проверки кода-речь. Эксперты заранее просматривают код, разбирают некоторые моменты, а затем делятся ими. Стиль речи может быть основан на системе ротации, что экономит много времени по сравнению со стилем мозгового штурма. В настоящее время распространенная форма проверки кода сопряжена, при этом один или два эксперта объединяются и проверяют друг друга. Он гибок во времени и не требует использования ресурсов конференц-зала.
2. Измерение давления
Манометрические цели
Первая цель измерения давления – обеспечить стабильность системы. В случае высокого параллелизма система обнаружения стабильна, потому что некоторые проблемы не могут быть обнаружены при низком трафике, и только в случае высокого параллелизма эта проблема может быть обнаружена. Второй-проверить сжимающую способность производительности и то, сколько QPS может выдержать система.
Проблемы измерения давления
Во-первых, машина для измерения давления и служба измерения давления находятся в одном сегменте сети, чтобы избежать неточных результатов измерения давления по сетевым причинам. Второй момент заключается в том, чтобы обратить внимание на нагрузку на сервер, обратите внимание, чтобы не нажимать на сервер на 100%, когда сервер вот-вот рухнет, полученное значение не является значительным. Это должно быть, когда загрузка сервера достигнет 60% -70%, посмотрите, сколько QPS. Кроме того, одновременные пьезометрические данные-это постепенный инкрементный процесс, в какой-то степени, чем больше одновременных данных, тем ниже QPS. Наконец, несущая способность линии оценивается в соответствии с результатами измерения давления в испытательной среде. Расчетная формула-это QPS только в режиме онлайн. Количество машин 0,7. Последнее умножается на коэффициент (0,7), потому что при ставке на линию всегда есть некоторый убыток.
Манометрия полного звена
Однако некоторые тесты не могут обеспечить измерение давления в тестовой среде, поэтому теперь оно превратилось в полнофункциональное измерение давления. Манометрию полного звена можно разделить на три основные задачи. Первый – это построение модели данных. Полноканальная манометрия-это реальная модель данных на аналоговой линии, такая как количество посетителей страниц с подробностями, количество размещенных заказов, доля людей, количество посадочных мест и так далее. Мы пытаемся смоделировать реальные данные и построить имитационную модель, чтобы действительно найти некоторые проблемы на линии. Обратите внимание, что полноканальная манометрия реализована не в тестовой среде, а в режиме онлайн-манометрии. Второе – это создание инструментов для измерения давления. С помощью инструментов измерения давления с открытым исходным кодом все они создали платформу для измерения давления, чтобы увеличить поток в соответствии с моделью данных. Третий момент-изоляция трафика. Увеличьте идентификацию трафика, чтобы гарантировать, что данные в режиме онлайн не будут затронуты, и поместите полную-
3. Уровень Серого
Цель серого уровня – пробовать и ошибаться в небольшом диапазоне и пытаться найти проблемы. Существует несколько стратегий серой шкалы. Первая стратегия состоит в том, чтобы позволить людям в определенной области сначала получить доступ к новейшим функциям. Если они столкнутся с проблемами, пользователи своевременно предоставят обратную связь, и проблемы будут затрагивать только определенные области. Другая стратегия основана на атрибутах пользователей, таких как система рекомендаций, которая может различать старых и новых пользователей при поступлении запросов. Он может рекомендовать различные стратегии новым и старым пользователям, чтобы проверить точность и эффективность стратегии. Третья стратегия заключается в выборе нескольких пользователей из группы пользователей для обработки на основе данных. Например, в цепочке поставок поставщик обрабатывает данные, но, как правило, не гарантирует, что 100% кода будет в режиме онлайн после возникновения проблемы. На этом этапе выберите поставщика для обработки, проверьте данные, убедитесь, что никаких проблем нет, а затем обратитесь ко всем поставщикам в полном объеме. Наконец, он основан на платформе, которая
4. Мониторинг
Мониторинг Точек Внимания
Цель мониторинга-автоматическое и своевременное выявление проблем. При мониторинге необходимо обратить внимание на несколько вопросов. Во-первых, необходимо осуществлять мониторинг всех аспектов мониторинга, систем и услуг. Второе-это классификация аварийных сигналов, и установка коэффициента контроля и сигнализации должна быть разумной. Последний пункт заключается в сборе данных в реальной среде. Например, серверы A и B отслеживают только серверы B. Если сервер A в моей сети баз данных SQL имеет проблемы, поскольку сервер B нормально работает при мониторинге, мониторинг не вызовет тревоги. Поэтому необходимо следить за сервером приложений, чтобы предупредить конкретную машину о сбое в обслуживании и другой информации.
Система Мониторинга Самостоятельных Исследований
На следующем рисунке показана система мониторинга самоисследований Али. Во-первых, определите, какие показатели следует отслеживать. Нарисуйте данные всего индекса и посмотрите на колебания данных индекса. Как только вы столкнетесь с проблемами, вы сможете легко их сравнить. Кроме того, нам необходимо определить влияние и обобщить все соответствующие показатели. Например, система управления командой поставщика часто производит картонную упаковку для складских операций. Есть много факторов, которые могут привести к карикатуре. Например, терминал ПК медленно вызывает другие интерфейсы, и нагрузка на сервер выше. Персонал склада не может обращать внимание на конкретные детали, они находятся в интерфейсе воздействия, чтобы увидеть влияние показателей, можно увидеть, какие показатели не квалифицированы, вызванные Катоном. Впоследствии, влияние соответствующего лечения, текущее общее поведение эффективной сигнализации или короткого сообщения тревоги.
Прочитайте исходный текст
Эта статья является оригинальным контентом сообщества Юньци, который не может быть воспроизведен без разрешения.