Как построить удаленную мультиактивность приложения?

резюме

При стремительном развитии бизнеса для многих компаний техническая архитектура, выстроенная в одном регионе, столкнется с различными проблемами, такими как: ограниченная инфраструктура ограничивает масштабируемость бизнеса; сбои на уровне машинного зала и города; стихийные бедствия, влияющие на устойчивость услуг.

Чтобы решить эти возникающие проблемы, компании могут построить многоактивную архитектуру в разных местах и построить несколько единиц (бизнес-центров) в одном городе или разных местах. Каждое бизнес-подразделение может быть распределено по разным регионам, что эффективно устраняет ограничения расширения инфраструктуры и устойчивости услуг, вызванные развертыванием в одном регионе.

Жизнь в разных местах была горячей темой в последние годы, так когда же вам нужно делать это в реальном бизнесе? Как это сделать? Что нужно учитывать при этом?

Когда это делать?

Личное ощущение зависит от следующих аспектов:

развитие бизнеса
состояние инфраструктуры
Накопление технологий

Как сделать?

В настоящее время поиск удаленных мультиактивных решений в Интернете в основном является практикой интернет-компаний Alibaba, Ele.me, JD.com, Weibo и др. Решения этих крупных компаний имеют одну общую черту: большое количество самостоятельно разработанные компоненты, Чтобы сделать связанную синхронизацию данных, бизнес-сегментацию и т. д., тогда для многих традиционных предприятий или относительно небольших предприятий, как это должно быть сделано?

Подходящие общедоступные облачные сервисы в зависимости от бизнес-характеристик

При этом на что следует обратить внимание?

Каким компаниям действительно нужно больше работать в разных местах?
Как инфраструктура?
Какова терпимость к недоступному времени?

бизнес фон

Во всех системах пользовательский центр является основным бизнесом, потому что он является необходимым условием для входа во многие другие бизнесы.
Наш IDC не очень стабилен, раньше было несколько масштабных сбоев в компьютерном зале, например, сеть компьютерного зала не работает, и весь компьютерный зал недоступен для внешнего мира.

Вышеупомянутые две точки являются отправной точкой для удаленного аварийного восстановления пользовательского центра на этот раз, чтобы обеспечить доступность службы в случае сбоев на уровне аппаратной комнаты.

Деловой кардинг

С общей точки зрения пользовательский центр в основном предоставляет такие услуги, как регистрация, вход в систему и запрос информации о пользователе. Эти услуги имеют следующие характеристики:

Логин имеет наивысший приоритет
низкие требования к транзакциям

Задействованные государственные компоненты в основном включают:

MySQL: хранилище пользовательских данных
Redis: хранение кода авторизации, кода подтверждения SMS, блокировки учетной записи, токена доступа и т. д.
Zookeeper: зависимость Даббо

план

Пользовательский центр разрабатывается на аутсорсе, он запущен и передан другому аутсорсеру для эксплуатации и обслуживания, поэтому при рассмотрении первого этапа плана аварийного восстановления необходимо максимально сохранить код.

Цель

Цель этапа 1

В случае сбоя компьютерного зала в Пекине трафик может быть переключен на компьютерный зал в Циндао в течение определенного периода времени, чтобы обеспечить базовую доступность основных услуг пользовательского центра.

Цели второго этапа

Пользовательский центр реализует высокую доступность за счет нескольких действий в разных местах (требуется групповая интеллектуальная поддержка DNS).

Архитектурный дизайн

Структура первой фазы

В случае сбоя компьютерного зала в Пекине трафик можно быстро переключить на сторону Циндао, чтобы обеспечить доступность основных служб пользовательского центра.

Конкретные планы таковы:

Основные бизнес-данные компьютерного зала в Пекине синхронизируются с компьютерным залом в Циндао почти в реальном времени через otter.
Промежуточное ПО, такое как Redis и ZooKeeper, развернуто в компьютерном зале Циндао.
Основное приложение пользовательского центра развернуто в компьютерном зале Циндао (экземпляр развернут и работает нормально, но в обычное время доступ отсутствует).

Конкретная структура выглядит следующим образом:

