Всем известно, что хоть я и программист, но очень увлекаюсь спортом, например танцами.Не каждый день перед тем, как пойти домой и лечь спать, я буду разучивать родственные танцы в танцевальной зоне станции Б.
Вчера не было исключением.Как только я закончила стирку, я побежала и села перед компьютером.Я открыла танцевальную зону станции Б и приготовилась учиться кусать мяу. .
Как раз когда я собирался выучить следующий ход, я узнал, почему я не нашел 404.
Он сломан. Как разработчик, я первым делом почувствовал, что система дала сбой. Я даже подозревал, что это проблема с моей сетью. Я обнаружил, что сеть мобильного телефона работает нормально, а компьютер нормально обращается к другим веб-страницам.
Несколько раз перепрошивал и обнаружил, что все так же.Немного сочувствовал соответствующим ответственным одноклассникам, а к концу года их уже должно не быть. (Сайт не был восстановлен к тому времени, когда я это пишу)
Я, как бывший программист, привычно задумываюсь над составом структуры сайта станции Б и моментами, которые могут пойти не так после просмотра этой аварии. (Старое занятие используется)
Прежде всего, мы можем примерно нарисовать простую архитектурную схему веб-сайта, а затем догадаться, в чем может быть проблема.
Поскольку я не спал всю ночь, чтобы писать статьи, я никогда не оставался в компании, которая в основном полагается на живое видео, и я не очень хорошо знаю стек технологий, поэтому я нарисовал эскиз, используя общую логику электронной коммерции, и все постучали по нему.
Сверху вниз, от входа до раздачи контента cdn, до front-end сервера, back-end сервера, распределенного хранилища, анализа больших данных, контроля рисков до рекомендаций поисковых систем, я просто нарисовал это вскользь, я думаю, что общая архитектура не должна отличаться Экстра большой.
Я зашел в Интернет и проверил некоторые компании, такие как Douyu, Station B, Station A. Основные технологические стеки и технические трудности:
Хранилище доступа к видео
- поток
- Ближайший узел
- Видео кодек
- Возобновление с точки останова (аналогично написанному нами примеру ввода-вывода)
- Изоляция системы базы данных и файловой системы
одновременный доступ
- Сервер потокового мультимедиа (есть у всех крупных производителей, стоимость полосы пропускания высока)
- Кластер данных, распределенное хранилище, кеш
- Распространение контента CDN
- балансировки нагрузки
- Поисковая система (разделенная)
система заграждений
- параллелизм, поток
- kafka
- nio-фреймворк (netty)
На самом деле это похоже на технологию, которую мы все изучаем, но языковой состав соответствующих микросервисов может составлять большую часть go, php, vue и node.
Разберем возможные причины и места этой аварии:
1.Удалить библиотеку и убежать
Это случалось с Weimeng раньше.Я не думаю, что компании должны давать такие большие полномочия на эксплуатацию и обслуживание.Например, полномочия хоста прямо запрещают такие команды, как rm-rf, fdisk и drop.
Тем более, что БД сейчас в основном multi-master и multi-slave, и ее бэкапится во многих местах.Аварийное восстановление тоже должно быть хорошо сделано.Причем, если БД только взорвана, много статических ресурсов CDN не должно быть загружена.Страница сразу 404.
2.Один микросервис зависает и тормозит большой кластер
Теперь фронтенд и бэкенд разделены.Если виснет бэкенд, то многое на фронтенде еще может грузиться, но данные не могут выйти и сообщается об ошибке.Поэтому если кластер собирается виснуть, может быть что фронтенд виснет, или фронтенд и бекенд вместе висят, но это все равно проблема, сейчас вроде бы все статические ресурсы недоступны.
Тем не менее, я думаю, что вероятность этого есть, потому что некоторые сервисы не работают, в результате чего возникает большое количество ошибок и подтягивание кластера, и чем больше этого происходит, тем больше людей будут постоянно обновлять страницу, что усложняет ее. для перезапуска других служб, но это не то, о чем я сказал в конце, весьма вероятно.
3.У производителя сервера есть проблема
Такой большой веб-сайт представляет собой кластер станций cdn+slb+, все виды ограничения тока и понижения, и балансировка нагрузки могут быть выполнены хорошо, и они не преминут сделать аварийное восстановление.
Поэтому возможна только проблема с производителями серверов этих front-end сервисов, если CDN зависнет, нагрузка на балансировку нагрузки шлюза будет велика, и в итоге цепной лавинный эффект повесит всю систему .
Но меня больше озадачивает то, что BFF станции B должен быть направлен в какие-то компьютерные комнаты, где узлы доступа более доступны, поэтому, когда друзья со всей страны трутся, некоторые люди хорошие, некоторые люди плохие, а некоторые люди хорошие и плохо.Да,но вроде сейчас совсем сломался.Делали ставку на узловую площадь производителя?
Вижу что горит датацентр облачного моря тоже.Не знаю правда это или нет.Могу только ждать пока проснусь и увижу официальное объявление станции Б.В принципе станция Б теоретически основана на CDN, распределенное хранилище, большие данные и поисковые системы — они должны были принять множество гарантийных мер, и было бы неразумно собрать все в одном месте.
Я чувствую, что я не сделал все развертывания в облаке.Есть проблема с автономными серверами.Просто так получилось, что ключевой бизнес находится не в облаке.Сейчас компания использует гибридное облако, такое как публичное облако + частное облако , но часть частного облака Это все внутреннее дело Билибили, так что в его собственном компьютерном зале не должно быть никаких проблем.
Если все так, как я сказал, я ставлю на производителя сервера, но ничего страшного, если есть проблема с CDN. Если на физической машине все еще есть проблемы, восстановление данных может быть медленным. Раньше я сам делал большие данные, и Я знаю, что резервное копирование данных - это все Инкрементальный + полный объем, это действительно хорошо, когда он восстанавливается, а часть можно вытащить с нод в других регионах, но если разместить в одном месте, то это будет хлопотно.
Обзор
Я думаю, что независимо от того, какова конечная причина, мы, технические специалисты и компании, должны думать о том, как этого избежать.
резервное копирование данных:Бэкапы надо делать, иначе в случае стихийного бедствия будет очень неудобно, поэтому многие облачные вендоры сейчас выбирают места вроде моего родного города в Гуйчжоу, где стихийные бедствия случаются реже, или на дне озер и морских стоимость кулера может значительно снизиться).
Полные и добавочные данные в основном всегда выполняются.Непрерывное добавочное данные в течение дней, недель и месяцев, а также своевременное резервное копирование полных данных могут значительно снизить потери, даже если механические диски во всех регионах сломаны ( Аварийное восстановление в можно восстановить разные места, кроме разрушения земли).
Схождение разрешений на эксплуатацию и обслуживание, или боязнь удалить библиотеку и убежать, так или иначе, я часто rm-rf на сервере, но вообще, те, у кого есть трамплин для входа, могут быть забанены командой.
Облако + собственное облако:Различные возможности облачных продуктов сейчас очень развиты.Предприятия должны иметь достаточное доверие к соответствующим облачным поставщикам.Конечно, они должны выбирать правильных.Различные возможности облачных продуктов являются одними из них, а также аварийное восстановление и аварийное восстановление реагирование в критические моменты Механизмы реагирования недоступны во многих компаниях.
Cloud Native — это технология, на которую все обратили внимание лишь в последние годы.Некоторые комбинации docker+k8s, плюс различные возможности облачных вычислений, действительно могут быть без присмотра, динамически сжиматься и расширяться, и упомянутое выше аварийное реагирование. сама по себе требует некоторых пробных затрат, и я не знаю, подходит ли система на основе видео, такая как станция B.
При разработке kubernetes также возникают некоторые проблемы с оркестровкой и коммуникацией.
Создайте свою собственную силу:На самом деле, я думаю, независимо от того, собираетесь ли вы переходить в облако или нет, вы не можете слишком полагаться на многих поставщиков облачных услуг.Вы все равно должны иметь свою собственную базовую технологическую систему и аварийный механизм.Что, если поставщики облачных услуг действительно ненадежны? О том, как добиться реальной высокой доступности, должны подумать технические специалисты предприятия.
Например, многие поставщики облачных услуг продают одну физическую машину, разделенную на несколько виртуальных машин, а затем будет одна физическая машина с несколькими хостами.Занимая пропускную способность сети, вы можете потерять пакеты, что крайне плохо для пользователей игр. Вот почему я говорю, почему бы не слишком доверять поставщикам облачных услуг и полагаться на них.
Если другая сторона купит его для моего, это будет еще более избыточно, истощая вычислительную мощность, а работа с полной нагрузкой будет еще более неудобной.
В этот раз на станции Б, к счастью, такая проблема была обнаружена заранее, и это было ночью, поэтому времени на восстановление должно быть много, когда трафик был низким.Когда я писал это, большинство веб-страниц были восстановлены, но я обнаружил, что они все еще частично восстановлены.
В любом случае, в следующий раз его можно полностью исключить, я думаю, что станция Б еще долго будет занята трансформацией архитектурной системы, чтобы обеспечить ее истинную высокую доступность.
Надеюсь, что в будущем я смогу стабильно смотреть танцевальную зону ночью, вместо того, чтобы пялиться на 2233 мать 502 и 404 в оцепенении, хи хи