Не есть дыню, анализ всего инцидента на станции B + обмен технологиями предотвращения и контроля
Привет всем, я Юпи, я думаю, что многие из моих друзей слышали о вчерашнем обрушении станции Сяопо.
Если бы это было отложено раньше, я бы не обращал внимания на такого рода вещи, если бы я не любил есть дыни.Если бы он рухнул, он бы рухнул.В любом случае, когда небо падает, есть программисты, которые его несут , и скоро станет лучше.
Но в этот раз все по-другому, потому что я сам стал частью этого события."потерпевший"!
Итак, сегодня, с точки зрения программиста, я верну вас к началу и концу краха Станции Б, рационально порассужу о причинах и поделюсь некоторыми методами предотвращения и инсайтами.
событие
Станция B только что рухнула, но до того, как она полностью рухнула, я писал небольшой код в комнате прямой трансляции и дружески переписывался с друзьями. Поскольку я не часто наблюдаю за экраном маркеров, когда пишу код, я не заметил, что экран маркеров не двигался, и ни один из мелких партнеров не отправил экран маркеров.
Сначала я думал, что будет скучно просто писать код самому и никому до меня нет дела. Потом положил куда-то и пробормотал себе под нос: Странно, а почему мои друзья не выложили скрины пули? привет, кто-нибудь? Привет? Привет? Сумасшедший, чем восемь шагов?
Только позже я узнал, что в зоне заграждения даже не было приглашения войти в комнату, нельзя же, чтобы никто не заходил несколько минут, верно? Должно быть, что-то случилось!
Я подумал, что это карточка заграждения, поэтому закрыл заграждение и снова открыл, но результат был тот же. Потом подумал перезапустить прямую трансляцию, но после того, как выключил, открыть снова не смог.Скрин прямо подсказал: Похоже, связь с сервером разорвана.
Честно говоря, до этого я никогда не думал, что платформа с миллиардным трафиком, такая как Station B, рухнет. Поэтому первая реакция такая же, как и у всех: все подозревали, что проблема в их собственной сети, оказалось, что страница открывается, но сеть не подключается. Вот я вдруг подумал и испугался: держитесь за траву? Станция Б даже заблокировала меня? (Старый разыскиваемый преступник)
Вот и все, я был пострадавшим на месте аварии, тот, кто упал на землю и был оглушен, так что только через десять минут после аварии я узнал другими способами, о, это оказалась авария на станции Б.
Хоть я и пропустил первую сцену, но общий процесс развала станции Б я тоже могу понять по горячим поискам.пару часовПользователи не могут получить доступ ни к одной функции станции B в обычном режиме!
Открытая станция B, первый ресурс 404 Not Found не найден:
Затем 502 Bad Gateway:
Через час некоторые друзья сказали, что некоторые функции станции B уже доступны, но полностью не восстановлены, и только ранним утром 14 числа официальная станция B, наконец, отреагировала и вернулась к нормальной работе.
Угадывание причины
Я вырезал видео прошлой ночью до 2 часов ночи. Я хотел сразу лечь спать, но я снова открыл Zhihu и обнаружил, что «станция B рухнула» — это самый популярный вопрос 1. Я нажал из любопытства, чтобы найти что стояло за аварией.Настоящая причина, см. все мнения.
Изначально я был посторонним, не работал на станции Б и не имел глубокого понимания ее технической архитектуры, а вкупе с отсутствием ключевой информации и достоверных предположений я не был готов высказать свое мнение. Выяснилось, что несколько программистов в первом ряду размышляли о причине аварии с технической точки зрения, и все они были небольшими ответами, чтобы помочь всем ароматнее есть дыни. Тогда я мог бы также высказать волну предположений, основанных на архитектурных знаниях, которые я получил в прошлом, и я буду приятно удивлен, если их подтолкнут.
Фактически, через 20 лет г-н Мао Цзянь, технический директор станции B, поделился лекцией «Практика архитектуры высокой доступности станции B» в сообществе Tencent Cloud +.
Поэтому перед этим анализом я еще раз прочитал статью «Практика архитектуры высокой доступности на станции Б» Интересно, что всего за полдня количество прочтений этой статьи увеличилось на 150 000!
И что еще интереснее, под статьей много "сарказма", какой "восьминогий архитектор" и тому подобное:
Но я не думаю, что это необходимо, потому что технология, которой поделился г-н Мао Цзянь, действительно является очень практичным решением высокой доступности, но ей все еще не хватает подтверждения.
Адрес статьи:cloud.Tencent.com/developer/ ах…
Ниже мои предположения.
Предположение 1: шлюз не работает
Во-первых, когда произошла авария на этой небольшой разбитой станции, другие станции тоже рухнули! Например, Станция А, Цзиньцзян и Дубань находятся в горячем поиске.
Одновременное возникновение этих инцидентов указывает на то, что существует проблема с государственными службами, от которых зависят эти системы, и единственное, что может вызвать крупномасштабный отказ службы, — этоCDN.
CDN — это сеть распространения контента.Контент сайта-источника заранее отправляется на серверные узлы в различных регионах, а затем пользователи в разных регионах могут получать контент поблизости, а не весь контент с сайта-источника, тем самым играя роль ускорения контента и балансировки нагрузки.
Как только CDN выйдет из строя, весь трафик пользователей в этой области будет направлен на шлюз:
Шлюз подобен боссу семьи.Если у пользователя есть потребность, он сообщит об этом боссу, а затем босс раздаст потребности младшим братьям для выполнения.
Кроме того, шлюз обычно берет на себя миссию защиты сервисных братьев, унификации балансировки нагрузки, управления трафиком, предохранения и понижения версии и т. д.
Логически говоря, шлюз обычно должен защищать не только нижестоящие сервисы, но и сам себя. Но почему шлюз не защищает себя?
Моя догадка такова: шлюз еще не пришел и не открыл меры защиты (самопрошивка даунгрейда и т.д.), его моментально разнесло трафиком.
Как только зависает шлюз, у сервиса нет отца, а у сервиса отсутствует запись вызова, поэтому он естественно недоступен.Не все сервисы за шлюзом находятся в парализованном состоянии.
Угадай 2: сервисная лавина
Также есть предположение, что в системе станции Б много сервисов.цепочка вызовов. Из-за отказа CDN или некоторых машин увеличивается время выполнения нижестоящего сервиса А, что приводит к увеличению времени выполнения сервиса Б, вызывающего вышестоящий сервис А, что делает вычислительную мощность системы на единица времени хуже. В сочетании с непрерывным отставанием запросов вверх по течению вся цепочка вызовов в конечном итоге лавинообразна, и все службы в цепочке от сыновей к отцам полностью уничтожаются.
Типичный пример - унитаз дома засорился, а ведро не наполнено, а по нему еще "доставляется". В итоге "доставить" уже нельзя, и унитаз лопнул!
официальное объяснение
После того, как официальное объяснение состояло в том, что серверная комната вышла из строя, я прочитал анализ других учителей и почувствовал, что официальное объяснение осталось в прошлом.
Действительно, станция B почти не упомянула об этом, когда делилась архитектурой высокой доступности с внешним миром.готовность к стихийным бедствиямижить болееС точки зрения дизайна, больше обработки выполняется на локальном уровне обслуживания и уровне приложений, например, ограничение тока, понижение версии, объединение, повторная попытка, обработка тайм-аута и т. д. Следовательно, при проектировании крупномасштабных распределенных систем необходимо рассматривать более всесторонне. Я думал, что это кольцо~
Пока статья не была опубликована, респонденты Zhihu Top 1 тщательно разбирали подсказки:
Почему двое других быстро восстановились, а станции Б потребовалось несколько часов, чтобы вернуться в нормальное состояние?
Я чувствую, что это как-то связано с самостоятельно разработанными компонентами станции B. С одной стороны, на него влияет поставщик облачных услуг, что приводит к зависанию нижестоящей цепочки услуг.Большая площадь разломаС другой стороны, перезапуск также требует времени, и во время процесса перезапуска балансировка нагрузки восходящего потока может не выдержать пиков трафика, поэтому, если вы хотите вернуться к нормальным уровням, вы должны как минимум дождаться перезапуска многих реплик контейнера. полностью.
Кроме того, вчера около 23:30, когда я открыл станцию B, я увидел старые данные за несколько часов назад, указывающие на то, что в это время станция B перезапустила некоторые сервисные копии и начала меры по понижению версии, но не сделала этого. не запрашивать реальные данные.
Я не ожидал, что этот мой собственный ответ все еще будет популярен на Zhihu, и он стал первыммиллион просмотровсомнительныйTop 2, польщенный, польщенный. . .
Спасение жизни: вышеизложенное само по себе является моим предположением, ха-ха, степень профессионализма ограничена, каждый может обсудить в области комментариев, слегка распылить.
Технология профилактики и контроля
Кратко поговорим о технологии предотвращения и контроля отказа сервиса, то есть о том, как обеспечить высокую доступность сервиса, и постараться продолжать предоставлять услуги пользователям без простоев.
Я просто классифицировал изученные технологии в виде ментальной карты:
Пока так много думал, конечно, есть и другие технологии.
Время ограничено, поэтому не будем сначала говорить об этих технологиях. Что касается того, как уменьшить количество ошибок в системе и обеспечить высокую доступность сервисов, добро пожаловать в мои исторические статьи:Демистификация дамоклова меча в разработке программного обеспечения, многие из вышеперечисленных методов также объясняются.
Получить представление
Относительно этого несчастного случая, как одного из пострадавших, у меня тоже есть некоторые приобретения и озарения, а не поедание дыни и поедание одиночества.
Во-первых, иметьвопрошающий дух, Когда возникает проблема в написании программы, мы обычно без проблем находим причину у себя, но после того, как мы не находим ошибку, мы должны смело предположить, что это библиотека классов, компонент или зависимый сервис, который мы используем, или даже возможно. Виноват редактор, а не предположение, что что-то общеизвестное должно быть правильным. После того, как у станции Сяопо возникла проблема, я действительно подозревал, что моя прямая трансляция была заблокирована, ха-ха, я почти хотел найти руководство, чтобы встать на колени.
В программировании мы не можем просто запоминать знания, слушать других, делатьБагувен Архитектор; Но быть инженером с богатым практическим опытом, не слепо верить или принимать на веру, а накапливать опыт на практике и оптимизировать систему под реальную ситуацию.
Благодаря этому анализу в сочетании с фактическим процессом отказа я также повторил знания об архитектуре, которые я получил ранее, и получил более глубокое понимание некоторых проектов высокой доступности. Однажды постарайся не допуститьпрограммирование навигации(Woohoo.code-это В. может)Станьте следующей станцией B (собачья голова).
Также, как упоминалось выше, необходимо всегда быть готовым к опасности и выработать в себе полезную привычку защитного программирования, а не устранять проблемы по мере их возникновения. Для такой известной платформы, как Station B, при возникновении небольшой проблемы потери для пользователей и предприятий неисчислимы.
Спасибо папе станции B за однодневную членскую компенсацию ❤️
Наконец, отправить вам некоторыеПомогите мне получить учебные материалы, предлагаемые Dachang:
Как я начал с нуля и получил предложения от крупных компаний, таких как Tencent и Bytes, путем самообучения Вы можете прочитать эту статью и больше не путаться!
Я изучаю компьютер уже четыре года, давайте друг друга подбадривать!
Я рыбья кожа,какЭто все еще просьба, и я желаю, чтобы каждый мог осуществить свою мечту, разбогатеть и иметь большую удачу.