Эффект, которого можно достичь:

В случае сбоя компьютерного зала в Пекине трафик может быть переключен на компьютерный зал в Циндао в течение определенного периода времени, чтобы обеспечить базовую доступность основных служб пользовательского центра, но в это время вошедшие в систему пользователи должны войти в систему. снова.
Определенное время: это зависит от времени изменения IP-адреса DNS + времени TTL DNS.В настоящее время TTL составляет 10 минут, а ручное изменение IP-адреса должно быть очень быстрым, поэтому определенное время составляет 10-20 минут.

Недостатки:

В период безотказной работы компьютерного зала в Пекине машины в компьютерном зале в Циндао используются только для синхронизации базы данных, что приводит к определенной трате ресурсов.
Когда компьютерный зал в Пекине выходит из строя и трафик переключается на компьютерный зал в Циндао, можно гарантировать только доступность основной услуги входа в систему. Службы, требующие изменения базы данных, такие как регистрация, не поддерживаются. Если к таким службам обращаться в течение этого периода, возникает исключение.

Структура второй фазы

Целью второго этапа является исправление недостатков первого этапа архитектуры и достижение высокой доступности за счет нескольких действий в разных местах.

Компьютерный зал в Циндао на втором этапе будет заменен компьютерным залом Alibaba Cloud.

Конкретные планы таковы:

Через службу Alibaba Cloud DTS базы данных двух компьютерных залов синхронизируются, чтобы обеспечить согласованность данных в Пекине и Alibaba Cloud практически в режиме реального времени.
Компьютерные классы Beijing и Alibaba Cloud предоставляют онлайн-услуги для повышения эффективности использования ресурсов.
Определите приоритеты обслуживания, измените код приложения и ухудшите качество службы поддержки.
При выходе из строя компьютерного зала (Alibaba Cloud или Beijing) трафик переключается на другой компьютерный зал через службу DNS.
- Если при развертывании в двух местах нет избыточных аппаратных ресурсов, необходимо реализовать переход на более раннюю версию службы.
- В настоящее время групповое разрешение DNS не может обеспечить функцию автоматического определения доступности службы, поэтому оно не может автоматически переключаться.
  - Доступность услуги можно контролировать с помощью нашего теста многоточечного набора.Если тест многоточечного набора недоступен, соответствующее уведомление отправляется соответствующему персоналу для ручного вмешательства.
  - Существует два типа аварийных сигналов для проверки многоточечного набора: 1. Когда точка проверки набора номера недоступна 2. Когда все точки проверки набора номера недоступны.
- В настоящее время групповое разрешение DNS, самое короткое время для вступления в силу TTL составляет 10 минут, и время TTL нельзя настроить.

Конкретная структура выглядит следующим образом:

Эффект, которого можно достичь:

Если групповой DNS может быть предоставлен, он аналогичен функции мониторинга веб-сайта Alibaba Cloud DNS и может гибко устанавливать время TTL.В это время, когда компьютерный зал в Пекине или компьютерный зал Alibaba Cloud выходит из строя, он может быть автоматически в течение очень короткий период времени (максимальное нештатное время некоторых сервисов) Выполнить переключение потока.

Это всего лишь пример облачного анализа Alibaba Cloud, если он может предоставлять аналогичные услуги.

Если групповой DNS не может предоставить функции, аналогичные Alibaba Cloud DNS, для мониторинга веб-сайтов и гибкой настройки времени TTL, максимальное нештатное время некоторых сервисов по-прежнему зависит от IP-времени модификации DNS + времени TTL DNS.

Глоссарий

Что такое мониторинг сайта?

Обнаружение HTTP/HTTPS в реальном времени записей разрешения доменных имен, поддержка настраиваемых портов, обнаружение простоев в реальном времени и немедленная тревога; Распределенный мониторинг всей сети, имитирующий реальные запросы клиента в различных регионах Китая, а результаты мониторинга достоверны и достоверны; Поддержите приостановку простоя, переключение аварийного восстановления и максимально устраните прерывание обслуживания для вашего бизнеса; Переключение аварийного восстановления поддерживает записи A и доменные имена CNAME для удовлетворения требований переключения аварийного восстановления различных сценариев;

