Больше отличных статей.
«Микросервисы — это не все, а лишь подмножество определенного домена».
С таким количеством компонентов мониторинга всегда найдется подходящий для вас
«С Нетти, что мы разрабатываем? 》
«Вероятно, это наиболее подходящая спецификация Redis».
«Портрет программиста, десять лет взлетов и падений»
Самая полезная серия:
«Наиболее часто используемый набор навыков «vim» в производственной среде Linux.
«Наиболее часто используемый набор навыков «Sed» в производственной среде Linux.
«Наиболее часто используемый набор навыков «AWK» в производственной среде Linux.
Как мы все знаем, системы с высокой степенью параллелизма имеют три оси:缓存,熔断и限流. Но есть и другой топор, часто забытый в углу, несчастный, т.预热.
Пример явления
Позвольте мне сначала поговорить о двух явлениях. Эти явления могут проявляться только в системах с высокой степенью параллелизма.
Ну, это вызвало несколько сбоев.
1. После перезагрузки БД мгновенно умирает
БД в среде с высокой степенью параллелизма перезапускается после остановки процесса. Из-за пикового периода бизнеса перераспределяется стратегия балансировки нагрузки восходящего потока. Только что запущенная БД получала 1/3 трафика в одно мгновение, а потом нагрузка взлетела до полного отсутствия ответа.
Причина: недавно запущенная БД, различные кэши не готовы, а состояние системы совсем не похоже на нормальную работу. Может быть, 1/10 от обычного количества может привести к смерти.
2. После перезапуска службы доступ ненормальный
Другая распространенная проблема: у меня проблема с одним из моих серверов, и из-за балансировки нагрузки остальные машины сразу же выполняют эти запросы и работают нормально. При повторном присоединении сервиса к кластеру возникало большое количество трудоемких запросов, а в случае большого объема запросов возникало даже большое количество сбоев.
Причина, вероятно, может быть связана с:
1. После запуска сервиса jvm не до конца подготовлен, JIT не скомпилирован и т.д.
2. Различные ресурсы, используемые приложением, не готовы.
3. Балансировка нагрузки перебалансирована.
Эти две проблемы недостаточно хорошо разогреты
Warm Up, то есть способ холодного пуска/прогрева. Когда система находится на низком уровне воды в течение длительного времени, когда поток внезапно увеличивается, прямое подтягивание системы к высокому уровню воды может мгновенно привести к перегрузке системы. Благодаря «холодному запуску» проходящий поток медленно увеличивается и постепенно увеличивается до верхнего предела порога в течение определенного периода времени, давая холодной системе время прогрева, чтобы избежать перегрузки холодной системы.
Я хочу такую кривую.
Правда сложнее
Трафик непредсказуем, в отличие от естественно растущего трафика или искусственных атак.Это процесс с нуля. Даже некоторые самопровозглашенные сверхбыстрые компоненты, такие как дисраптор lmax, рухнут от этого внезапного наводнения.
Наиболее подходящим начальным уровнем для разминки является шлюз. Как показано на рисунке:node4Это нода, которая только что была запущена.Компонент балансировки нагрузки, интегрированный в шлюз, сможет идентифицировать инстанс, который только что присоединился, а затем постепенно увеличивать объем до этой машины до тех пор, пока она действительно не сможет выдерживать высокоскоростной трафик.
1. Ваше приложение напрямую получает информацию из реестра, а затем распределяет трафик в клиентском компоненте.
2. Ваше приложение проходит некоторые сложные правила промежуточного программного обеспечения и маршрутизации и, наконец, размещается в определенной БД.
3. Ваш терминал может быть напрямую подключен к серверу MQTT по протоколу MQTT.
Давайте сделаем небольшую абстракцию, и мы увидим: Всю эту логику распределения трафика, включая шлюзы, можно назвать客户端. То есть вся логика прогрева помещается в客户端Да, все они тесно связаны с балансировкой нагрузки.
Решение
Громкость интерфейса
Согласно приведенному выше анализу, контролируйте все客户端Звонок для решения проблемы.
Простой метод опроса
1. Я хочу иметь возможность получить набор всех вызываемых ресурсов, а также время запуска, конфигурацию холодного запуска и т.д.
2. Назначьте этим ресурсам некоторые веса, например, максимальный вес равен 100, а холодный запуск будет успешным после 100 секунд настройки. Если это 15-я секунда, общий вес равен 100*(n-1)+15.
3. В соответствии с рассчитанным весом будет осуществляться распределение, и трафик будет постепенно увеличиваться по прошествии времени, пока не сравняется с другими узлами.
4. В крайнем случае у меня всего один экземпляр моего бекенда, и его вообще нельзя запустить.
В случае со SpringCloud нам нужно изменить поведение этих компонентов.
1. Стратегия балансировки нагрузки ленты.
2. Стратегия балансировки нагрузки шлюза.
К счастью, все они являются базовыми компонентами, поэтому нет необходимости копировать код туда и обратно.
Смотреть цветы верхом на лошади
Как следует из названия, это означает, что доступ ко всем интерфейсам осуществляется заранее, чтобы система могла заранее подготовить ресурсы. Например, перебрать все http-соединения и отправить запрос. Этот метод частично эффективен, на этом этапе будут загружены некоторые отложенные ресурсы, но не все. Некоторые усовершенствования, такие как JIT, могут сделать процесс прогрева очень долгим, а способ наблюдения за цветами может работать только до определенной степени.
Другим примером является то, что некоторые БД после запуска будут выполнять некоторые очень специальные有特点sql, так что самые необходимые горячие данные загружаются в PageCache.
сохранение состояния
Система делает снимок при выходе из строя, а затем восстанавливает его неповрежденным при запуске.
Этот процесс более волшебный, потому что при общем аварийном завершении работы система не имеет возможности произнести последние слова, поэтому она может только регулярно делать снимки в работающей системе.
При запуске узла снимок загружается в память. Это широко используется в некоторых компонентах на основе памяти.
End
Путем сравнения мы обнаружили, что самый надежный способ — закодировать и интегрировать логику прогрева в客户端. Работа может быть мучительной и долгой, но конец счастливый.
Конечно, вы также можете использовать метод «удалить nginx-> изменить вес-> перезагрузить nginx». Иногда эффективно, но не всегда, обычно обнадеживает, но не всегда обнадеживает.
Все зависит от вас. Ведь нет никакой прелюдии, чтобы перейти сразу к теме, что безрассудно.
Больше отличных статей.
«Микросервисы — это не все, а лишь подмножество определенного домена».
С таким количеством компонентов мониторинга всегда найдется подходящий для вас
«Наиболее часто используемый набор навыков «vim» в производственной среде Linux.
«С Нетти, что мы разрабатываем? 》
Линукс из пяти частей и тому подобное.
«Остальная часть необитаемого острова» Linux (1) Подготовка»
«Linux« Остальная часть необитаемого острова »(2) Глава CPU»
«Linux« Остальная часть необитаемого острова »(3) глава памяти»
«Linux« Остальная часть необитаемого острова »(4) глава ввода-вывода»
«Сетевая глава Linux« Оставшаяся жизнь на необитаемом острове »(5)»