Автор: Free Fish Technology - Ву Бай
задний план
Домашняя страница и поиск всегда были основными позициями торговых гидов Xianyu.Чтобы обеспечить высокую доступность, было сделано множество схем защиты. Однако по мере того, как IDC в исходном регионе становится все более насыщенным, начинают проявляться некоторые более глубокие проблемы: а) Архитектура не масштабируется. Когда объем услуг увеличивается, один IDC не может удовлетворить требования из-за физических факторов, таких как развертывание сервера и мощность, и не может просто использовать развертывание IDC для обработки нового трафика. Если взять алгоритм в качестве примера, когда существующие ресурсы IDC перенасыщены, алгоритму приходится ждать, пока старая модель перейдет в автономный режим, прежде чем запускать новую модель, что серьезно ограничивает итеративную эффективность бизнеса. б) Проблема аварийного восстановления. Как обеспечить высокую доступность основной ссылки в справочнике по покупкам в случае сбоя существующего IDC.
Часто используемая архитектура высокой доступности
• Двойная активность в одном городе: система развернута в двух компьютерных залах в одном городе из уровня доступа ниже, чтобы она могла справляться с отказами одного компьютерного зала, такими как сбой питания и отключение сети. Поскольку компьютерные залы в одном городе расположены достаточно близко, чтобы их можно было рассматривать как один компьютерный зал, особых требований к развертыванию по сравнению с одним компьютерным залом нет. Однако в случае стихийного бедствия в том же регионе это повлияет на службу, а масштабируемость будет низкой.
• Удаленное аварийное восстановление: система из нижнего уровня доступа развернута в двух компьютерных залах в одном городе, а удаленное резервное копирование развернуто в других районах Базовые данные представляют собой горячее резервное копирование/холодное резервное копирование в соответствии с фактическими требованиями, но не несут любой трафик. При сбое области служба переключается на резервную область, чтобы обеспечить доступность службы. Однако проблема удаленного аварийного восстановления заключается в следующем: а) Другая зона не ходит по трафику и не боится обрезаться в случае возникновения проблемы. б) Резервное копирование всей станции, а коэффициент использования ресурсов низкий. c) Существует межрегиональный доступ.
• Удаленный мультиактивный: развертывание в нескольких регионах и в нескольких комнатах начинается с уровня доступа.Концепции главного и резервного между регионами нет, и все они несут соответствующий трафик. Его преимуществами являются высокая степень использования ресурсов и хорошая масштабируемость.
Как упоминалось ранее, помимо решения проблемы аварийного восстановления, Xianyu также необходимо решить проблему использования ресурсов студентов-алгоритмов, поэтому для нас естественно жить в разных местах.
Изменения, вызванные несколькими развертываниями
Когда наша система обновляется с развертывания на одной площадке до развертывания в нескольких регионах, это не просто перемещение всей системы в различные регионы для развертывания. После развертывания вашей системы вам необходимо учитывать множество факторов, таких как
• Планирование трафика, как будет проходить трафик после развертывания системы. • Самозамыкающийся контур потока. Из-за расстояния физическая задержка между регионами неизбежна. Как мы можем гарантировать, что все операции будут завершены локально после прохождения трафика? Если это невозможно сделать, как можно минимизировать влияние этой задержки. • Согласованность данных, как обеспечить согласованность данных между несколькими регионами и как устранить задержку синхронизации данных между несколькими регионами для некоторых сценариев, таких как своевременность данных, связанных с транзакциями. • Переключение аварийного восстановления. При выходе из строя компьютерного зала, как быстро перекрыть трафик в другие компьютерные залы без повреждений. Это не означает, что выполняется просто отсечение трафика.Поскольку данные синхронизируются в нескольких регионах, можно ли гарантировать согласованность данных после отсечения трафика?
Есть много других факторов, слишком много, чтобы перечислять здесь. Можно ожидать, что когда наша система будет модернизирована до многорегиональной архитектуры развертывания, это внесет большие изменения во всю систему, а также вызовет серьезные проблемы.
План развертывания в нескольких регионах
проблемы
Самой большой особенностью удаленного развертывания является высокая задержка в сети: вообще говоря, задержка в одном регионе составляет 2-3 мс, задержка в том же машинном помещении составляет менее 1 мс, а задержка между регионами обычно превышает 20 мс. Таким образом, первая проблема, которую нам нужно решить, — это как уменьшить влияние межрегиональных ссылок на руководство по покупкам.Это также является основным принципом для нас при удаленном аварийном восстановлении, которое сталкивается с рядом трудностей.
1. Как добиться движения с обратной связью в регионе, движение с обратной связью должно иметь цену, как сбалансировать отношения между ними. 2. Сложность архитектуры системы, вызванная мультирегиональным развертыванием. Будь то регулирование трафика, маршрутизация услуг или синхронизация чтения/записи данных, тонкое регулирование должно выполняться в огромной системе, и можно себе представить сложность системы. 3. Как сделать маршрутизацию трафика. Как определить источник трафика и контролировать местонахождение трафика. 4. Спецификации развертывания системы. Система постоянно развивается, как избежать быстрой порчи архитектуры. 5. Как управлять и контролировать трафик. Правила управления трафиком должны отслеживаться и контролироваться единым образом.Если трафик нужно сократить, как быстро настроить и свести трафик.
Разделяются ли пользовательские данные
Прежде чем представить архитектуру развертывания, давайте поговорим об основной предпосылке ссылки на руководство по покупкам Xianyu.Многие из следующих решений основаны на этой предпосылке, то есть следует ли разделять данные на уровне хранилища.
После удаленного развертывания данные будут находиться в нескольких регионах, и синхронизация данных между регионами будет иметь определенную задержку, поэтому необходимость разделения данных зависит от требований к согласованности данных. Если допустима кратковременная несогласованность данных, то разделение данных не требуется. Однако в некоторых сценариях электронной коммерции, например, когда покупатель добавляет в корзину, если данные записываются в области А, но список корзины считывается из области Б, очень вероятно, что покупатель не сможет чтобы увидеть недавно добавленный товар в корзину, это был очень плохой опыт. Поэтому в этом сценарии необходимо обеспечить, чтобы чтение и запись данных происходили в одном и том же измерении.В этом случае данные необходимо разделить.
Тем не менее, упомянутая выше ссылка на руководство по покупкам Xianyu имеет следующие характеристики: а) Она может допускать краткосрочное несоответствие данных. б) Не требует операций записи в базу данных. Очевидно, что разбиение данных не так уж необходимо, поэтому мы решили не разбивать данные.
Архитектура развертывания
В общей схеме развертывания каждая область физически эквивалентна, и нет понятия активной и резервной, но центральная область и другие доступные области логически различаются, потому что: -регион развертывания. б) Не все сценарии (неосновные каналы) подходят для развертывания в нескольких регионах. Мы помещаем эти длинные зависимости в центральную область и выполняем основное развертывание.
Схема маршрутизации трафика
Схема маршрутизации трафика содержит две проблемы:
•Какой принцип распределения трафика и какой трафик должен идти в какой регион. Существует три распространенных способа распределения трафика: а) Полностью случайное. б) Посещение поблизости по регионам. c) Разделите в соответствии с пользовательским измерением. • На каком уровне распределять трафик, чтобы решить, где начинают распределяться запросы пользователей.
Как упоминалось выше в разделе о разделении данных, распределение трафика теоретически должно соответствовать логике разделения данных. Поскольку нижний слой Xianyu не выполняет разбиение данных, принцип распределения трафика относительно гибкий.
1. Самый простой принцип распределения трафика — полностью случайный. Как упоминалось ранее, существует задержка синхронизации данных между несколькими регионами. Хотя ссылка на руководство по покупкам может допускать кратковременную задержку данных, нам необходимо избегать несогласованности данных, видимых пользователем для двух последовательных запросов (если два запроса выпадают отдельно в разных регионах).
1. Наименьшая задержка доступа может быть достигнута при доступе к ближайшему региону в соответствии с регионом, но самая большая проблема этой схемы в том, что трафик между регионами серьезно несбалансирован, и он постоянно меняется (обычные часы и праздничные дни), что нагрузка на всю систему.Выравнивание приносит высокий уровень сложности.
1. Разделите по пользователям, чтобы гарантировать, что некоторые запросы пользователей будут фиксированно направляться в определенную область.
В нашем сценарии руководства по покупкам варианты 1 и 2 не подходят, так как оба могут привести к несогласованности данных, отображаемых двумя запросами пользователя.В конце концов, мы выбираем сегментацию в соответствии с пользователем, что также является зрелым решением маршрутизации внутри компании. . После определения принципа распределения трафика необходимо решить, по какому слою следует распределять трафик. На данный момент мы рассмотрели три альтернативы
• Схема 1, на этапе разрешения доменного имени распределяйте трафик по разным регионам. а) Стоимость этого метода высока, и требуется независимое доменное имя DNS и независимые правила маршрутизации. б) Когда правила маршрутизации корректируются, период конвергенции длительный (в зависимости от обновления кеша на конечной стороне). в) Привязка к операционной среде, не поддерживает H5, Web и другие сценарии. Его преимущество в том, что он был проверен внутри компании и является относительно зрелым.
• Вариант 2. Распределите трафик по разным регионам на унифицированном уровне доступа. Этот метод является недорогим, может повторно использовать существующую логику и требует только настройки правил на унифицированном уровне доступа, но некоторый трафик имеет межрегиональный доступ (от уровня доступа к бизнес-кластеру).
• Вариант 3. Создайте пограничный шлюз. Выполните разрешение доменного имени через собственный DNS, а затем выберите ближайший пограничный шлюз для доступа. Сложная логика, такая как отсечение потока, выполняется в пограничном шлюзе. Это решение не имеет ничего общего со средой выполнения, поддерживает приложения, апплеты, веб-сайты и т. д., а также отличается высокой скоростью конвергенции при корректировке правил и высокой масштабируемостью. Недостаток в том, что нужно строить инфраструктуру с 0.
Нам нужно избежать межрегиональной проблемы Варианта 1. Хотя Вариант 3 более подходит, стоимость слишком высока, и нет зрелого опыта, на котором можно было бы учиться. Мы, наконец, решили принять Вариант 2, взвесив его.
Полное обновление ссылки
Цель полносвязного преобразования — адаптировать нашу систему к переходу от развертывания на одной площадке к развертыванию в нескольких регионах.Преобразование включает в себя множество моментов, в основном в том числе:
1. Модификация кода приложения. Могут ли все зависимости ссылки на руководство по покупкам быть развернуты в нескольких местах, и будет ли увеличиваться межрегиональная задержка, если ее нельзя развернуть в нескольких местах. 2. Стратегия маршрутизации трафика между сервисами. Ссылка на руководство по покупкам включает в себя множество разнородных подсистем. Следует ли трафик между этими разнородными системами следовать одному и тому же приоритету региона и разрешено ли трафику автоматически переключаться на другие регионы после приостановки обслуживания определенного региона. 3. Сильная коррекция потока. Ссылка запроса гида по магазинам более сложная и зависит от множества разнородных подсистем. Несмотря на то, что при разрешении доменного имени трафик будет направляться в соответствующую область, при последующих ссылках трафик все же может перетекать в другие области. В этом случае теоретически это повлияет на взаимодействие с пользователем. Поэтому в каждом руководстве по покупкам ссылка Все прыжковые узлы должны иметь стратегию коррекции смещения. 4. Мы не можем контролировать внешний трафик из-за стратегии распределения, что приведет к неожиданному притоку трафика. Чтобы избежать этой ситуации, нам также необходимо иметь стратегию коррекции трафика.
Точка преобразования 3 важна в сценарии строгой согласованности данных, но для этой ссылки на руководство по покупкам из-за взаимосвязи между стоимостью преобразования и временем мы, наконец, отказались от точки преобразования 3. Поскольку точка преобразования 2 гарантирует, что путь потока соответствует ожиданиям в нормальных условиях, и только ненормальные условия могут привести к тому, что поток будет течь в другие области, но в этом случае мы считаем, что: а) частота низкая и продолжительность не велика. б) Краткосрочное несоответствие оказывает контролируемое влияние на бизнес.
Преобразование кода приложения в основном включает
• Для тех зависимостей, которые не могут быть развернуты во многих местах, оцените их ограничения на согласованность данных.Если это слабая согласованность, рассмотрите возможность использования режима расширенного клиента.В режиме расширенного клиента сначала прочитайте кэш и повторите попытку, если он пропустит hit.RPC, который снижает частоту межрегиональных запросов за счет кэширования.
• Для зависимостей, которые не могут быть развернуты в нескольких местах и требуют строгой согласованности данных, необходимо избегать увеличения задержки доступа в разных регионах. Когда нет межрегиональной задержки, разница между последовательной и параллельной не очевидна, но после введения межрегиональной задержки разница между последовательной и параллельной будет очень очевидной, поэтому эту часть зависимости необходимо изменить. одновременно. С другой стороны, в процессе преобразования основные зависимости и неосновные зависимости сортируются, основные зависимости принудительно объединяются, а неосновные зависимости становятся параллельными, наблюдаемыми и деградируемыми.
• Модернизация кэша. Из-за недостаточно строгого использования кэша в прошлом проблемы, которые были скрыты при развертывании в одном регионе, будут обнаружены при развертывании в нескольких регионах. Например, в следующем сценарии ключ записывается в одном сценарии, а затем считывается в другом сценарии. При развертывании в одном регионе проблем нет, но при развертывании в нескольких регионах может возникнуть несогласованность данных из-за чтения и записи в разных регионах.
В этом случае нам необходимо: a) Принудительно записать на центральный мастер-узел. б) Включите синхронизацию данных с главного узла на другие регионы. В общем, есть два принципа преобразования кеша
• Если это непостоянный кэш, модификация не требуется. Из-за этого промаха кеша сцены будет процесс загрузки данных. Однако многие сценарии непостоянного кэша злоупотребляют постоянными кэшами, поэтому в таких случаях их необходимо стандартизировать и преобразовать в непостоянные кэши. • Если это постоянный кэш, возможны два случая: a) Строгая согласованность, такая как распределенные блокировки, в этом случае принудительно используется главный кластер центра чтения-записи. б) Если непротиворечивость не является строгой, центральный мастер-узел принудительно записывается, а ближайший — считывается.
Ссылка на руководство по покупкам включает в себя множество разнородных систем, в том числе кластеры микросервисов, образованные приложениями в различных подобластях, и множество служб поиска и рекомендаций. Неоднородность в основном отражается в: а) Различиях в языках программирования и платформах развертывания, эксплуатации и обслуживания. б) Механизм обнаружения регистрации службы отличается, в основном, включая configserver/vipserver/zookeeper. Таким образом, основное содержание преобразования заключается в регулировании использования этих компонентов и корректировке стратегии маршрутизации трафика для обеспечения самозамыкающейся петли в зоне трафика.
Чтобы предотвратить влияние внешнего трафика на трафик справочника по покупкам Xianyu, мы добавили политику коррекции трафика на унифицированный уровень доступа: для трафика внешних ссылок, не связанных с покупками, он принудительно переключается обратно в центральную область. Это очень важно, потому что для сервисов вне области развертывания, если трафик по этой причине уходит в другие зоны доступности, мы не можем гарантировать корректность возвращаемых данных.
Схема развертывания сервисного кластера
Кластер микросервисов использует одноранговое развертывание в целом. Кластеры микросервисов делятся на три категории в соответствии с механизмами обнаружения и регистрации сервисов:
•Используя HSF в качестве бизнес-службы инфраструктуры RPC и используя configserver для обнаружения служб, configserver одновременно развертывается в нескольких регионах и изолирован друг от друга.Службы, развернутые в каждом регионе, извлекают данные configserver только из домен.изоляция трафика между. Однако данные в центральной области будут синхронизированы с другими областями (трафик может быть направлен в центральную область, если область приостановлена для обеспечения доступности службы).
• Алгоритм сервисного кластера с использованием HTTP-вызова использует два метода регистрации и обнаружения сервисов по историческим и разнородным причинам.
• Работник зоопарка. Zookeeper разворачивается отдельно в центре и регионе, по запросу клиента подтягивается соответствующий Zookeeper по региону. Таким образом, доступ к трафику может осуществляться в одном и том же компьютерном зале, а данные между регионами изолированы друг от друга.При возникновении сервисной проблемы в одном регионе ее можно восстановить только путем монтирования сервисных данных других регионов в Zookeeper. соответствующий неисправному региону. • vipserver (набор системы балансировки нагрузки программного обеспечения маршрутизации кластера, разработанной Alibaba). Поскольку vipserver сам по себе является распределенной системой балансировки нагрузки и поддерживает несколько методов маршрутизации, развертывается только один набор.
Есть много мест, где ссылки на руководство по покупкам используют кеш, который можно условно разделить на два варианта использования.
• Уменьшите давление доступа на уровне сохраняемости. Сначала обратитесь к кешу. Если в кеше нет данных, он запрашивает уровень сохраняемости и загружает данные в кеш. Сам кеш не гарантирует согласованности данных. С этой ситуацией проще справиться, так как она не требует синхронизации между несколькими регионами и требует только развертывания в нескольких регионах.
• Используется для сохранения данных. Типичными примерами являются распределенные замки, счетчики и т. д. Этот сценарий будет иметь концепцию центра и региона, которые синхронизируются друг с другом в двух направлениях.Этот сценарий мало чем отличается от вышеприведенного использования при развертывании в одном регионе, но в архитектуре развертывания с несколькими регионами данные будут отображаться из-за двойной записи Несовместимы, поэтому необходимо убедиться, что один и тот же ключ не может быть записан в несколько регионов одновременно.
• Зоны синхронизируются с центром. Поскольку данные необходимо сохранять, в центре будет полный набор данных, а регион может обеспечить окончательную согласованность данных. • Центральная синхронизация с зоной. Убедитесь, что данные в регионе совпадают с данными в центре.
Развертывание базы данных
Согласно теореме CAP о распределенных системах: Consistency (непротиворечивость), Availability (доступность) и Partition trust (разделительная толерантность). Так что, строго говоря, для удаленного развертывания базы данных можно выбрать только два варианта из трех. Однако в распределенной системе она должна быть разделена, и мы не можем управлять сетью между разделами, то есть P является фактом, и мы можем выбрать только один из C и A, которые соответствуют двум типам баз данных. соответственно Метод репликации данных.
• MySql в режиме репликации ведущий-ведомый: центр вернется после успешной записи, а подчиненный узел зависит от синхронизации данных между ведущим и подчиненным. А и Р гарантируются в этом режиме за счет С.
• MySql в режиме двунаправленной репликации: нет различий между главным и подчиненным узлами, и данные между узлами в конечном итоге согласуются. В этом режиме также гарантируются А и Р за счет С.
• Распределенные базы данных, использующие протокол Paxos, такие как Spanner от Google, используют протокол Paxos для обеспечения строгой согласованности данных, но после того, как главный узел повесит трубку, он будет недоступен до тех пор, пока не будет выбран новый главный узел, то есть C и P. гарантированы, жертвуя A.
С одной стороны, по характеристикам ссылок в справочнике по покупкам (большинство из них представляют собой операции чтения данных, которые могут допускать несоответствия за короткий промежуток времени). С другой стороны, исходное хранилище данных использует MySql.Учитывая стоимость, окончательно выбран режим репликации master-slave MySql.
Суммировать
Самая большая проблема, связанная с удаленным развертыванием системы, — это задержка в сети, вызванная физическим расстоянием, и весь дизайн системы вращается вокруг этого. В целом, мы следуем двум основным принципам в процессе решения межрегиональных задержек: а) Самозамыкание петель внутри регионов движения. б) В первую очередь придерживайтесь юзабилити. В соответствии с этими двумя основными принципами были выполнены соответствующие преобразования и развертывания на уровне доступа, уровне обслуживания и уровне хранения данных.
В настоящее время некоторые ссылки Xianyu развернуты в двух местах и трех компьютерных залах и уже осуществляют онлайн-трафик с возможностью удаленного аварийного восстановления. В то же время после этого преобразования ссылка на руководство по покупкам имеет хорошую масштабируемость и может быть быстро развернута в большем количестве компьютерных залов по очень низкой цене.
Однако, с одной стороны, поскольку большинство ссылок на руководство по покупкам предназначены только для чтения, требуется слабая согласованность данных. Для сценариев со строгой согласованностью данных проблема для системы будет еще более сложной. С другой стороны, бизнес — это процесс непрерывной эволюции, и как обеспечить развертывание архитектуры множества активностей в разных местах в процессе эволюции — актуальная проблема, требующая решения.