При каких обстоятельствах монитор веб-сайта определит, что он не работает, и отправит оповещение?

В результатах мониторинга только в том случае, если код возврата HTTP/HTTPS больше 500, будет уведомлено об ошибке сервера. Пример: если установлены четыре точки обнаружения: Beijing Unicom, Shenzhen Alibaba, Shanghai Telecom и Chongqing Unicom. Сценарий 1: только когда 50% точек мониторинга в четырех точках обнаружения не могут получить ответ от вашего сервера или когда 50% точек мониторинга получают код возврата больше или равный 500, ваш веб-сайт будет считаться недействительным. вниз. Сценарий 2. Если более 50 % из четырех точек обнаружения обнаружат, что код возврата вашего веб-сайта меньше 500, ваш веб-сайт не будет считаться недоступным.

Облачный DNS DNS «Управление трафиком»

Облачный DNS «Управление трафиком» может опрашивать и возвращать результаты разрешения в соответствии с коэффициентом веса для каждой установленной вами строки разрешения. Когда IP-адрес под линией не работает, он может быть автоматически обнаружен с помощью мониторинга, и отключенный IP-адрес будет удален из текущей линии до тех пор, пока IP-адрес мониторинга не станет нормальным, и разрешение не будет возобновлено. В то же время, когда все IP-адреса в строке синтаксического анализа не работают, вы можете переключиться на другие обычные линии. Максимально обеспечьте высокую доступность сервисов вашего сайта и сократите потери.

Максимальное аварийное время некоторых услуг

Например, если в компьютерном зале Пекина возникает исключение, трафик, направляемый в компьютерный зал Alibaba Cloud, может быть доступен в обычном режиме, но только трафик, пересылаемый в компьютерный зал Пекина, является ненормальным.

В настоящее время, если вы используете мониторинг веб-сайта или аналогичные службы для мониторинга и устанавливаете интервал проверки набора номера на 1 минуту, а эффективное время TTL на 1 секунду, тогда будет максимум 60 + 1 секунд ненормального времени службы. , а затем DNS автоматически изменит ip пекинского компьютерного зала, он автоматически запустится, и весь трафик перенаправится на Alibaba Cloud.

Пополнить

Реализация первого и второго этапов плана сильно зависит от службы DNS группы.
Для услуг, предоставляемых пользовательским центром через ip, в случае сбоя на уровне компьютерного зала первый этап и план второго этапа не могут гарантировать доступность этой части услуги.
На самом деле, помимо решения DNS, есть еще одно решение, которое использует устройство типа F5 для загрузки между машинными залами, но оно должно быть gslb, и оба конца должны быть одним и тем же устройством.

резюме

Для компаний, не являющихся интернет-компаниями первого уровня, необходимо использовать общедоступное облако при реализации удаленного аварийного восстановления, например:

Для синхронизации данных в компьютерных залах вы можете использовать службу DTS (служба передачи данных) Alibaba Cloud.В настоящее время DTS поддерживает передачу данных между источниками данных, такими как реляционные базы данных, NoSQL и большие данные (OLAP). Это служба передачи данных, которая объединяет миграцию данных, подписку на данные и синхронизацию данных в реальном времени.

Для распределенных баз данных по компьютерным комнатам можно использовать OceanBase. Финансовая среда обычно предъявляет более высокие требования к надежности данных.Каждый раз, когда OceanBase отправляет транзакцию, соответствующие журналы всегда синхронизируются в нескольких центрах обработки данных в режиме реального времени и сохраняются. Даже в случае сбоя на уровне центра обработки данных каждую завершенную транзакцию всегда можно восстановить в других центрах обработки данных, что соответствует истинным требованиям надежности финансового уровня.
Поскольку бизнес, инфраструктура и задачи, которые необходимо решить у каждой компании, разные, хорошо выбрать ту, которая подходит именно вам.
Или напрямую используйте ApsaraDB для RDS для MySQL

Личный публичный аккаунт WeChat:

Персональный гитхаб:

github.com/jiankunking

личный блог:

jiankunking.com