Управляемое чтение: В этой статье в основном представлен некоторый практический опыт AutoNavi в создании сервисных модулей.Создание сервисных модулей сталкивается со многими общими проблемами, такими как маршрутизация запросов, закрытие модулей и синхронизация данных.Некоторые из них имеют зрелые решения, которые можно использовать для справки и использования, но разные компании. Различные виды бизнеса необходимо максимально сочетать с бизнес-характеристиками, чтобы соответствующим образом их разрабатывать и работать с ними.
1. Зачем объединяться
- Узкое место в ресурсах одноместного номера
С ростом объема бизнеса и групп пользователей услуг одна или две компьютерные комнаты в одном городе не могут поддерживать постоянное расширение услуг.
- Услуга удаленного аварийного восстановления
Аварийное восстановление в удаленных местах стало стандартом для основных служб. Хотя некоторые службы были развернуты в нескольких местах и в нескольких компьютерных залах, данные по-прежнему находятся только в центральном компьютерном зале. преобразовать в единицы.
2. Особенности юнитизации Gaode
При работе над проектом унификации AutoNavi первое, что нам нужно рассмотреть, — это объединить бизнес-характеристики AutoNavi и посмотреть, какие различные требования предъявляются к унификации AutoNavi, чтобы мы могли знать, какой опыт и решения можно использовать напрямую. решать нам.
Бизнес AutoNavi отличается от традиционного бизнеса онлайн-транзакций. AutoNavi предоставляет пользователям туристические услуги, представленные навигацией. Многие бизнес-сценарии предъявляют высокие требования к RT для услуг, поэтому при создании унифицированных решений сокращайте их как можно больше. Влияние на общий сервис RT — это то, на чем нам нужно сосредоточиться, и постараться, чтобы данные были как можно ближе к пользователю. Переход на унифицированный технологический уровень требует решения двух задач:
1. Блок доступа к пользовательскому оборудованию должен быть как можно ближе к ближайшему блоку.Реальное географическое положение пользователя близко к тому, какой блок подключен к какому блоку.Например, пользователи в Северном Китае имеют доступ к Чжанбэй, а Южный Китай выходит в Шэньчжэнь.
2. Предпочтительно, чтобы единица подразделения пользователя соответствовала единице, подключенной к ближайшей единице, чтобы уменьшить межблочную маршрутизацию между единицами. Если пользователь запрашивает прибытие из Шэньчжэня, подразделение пользователя лучше всего использовать в подразделении Шэньчжэнь, а если оно разделено на подразделение Чжанбэй, это вызовет маршрутизацию между подразделениями.
Еще одно отличие состоит в том, что многие предприятия AutoNavi не требуют входа в систему, поэтому наше унифицированное решение также поддерживает идентификатор устройства на основе идентификатора пользователя в дополнение к идентификатору пользователя.
3. Практика объединения Gaode
Преобразование сервисов в унифицированную архитектуру требует систематического проектирования сверху вниз, и ядро должно решить три проблемы: маршрутизацию запросов, закрытие блоков и синхронизацию данных.
Закрытие подразделения: благодаря построению инфраструктуры группы мы используем vipserver, hsf и другие возможности управления службами, чтобы гарантировать, что службы вызываются в том же компьютерном зале, чтобы добиться закрытия подразделения (модель модуля hsf также является возможным решением, но Я лично считаю, что тот же компьютерный зал называется Архитектура и шаблоны лаконичнее и проще в обслуживании).
Синхронизация данных: часть данных использует синхронизацию данных DRC, предоставляемую продуктами группы DB.
Еще одна проблема, с которой нам придется столкнуться, — это схема развертывания службы маршрутизации устройств. Были рассмотрены следующие три схемы:
Архитектура сервисного подразделения
В настоящее время учетная запись AutoNavi, облачная синхронизация и система комментариев пользователей преобразованы в блоки. Служба облачной синхронизации развернута в трех местах и четырех компьютерных залах. Служба облачной синхронизации с большим объемом записи может достигать нескольких w + QPS (хранилище кластер монгодб).
Возьмите систему учетных записей в качестве примера, чтобы представить общую архитектуру унифицированного приложения AutoNavi.
PS: По историческим причинам кеш использует таир и самодельный uredis (функция синхронизации данных на основе лога добавлена на базе redis), и он постепенно унифицирован с tair. Синхронизация данных опирается на решения по синхронизации данных от tair и alisql, а также на встроенную возможность синхронизации данных uredis.
Решение для ближайшего доступа
Чтобы удовлетворить требования сервисов AutoNavi к малой задержке, мы должны найти способ приблизить данные (устройство) к пользователю. внутренняя маршрутизация службы (насколько это возможно без создания межблочной маршрутизации).
Мера 1: Доступ клиента к внешней сети Благодаря конфигурации на сервере устройства в разных географических зонах (семь регионов) делятся на соответствующие блоки, например, пользователи из Северного Китая получают доступ к блоку Zhangbei.
Мера 2: Разделить блок, к которому принадлежит пользователь, с помощью таблицы маршрутизации, в которой записаны отношения между пользователем и блоком.Эта связь анализируется через системный журнал.Из какой записи блока пользователь часто входит, пользователь будет разделен на какой блок, чтобы гарантировать, что запись запроса и разделение блока относительно согласованы, тем самым уменьшая маршрутизацию между блоками.
Поэтому в окончательной реализации модульной маршрутизации мы предлагаем две стратегии: традиционную маршрутизацию по модулю и маршрутизацию на основе таблицы маршрутизации, предназначенную для уменьшения задержки. В то же время, чтобы решить проблему бизнес-сценариев, не требующих входа в систему, две вышеупомянутые стратегии поддерживают не только идентификатор пользователя, но и идентификатор устройства.
Таблица маршрутизации разделена на две части: одна представляет собой таблицу сопоставления взаимосвязей между пользователями и группами, а другая — таблицу сопоставления взаимосвязей между группами и устройствами. При использовании найдите соответствующую группу в таблице маршрутизации, а затем посмотрите на устройство, к которому принадлежит пользователь, в группе. Группировка соответствует семи регионам материкового Китая.
Давайте сначала посмотрим на «группировку пользователей (регионов)»:
Таблица маршрутизации регулярно анализируется через системный журнал и делится на группы, в зависимости от того, к какому региону принадлежит последний IP пользователя, а также соответствует конкретному устройству. Когда пользователь из Пекина находится в Шэньчжэне в течение длительного времени, таблица маршрутизации будет обновлена, чтобы быть сгруппированной в новую область из-за изменения IP-адреса, тем самым завершив миграцию пользователя из подразделения Чжанбэй в подразделение Шэньчжэнь.
Посмотрите еще раз на "grouping-unit":
Между группировкой и сопоставлением единиц существует связь по умолчанию, которая настраивается в соответствии с географической близостью, например, Южный Китай соответствует Шэньчжэню. В дополнение к отношениям сопоставления по умолчанию существует несколько сопоставлений отношений для сценариев переключения потоков.
расчет маршрута
Следующим шагом с таблицей маршрутизации является решение проблемы инженерных приложений.Производительность, пространство, гибкость и точность, а также влияние на стабильность службы необходимо учитывать всесторонне.Прежде всего, внешнее хранилище повысит стабильность. риск службы, мы выбираем BloomFilter среди различных схем BloomFilter, BitMap и MapDB позже, межблочная маршрутизация, вызванная ложным коэффициентом попадания в несколько десятитысячных, находится в пределах приемлемого диапазона бизнеса.
-
Поскольку в BloomFilter присутствует коэффициент просчета, может возникнуть ситуация, когда пользователи, сгруппированные в Южном Китае, учитываются в Северном Китае, и пропорция этой ситуации составляет 3/10 000 (настраивается при создании BloomFilter), что не влияет на бизнес. Пользователь эквивалентен разделению на группу, которая не находится на большой территории, но эта связь стабильна и не повлияет на бизнес, но существует маршрутизация между подразделениями, что допустимо.
-
Новый пользователь не находится в информации о группировке, поэтому соответствующая группировка большой площади не сопоставляется после послойного расчета.В настоящее время модуль используется для расчета группировки модульного деления.
Сотовые разрезы
Когда происходит отказ устройства и поток прерывается, он в основном делится на четыре этапа.
Включите запрет на запись блока (невозможно настроить бизнес, нечувствительный к записи между блоками)
Проверьте деловую задержку
сменить план
Разблокировать блок записи
PS: При обновлении таблицы маршрутизации также требуются вышеуказанные операции, но план переключения на шаге 3 становится переключением таблицы маршрутизации новой версии; запрет на запись блока в основном заключается в ожидании синхронизации данных, чтобы избежать вызванных бизнес-проблем по несоответствию данных.
основные показатели
Расчет единицы измерения занимает 1~2 мс
Коэффициент межблочной маршрутизации менее 5%
В дополнение к производительности, коэффициент маршрутизации между устройствами также является важным показателем, который нас больше беспокоит из-за требований к близлежащему доступу. Судя по онлайн-наблюдению, расчет блока политики таблицы маршрутизации в основном выполняется в течение 1 или 2 мс, доля маршрутизации между блоками составляет около 3%, а общее дно составляет менее 5%.
В-четвертых, последующая оптимизация
Единый доступ, интегрированная возможность объединения
В настоящее время большинство сервисов подключено к сервису унифицированного шлюза доступа. Интегрированные унифицированные возможности шлюза значительно снизят стоимость унифицированного развертывания сервисов. Маршрутизация модулей может быть достигнута за счет простой настройки, а сервисы могут больше ориентироваться на бизнес. , Устройство закрывается, и данные синхронизируются.
Оптимизация механизма группировки
Есть три проблемы с группировкой по регионам:
В области расчета IP существует определенная частота просчетов, из-за которой некоторые пользователи разделяют неправильную группу.
Степень детализации пакетов слишком велика, и трафик не распределяется легко при переключении устройства. Например, если Восточный Китай является большой территорией, где сосредоточены наши пользователи, переключение этой группы на любой назначенный блок во время переключения трафика вызовет чрезмерную нагрузку на службу блока.
Количество вычислений велико, сколько больших областей разделено, и сколько раз теоретическое максимальное количество вычислений, и, наконец, принята стратегия по модулю.
В ответ на вышеуказанные проблемы мы планируем внести следующие улучшения в механизм группировки.
Единица, к которой принадлежит пользователь, подтверждается записью пользователя, входящего в единицу, а не суждением, основанным на регионе, где находится IP-адрес пользователя, и вышеуказанная проблема 1 решена.
Каждый блок разделен на 4 виртуальные группы для поддержки более детального переключения блоков и решения указанной выше проблемы 2.
После того, как пользователь подтвердил единицу, она делится на разные виртуальные группы по модулю. Каждый модуль может быть выполнен только с одним расчетом, а новым пользователям нужно выполнить только три расчета, чтобы решить вышеуказанную проблему 3.
В отличие от стратегии маршрутизации по модулю, стратегию таблицы маршрутизации необходимо регулярно обновлять, чтобы лучше контролировать маршрутизацию между модулями.В настоящее время во время обновления требуется кратковременный запрет записи модулей, что неприемлемо для многих Сервисы.
Чтобы оптимизировать эту проблему, система будет выполнять двойной расчет (маршрутизации) таблицы при обновлении таблицы маршрутизации, то есть новая и старая таблицы маршрутизации будут загружаться в память одновременно, и бизнес не будет полностью отключается при обновлении.Текущего пользователя (или устройство) будем вычислять в единицах результатов новой и старой таблиц маршрутизации, если единицы согласованы, значит, обновление таблицы маршрутизации не вызвало пользователя (или устройство) изменить единицу измерения, поэтому запрос будет разблокирован, и наоборот, если в результате расчета будет другая единица измерения, то это означает, что в единице измерения произошли изменения, запрос будет заблокирован до полного времени активации новой маршрутизации стол достигнут.
До оптимизации сервис будет полностью отключен от записи, например, на 10 секунд (время зависит от времени синхронизации данных), после оптимизации им станет пользователь, маршрут которого изменился в течение 10 секунд, срабатывает запрет на запись , что значительно снизит влияние на бизнес.
Унифицированные сценарии на стороне сервера, управляемые данными
Как упоминалось выше, AutoNavi сочетает в себе особый дизайн бизнеса со стратегией маршрутизации, но общее деление единиц по-прежнему основано на измерении пользователя (или оборудования), но для бизнеса AutoNavi все еще существует большой сценарий, с которым мы столкнемся и решим. в будущем Да, дизайн устройства определяется измерением данных, и маршрутизация услуг на основе терминалов станет маршрутизацией услуг на основе предметной области.
напиши в конце
Разные бизнес-сценарии предъявляют разные требования к унификации. Мы предлагаем разные стратегии и возможности для выбора бизнеса. Для сервисов с несколькими данными мы рекомендуем использовать бизнес-модульную маршрутизацию, которая проста и удобна в обслуживании; для сервисов, чувствительных к RT, используйте стратегию таблиц маршрутизации. чтобы свести к минимуму влияние времени отклика службы. Кроме того, следует отметить, что службы с сильными зависимостями должны использовать одну и ту же стратегию маршрутизации.