В этой статье будет представлен план доступности системы на 4 девятки (99,99%) в течение года.
При высокой надежности системы существует стандарт измерения ее надежности - X 9, этот X представляет собой число 3~5. X 9s обозначают отношение времени нормального использования системы к общему времени (1 год) при использовании системы в течение 1 года.
Формула расчета доступности системы: A=MTBF/(MTBF+MTTR)
Возьмите 365 дней (1 год) в качестве расчета и посмотрите, сколько времени потребуется, чтобы остановить несколько девяток, чтобы достичь этого!
1 год = 365 дней = 8760 часов
99,9 = 8760 * 0,1% = 8760 * 0,001 = 8,76 часа
99,99 = 8760 * 0,0001 = 0,876 часа = 0,876 * 60 = 52,6 минуты
99,999 = 8760 * 0,00001 = 0,0876 часа = 0,0876 * 60 = 5,26 минуты
Технические моменты дизайна этой статьи:
- LVS
- keepalived
- nginx
- Высокая доступность кластера
- Spring Cloud Nacos (аналогично другим сервисным реестрам)
- Spring Cloud Gateway (то же самое для других шлюзов API)
- весенняя загрузка (то же самое для приложений, отличных от Java)
LVS && Keepalived (понять)
Что такое LVS?
LVS этоLinux Virtual Server(Linux Virtual Server) для краткости. В настоящее время LVS уже является частью стандарта ядра Linux. LVS работает на сетевом уровне 4 только для распространения, поэтому он обладает относительно сильными антизагрузочными возможностями. LVS имеет полное двухсистемное решение для горячего резервного копирования, которое поддерживает балансировку нагрузки почти для всех приложений. Позиция LVS в интернет-приложениях выше, чем у Nginx.
Как применяется LVS?
LVS сама по себе являетсяIP_VSЭтот модуль может делать балансировку нагрузки, но этого недостаточно, чтобы использовать этот модуль для загрузки приложений.Например, как быть с самим LVS, когда он выходит из строя? В реальной производственной среде общее сотрудничествоKeepalivedиспользовать ЛВС,keepalivedслужба поддержкиVRRPПротокол пульса может реализовать избыточность главного и резервного LVS для устранения единой точки отказа самого LVS. Кроме того, Keepalived поддерживает проверку работоспособности, проверку работоспособности сетевого уровня 4 и 7 для предотвращения простоя сервера.
Как работает поддержка активности
Будучи высокопроизводительным кластерным программным обеспечением, Keepalived также может отслеживать рабочее состояние серверов в кластере и изолировать сбои.Давайте представим, как Keepalived работает с рабочим состоянием сервера и локализацией сбоев.
Keepalived работает на трех уровнях (сетевой уровень), четырех уровнях (транспортный уровень) и семи уровнях (прикладной уровень) модели TCP/IP. Механизм работы Keepalived выглядит следующим образом:
-
На сетевом уровне (3): мы знаем, что в работе находятся 4 важных протокола. Интернет-IP-протокол, Интернет-управляемый пакетный протокол ICMP, протокол преобразования адресов ARP, протокол обратного преобразования адресов RARP, Keepalived Наиболее распространенным способом работы на сетевом уровне является отправка сообщения каждому узлу в кластере серверов по протоколу ICMP. пакеты (несколько похоже на функцию Ping), если узел не возвращает ответный пакет, то узел считается неисправным, Keepalived сообщит об отказе узла и удалит неисправный узел из кластера серверов.
-
На транспортном уровне (4): Предусмотрены два основных протокола: Протокол управления передачей TCP и Протокол данных пользователя UDP.Протокол управления передачей TCP может предоставлять надежные услуги вывода данных, IP-адреса и порты, представляющие конец соединения TCP, что требует для получения услуг TCP необходимо установить соединение между портом отправителя и портом получателя, а Keepalived использует соединение портов и технологию сканирования протокола TCP на транспортном уровне, чтобы определить, является ли порт узла кластера нормальный, например, для общего порта веб-сервера 80. Или сервисный порт SSH 22. Как только Keepalived обнаруживает, что эти номера портов не имеют ответа данных и возврата данных на транспортном уровне, он считает эти порты ненормальными, а затем принудительно удаляет узлы, соответствующие этим портам, из кластера серверов.
-
На прикладном уровне (7): он может запускать различные типы высокоуровневых протоколов, таких как FTP, TELNET, SMTP, DNS и т. д. Режим работы Keepalived также более полный и сложный.. Пользователи могут настраивать способ работы Keepalived, например: через Написать программу или скрипт для запуска Keepalived, и Keepalived проверит, разрешено ли работать различным программам или службам в соответствии с заданными пользователем параметрами.Если результат теста Keepalived не соответствует настройке пользователя, Keepalived удалит соответствующий сервер из кластера серверов.
Что такое ВРРП?
VRRPДва или более физических маршрутизатора могут быть виртуализированы в一个虚拟路由, этот виртуальный маршрутизатор проходит черезВиртуальный IP (один или несколько) для предоставления внешних услугВ виртуальном маршрутизаторе более десяти физических маршрутизаторов работают вместе, и только один физический маршрутизатор одновременно предоставляет услуги внешнему миру.Это физическое устройство маршрутизации называется главным маршрутизатором (роль главного).Как правило, главный создается алгоритм выбора.Он имеет виртуальный IP-адрес для внешних служб и обеспечивает различные сетевые функции, такие как: запрос ARP, пересылка данных ICMP и т. д., а другие физические маршрутизаторы не имеют внешних виртуальных IP-адресов и не предоставляют внешних сетевых функций. .Получайте информацию о состоянии VRRP только от MASTER., эти маршрутизаторы вместе называютсяBACKUPроль", когда основной маршрутизатор выходит из строя, вBACKUPРезервный маршрутизатор роли будет переизбран, в результате чего новый основной маршрутизатор войдет в роль.MASTERроль, продолжать предоставлять внешние услуги, и весь коммутатор полностью прозрачен для пользователей.
Высокая доступность уровня доступа Lvs+Keepalived+nginx (ключ)
Исторический обзор архитектуры эволюции технологий уровня доступа к трафику
Автономная архитектура
- Браузер разрешает доменное имя в ip через DNS-сервер
- Браузерный доступ к веб-серверу через ip
недостаток:
- Невысокая доступность, веб-сервер вешает всю систему и зависает
- Плохая масштабируемость, когда пропускная способность достигает верхнего предела веб-сервера, емкость не может быть расширена
Примечание. Один компьютер не требует балансировки нагрузки.
Простой план расширения и опрос DNS
Предполагая, что пропускная способность tomcat составляет 1 Вт раз в секунду, когда общая пропускная способность системы достигает 3 Вт, то, как увеличить пропускную способность, является первой проблемой, которую необходимо решить.Опрос DNS — это простое решение:
- Разверните еще несколько копий веб-сервера, 1 кот может противостоять 1000, развернуть 3 кота может противостоять 3000
- На уровне DNS-сервера доменное имя каждый раз разрешается в другой ip
преимущество:
- Нулевая стоимость: достаточно настроить еще несколько IP-адресов на DNS-сервере, и функция не тарифицируется
- Простое развертывание: разверните еще несколько веб-серверов, исходная архитектура системы не нуждается в каких-либо изменениях.
- Балансировка нагрузки: стало несколько машин, но нагрузка в основном сбалансирована
недостаток:
- Невысокая доступность: DNS-сервер отвечает только за разрешение доменного имени ip, доступна ли служба, соответствующая этому ip, DNS-сервер не гарантируется, если веб-сервер зависнет, некоторые службы будут затронуты
- Расширение емкости не в режиме реального времени: разрешение DNS имеет действительный период
- Выставлено слишком много IP-адресов внешней сети
Простой план расширения и nginx
Производительность tomcat низкая, но производительность nginx как обратного прокси намного выше.Предполагая, что онлайн работает до 1 Вт, это в 10 раз выше, чем у tomcat.Эта функция может быть использована для расширения:
- Между уровнем сайта и уровнем браузера добавляется обратный прокси-сервер с использованием высокопроизводительного nginx в качестве обратного прокси-сервера.
- nginx распределяет http-запросы на несколько внутренних веб-серверов
преимущество:
- DNS-сервер не нужно перемещать
- Балансировка нагрузки: гарантируется nginx
- Доступен только один внешний сетевой IP-адрес, и доступ к внутренней сети используется между nginx-> tomcat
- Расширение емкости в режиме реального времени: nginx можно контролировать изнутри, а веб-сервер можно добавить в любое время для расширения емкости в режиме реального времени в любое время.
- Может обеспечить доступность уровня сайта: любой кот зависает, nginx может мигрировать трафик на другие коты
недостаток:
- Увеличенная задержка + более сложная архитектура: в середине добавлен дополнительный уровень обратного прокси
- Слой обратного прокси стал единой точкой и не отличается высокой доступностью: tomcat зависает, не затрагивая сервисы, что делать, если nginx зависает?
Решение высокой доступности и поддержка активности
Для того, чтобы решить проблему высокой доступности, появился keepalived
- Два DO NGINX, составляющие кластеру, развернуты на ATEMALIVED, установленные на тот же виртуальный IP, обеспечивающий доступность Nginx
- Когда один nginx зависает, keepalived может обнаружить это и автоматически перенести трафик на другой nginx, и весь процесс прозрачен для вызывающей стороны.
преимущество:
- Решена проблема высокой доступности
недостаток:
- Использование ресурсов составляет всего 50%
- nginx по-прежнему является единой точкой доступа, что делать, если пропускная способность доступа превышает предел производительности nginx, например, qps достигает 50 000?
Продольное (увеличение масштаба) решение и LVS
В конце концов, nginx — это программное обеспечение, и его производительность лучше, чем у tomcat, но всегда есть верхний предел. LVS другой, он реализован на уровне операционной системы, и его производительность намного лучше, чем у nginx, например, он может выдерживать 10 Вт в секунду, чтобы их можно было использовать для расширения, общая схема архитектуры выглядит следующим образом:
- Если несколько tomcats можно расширить с помощью nginx, несколько nginx можно расширить с помощью lvs.
- Доступность может быть гарантирована с помощью решения keepalived+VIP.
- 99,9999% компаний в принципе могут решить проблемы высокой доступности, масштабируемости и балансировки нагрузки уровня доступа на этом шаге.
недостаток Независимо от того, используете ли вы lvs или f5, это масштабируемые решения.В принципе, lvs/f5 все еще имеет предел производительности.Предполагая, что он может обрабатывать 10 Вт запросов в секунду, он может обрабатывать только 8 миллиардов запросов в день (пропускная способность 10 Вт в секунду).*8w секунд), что делать, если ежедневный PV системы превышает 8 миллиардов? (Ну, не многие компании думают об этом)
Горизонтальный (масштабируемый) план расширения и опрос DNS
Расширение уровня - это фундаментальное решение для решения проблем с производительностью и имеет наилучшую масштабируемость с помощью Plus Experious Performance Performance.
Facebook, Google, PV Baidu - более 8 миллиардов, их доменное имя соответствует только IP, конец является начальной точкой или для расширения через опрос DNS:В настоящее время:
- Линейное масштабирование производительности входящего уровня lvs с помощью циклического перебора DNS
- Обеспечьте высокую доступность с помощью поддержки активности
- Расширить несколько nginx через lvs
- Балансировка нагрузки через nginx, маршрутизация бизнес-уровня 7
Суммировать
- Проблемными областями, которые следует учитывать в архитектуре уровня доступа, являются: высокая доступность, масштабируемость, обратный прокси-сервер + баланс расширения.
- Nginx, keepalived, lvs, f5 вполне могут решить проблемы высокой доступности, масштабируемости, обратного прокси + баланс расширения
- Горизонтальное масштабирование — фундаментальное решение проблемы масштабируемости, опрос DNS нельзя полностью заменить nginx/lvs/f5.
- Предприятия могут приобретать услуги облачной платформы для реализации аналогичных функций, экономя рабочее время и затраты.
- Необлачные предприятия также могут развертываться самостоятельно.Вышеупомянутый контент является необходимым навыком для инженеров по эксплуатации и техническому обслуживанию, и это не особенно хлопотно.
Обновление в реальном времени и высокая доступность реестра служб
кластеризация сервисов
Эта часть пропущена.Существует много статей, связанных с кластерным развертыванием микросервисов.Место этой статьи ограничено.Друзья, кто хочет знать больше, пожалуйста, найдите и прочитайте сами.
изящное завершение работы
Грамотное завершение работы приложения в микросервисной архитектуре в основном относится к запланированному и плавному выходу экземпляров приложения (то есть к отсутствию аварий, с которыми необходимо справляться). Выключения сервера приложений в основном делятся на две категории: активные выключения и пассивные выключения, среди которых активные выключения и большинство пассивных выключений могут обеспечить плавное завершение работы. Если приложение не выполняет корректное завершение работы, это приведет к следующим ситуациям:
- Потеря данных: данные в памяти не были сохранены на диск
- Повреждение файла: записываемый файл не обновляется, что приводит к повреждению файла.
- Запрос потерян: запрос в очереди был потерян, ожидая обработки.
- Отсутствует ответ: успешная транзакция не успела ответить
- Прерывание транзакции: транзакция, которая обрабатывается до промежуточного состояния, принудительно прерывается.
- Служба не находится в автономном режиме: вышестоящая служба будет продолжать отправлять запросы на потребление нижестоящей службе.
Цель элегантного обновления микросервисов — избежать описанных выше ситуаций, тем самым избегая рабочей нагрузки ручного вмешательства и повышая надежность сервисов микросервисной архитектуры.
сцены, которые будут использоваться
Мягкое завершение работы может решить следующие сценарии:
- KILL PID
- Авария приложения автоматически завершается (System.exit (n))
- Остановите приложение с помощью команды сценария
Мягкое завершение работы не может решить следующие сценарии:
- Внезапный сбой питания
- физическое уничтожение машины
- ILL-9 PID или тасккилл /f /pid
Изящное отключение для Java ShutdownHook
Грамотное завершение работы Java обычно достигается путем регистрации ShutdownHook JDK.Когда система получает команду выхода, она сначала помечает систему как находящуюся в состоянии выхода и больше не получает новые сообщения, затем обрабатывает накопившиеся сообщения и наконец, вызывает восстановление ресурсов.Интерфейс уничтожает ресурс, и, наконец, каждый поток завершает выполнение. Простой демо-кейс выглядит следующим образом (простая версия):
/**
* 优雅停机处理方式
*
* @author lry
**/
public class Main{
/**
* 启动应用
**/
public void start(){
// 第一步：启动应用服务……
// 第二步：注册JDK钩子
Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
@Override
public void run() {
System.out.println("The hook running...");
//第三步：调用停机处理
stop();
}
}));
}
/**
* 停止应用
**/
public void stop(){
// 停止应用前停机处理(如：注销服务、标记不接受请求等)
}
}
Примечание: Обычно для корректного выхода требуется механизм управления тайм-аутом.Если восстановление ресурсов и другие операции перед выходом еще не завершены, сценарий выключения напрямую вызовет KILL -9 PID для принудительного выхода, иначе он может долго ждать.
Грамотное отключение микросервисов
Следующие предлагаемые правила можно использовать для разработки механизмов корректного завершения работы микросервисов.
- Все микросервисные приложения должны поддерживать постепенное время простоя.
- Приоритет для отмены экземпляра службы, зарегистрированного в реестре
- Пометка точки доступа об отказе в обслуживании (ShutdownHook) для отключения служб
- Восходящий сервис поддерживает аварийное переключение благодаря элегантному отключению.
- Обеспечьте соответствующий интерфейс отключения в соответствии с конкретным бизнесом
Грамотное завершение работы микросервисных приложений в основном делится на два типа в зависимости от роли его пользователей.
- Мягкое закрытие бизнес-приложений
- Мягкое завершение приложений шлюза
Элегантный дизайн выключения для бизнес-приложений
Операции шагов 1–6 на приведенном выше рисунке были интегрированы в большинство микросервисных фреймворков, и разработчикам не нужно заниматься самостоятельной разработкой. Для выполнения той же операции в системе написан ShutdownHook.
Мягкое завершение работы приложения шлюза
Если Nginx не поддерживает динамическое обнаружение шлюзов, процесс простоя, апгрейда и переключения требует ручного доступа, что чуть более трудоемко, но также незаметно для пользователей.
Суммировать
Сочетая высокую доступность балансировки нагрузки на уровне доступа и высокую доступность микросервисной архитектуры, ее можно обновить в любое время, не влияя на работу пользователей и не вызывая аварий на производстве. Однако полностью автоматический процесс реализован не был, поскольку Nginx не поддерживает динамическое обнаружение шлюзов и изменение конфигурации для вступления в силу.
Nginx динамические онлайн и оффлайн сайты
Существует 4 схемы динамического обновления восходящей ветки, обычно используемые сообществом.
- ngx_http_dyups_moduleПредоставляет укрупненный метод управления восходящим потоком, который может добавлять и удалять весь восходящий поток.
- lua-upstream-nginx-module, он предоставляет метод детального управления, который может управлять определенным IP-адресом службы.Предоставленный в нем метод set_peer_down может подключаться и отключаться для определенного IP-адреса в восходящем направлении.
- ngx_dynamic_upstream
У этих плагинов есть одна общая черта: они могут динамически изменять конфигурацию nginx без перезапуска nginx.
На основе вышеуказанных плагинов его можно немного изменить для поддержки обнаружения сервисов в реестрах, таких как nacos/zookeeper/consol/erueka, и вы можете настроить необходимый модуль динамического обновления nginx reload upstream.