Техническая команда Ele.me потратила более года, чтобы реализовать общую удаленную многозадачность бизнеса и может гибко планировать пользователей между несколькими удаленными компьютерными комнатами, достигая целей бесплатного расширения и аварийного восстановления нескольких компьютерных комнат. В этой статье представлена общая структура проекта, а также кратко представлены пять основных основных компонентов, которые реализуют многозадачность, и установлена базовая концептуальная модель для читателей.Будет серия статей, посвященных деталям реализации каждого компонента. после другого. Читатели могут понять общее направление проведения большего количества прямых трансляций в разных местах и предоставить справочные материалы для реализации своих собственных живых выступлений в разных местах или резервного копирования для аварийного восстановления.
Предыстория: Почему вы живете вне офиса?
Вы голодны? Это обусловлено развитием бизнеса. После нескольких лет быстрого развития наш бизнес расширился до такой степени, что один центр обработки данных больше не может его поддерживать. Главный компьютерный зал больше не может добавлять машины, но бизнес продолжается. Чтобы требовать большего Расширение емкости, поэтому нам нужно решение, позволяющее развертывать серверы в нескольких компьютерных залах. Другая более важная причина заключается в том, что сбои на уровне всего машинного зала происходят время от времени, и каждый раз это приносит серьезные последствия.Нам нужно иметь возможность переносить весь бизнес одного компьютерного зала в другой компьютерный зал, когда Ошибка возникает, чтобы убедиться, что услуги доступны.
Подводя итог, мы хотим достичь двух целей:
- Услуги могут быть распространены на несколько компьютерных залов.
- Способность справляться со сбоями в масштабе всей комнаты
Обычный способ решения этих двух проблем заключается в том, чтобы выполнять больше работы в разных местах и распределять службы по нескольким компьютерным залам, а проблемы естественного расширения и высокой доступности решаются легко.
У Ele.me есть свои особые обстоятельства.Для большинства других компаний вопрос о том, делать больше работы или нет, в основном зависит от кривой, как на рисунке ниже.
Для предприятия с быстрым ростом бизнеса потери, вызванные каждым сбоем, также будут соответственно увеличиваться, а инвестиции в технологии, как правило, линейны. Первоначальные потери от сбоев меньше, чем инвестиции в технологии. В определенный момент времени потери от сбоев будут превышают инвестиции в технологии, в настоящее время нам необходимо использовать некоторые решения с высокой доступностью, чтобы избежать сбоев, и наиболее важной является дополнительная работа.
Основная проблема, с которой сталкиваются удаленные мульти-активности, — это задержка сети.От Пекина до Шанхая 1468 километров, даже при скорости света туда и обратно требуется около 10 мс.Во время фактического теста мы обнаружили, что задержка сети из Шанхая до Пекина обычно 30 мс. . Эти 30 мс можно сравнить с другими временами задержки в вычислительной системе:
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
Round trip within same datacenter ...... 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms
Сетевая задержка между двумя машинными залами в Шанхае ................................ 1 000 000 нс = 1 мс
Disk seek ........................... 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms
Сетевая задержка от Пекина до Шанхая 30 000 000 нс = 30 мс
Send packet CA->Netherlands->CA .... 150,000,000 ns = 150 ms
Время задержки в сети в Пекине и Шанхае примерно в 60 раз превышает скорость доступа во внутренней сети (30 мс/0,5 мс).Если одна сторона напрямую обращается к службе другой стороны без каких-либо изменений, ответ нашего приложения будет медленнее, чем 60 раз, на самом деле, учитывая несколько циклов, это может быть в 600 раз медленнее.
Если все компьютерные классы находятся в Шанхае, сетевая задержка всего в два раза превышает скорость внутренней сети, которую можно использовать в качестве компьютерного класса. Все мультиактивные решения некоторых компаний будут выбирать один и тот же городской компьютерный зал и развертывать несколько компьютерных залов в том же городе в качестве одного компьютерного зала Это быстрый и эффективный метод расширения нескольких компьютерных залов без ущерба для структуры обслуживания. В первые дни многозадачности мы также обсуждали план одного и того же города, например, строительство нового компьютерного зала вокруг Пекина, перенос некоторых служб в новый компьютерный зал, соединение двух компьютерных залов выделенными линиями и создание перекрестных сетей. вызовы компьютерного зала между служебными помещениями. Хотя это решение относительно простое и решает проблему расширения машинного зала, оно не годится для обеспечения высокой доступности и, наоборот, сопряжено с более высокими рисками.
В отличие от мультиактивного решения в одном городе, мультиактивное решение в разных местах ограничит взаимные вызовы компьютерных залов, необходимо определить четкие границы обслуживания, уменьшить взаимозависимость и сделать каждый компьютерный зал независимой единицей, не зависит от других компьютерных залов. После нескольких размышлений мы, наконец, выбрали план проживания в разных местах. Сравнение и обдумывание этих двух планов можно увидеть в таблице ниже. Хотя жить в разных местах сложнее, это может достичь наших двух основных целей в одновременно.
Дизайн: Идеи и методы реализации мультиактивности в разных местах
Существует несколько основных принципов нашей удаленной многофункциональной программы, и вся многофункциональная программа является естественным следствием этих принципов. Но прежде чем представить эти принципы, мы должны сначала объяснить процесс обслуживания Ele.me, чтобы каждый мог лучше понять происхождение этих принципов.
Следующая диаграмма является нашим основным процессом:
В бизнес-процессе есть 3 самые важные роли, а именно пользователи, мерчанты и райдеры Заказ состоит из 3 шагов:
- Когда пользователь открывает наше приложение, система будет рекомендовать различные продукты поблизости от местоположения пользователя.Последовательность рекомендаций сочетает в себе привычки пользователя, ранжирование рекомендаций и продвижение продавца. Пользователи находят понравившуюся еду, оформляют заказ и оплачивают, и заказ поступает к продавцу.
- Продавец принимает заказ и начинает готовить еду, а после того, как производство завершено, система отправляет райдера спешить в магазин, чтобы забрать еду.
- Райдер доставляет еду покупателю в соответствии с адресом доставки.
Существуют строгие требования ко времени от размещения заказа до завершения доставки, и он должен быть выполнен в течение нескольких десятков минут.Наши услуги тесно связаны с географическим положением и имеют высокие требования к реальному времени.Региональные услуги и услуги в режиме реального времени Наши основные функции, самое главное для мультиактивного дизайна — удовлетворить эти две функции.
После неоднократных обсуждений наша мультиактивная архитектура отвечает этим двум основным характеристикам, следуя следующим основным принципам:
- Сплоченность бизнеса: процесс заказа на поездку одного заказа должен быть выполнен в одном компьютерном зале, и вызовы между компьютерами не допускаются. Этот принцип заключается в обеспечении производительности в режиме реального времени, чтобы не было задержек в процессе заказа на поездку, не полагаясь на обслуживание другого компьютерного зала. Мы называем каждую компьютерную комнату эзоной, а эзона содержит различные сервисы, которые нужны Ele.me. Бизнес может быть связан в одной зоне, тогда пользователи, продавцы и райдеры, участвующие в заказе, будут находиться в одном и том же компьютерном зале, так что заказ будет перемещаться между различными ролями с максимальной скоростью, и не будет задержки из-за к различным нештатным ситуациям. Так уж получилось, что наш бизнес регионализирован, и сплоченность бизнеса также может быть достигнута за счет разумного географического разделения.
- Приоритет доступности: когда происходит аварийное переключение, система получает приоритет для обеспечения доступности системы.Во-первых, пользователи могут размещать заказы на питание, допускать несоответствия данных в течение ограниченного периода времени, а затем устранять их. Каждая зона будет иметь полные бизнес-данные.Если одна зона выходит из строя, другие зоны могут взять на себя управление пользователем. Данные о заказах, размещенных пользователями в одной зоне, будут скопированы в другие зоны в режиме реального времени.
- Убедитесь, что данные верны: в случае обеспечения доступности данные должны быть защищены, чтобы избежать ошибок.Во время переключения и сбоя, если будет обнаружено, что статус некоторых заказов не соответствует между двумя компьютерными залами, заказ будет заблокирован, чтобы предотвратить его изменение. , чтобы обеспечить правильность данных.
- Восприятие бизнеса: поскольку инфраструктура недостаточно сильна, чтобы стереть различия между компьютерными классами, необходимо довести до сведения бизнеса логику многозадачности, и бизнес-код должен быть преобразован, в том числе: бизнес-код должен быть в состоянии определить атрибуцию бизнес-данных и работать только с этими данными, отфильтровывая нерелевантные данные. Улучшите конечный автомат бизнес-процессов, который может обнаруживать и исправлять несоответствия данных с помощью конечного автомата.
Эти основные принципы пронизывают весь дизайн Elephant.com.
Основываясь на этих принципах, мы разработали мультиактивное решение с точки зрения разделения услуг, маршрутизации трафика и трансформации бизнеса.Ниже приводится краткое введение в основную логику.
Сервисное подразделение (шардинг):
Чтобы добиться сплоченности бизнеса, мы должны сначала выбрать метод разделения (Sharding Key) для разделения услуг, чтобы пользователи, продавцы и пассажиры могли правильно объединиться в одну и ту же зону. Схема разделов является основой всего мультилайва и определяет всю последующую логику.
Согласно бизнес-характеристикам Ele.me, мы, естественно, выбираем географическое местоположение в качестве единицы бизнес-подразделения и разделяем географически близких пользователей, продавцов и пассажиров на одну и ту же зону, чтобы процесс выполнения заказа был завершен в одной зоне. компьютерный зал., который может обеспечить минимальную задержку.Когда проблема возникает в определенном компьютерном зале, пользователи, продавцы и пассажиры также могут быть упакованы и перенесены в другие компьютерные залы в соответствии с их географическим расположением.
Поэтому решение, которое мы в конечном итоге выбрали, показано на рисунке ниже. Мы определяем забор географического деления и разделяем всю страну на несколько осколков заборами. Границы заборов должны максимально соответствовать административным и провинциальным границам. Если необходимо внести некоторые коррективы, чтобы заборы не проходили через городскую территорию. Эзона может содержать несколько осколков.Осколок эзоны может быть переключен на другую эзону в любое время с гибким планированием ресурсов и отказоустойчивостью.
Такой план разделения в основном решает проблему размещения заказов в разрушенных городах, а межзональных заказов онлайн не наблюдалось. Разделение ограждения является гибким и может быть изменено по мере расширения бизнеса в будущем.Поскольку каждый компьютерный зал содержит полные данные, настройка ограждения не вызовет проблем.
Есть несколько общих вопросов об этом методе деления, например:
1. Если два города граничат, возникнут ситуации, когда предприятия и пользователи будут находиться в разных зонах, не нарушает ли это принцип сплоченности?
Такая ситуация действительно имеет место, чтобы максимально избежать ее, мы не просто использовали название города при разделении шарда, а использовали сложную геозону для достижения основной части геозоны, лимит позволяет избежать ситуации выставления ордеров по эзоне. Но если он все же появится, то на заказ пользователя это не повлияет, в состоянии максимум задержка около 1с.
2. Пользователи могут перемещаться.Если пользователи путешествуют из Пекина в Шанхай, как должны обрабатываться правила деления?
Когда пользователь размещает заказ в Пекине, данные попадают в сегмент Пекина, а когда он размещает заказ в Шанхае, данные попадают в сегмент Шанхай. С помощью базового инструмента синхронизации данных пользователи могут видеть свои данные без независимо от того, где они находятся, но есть 1 с. Задержка слева и справа, для большинства бизнес-сценариев эта задержка может быть допустима. Конечно, есть некоторые бизнес-сценарии, которые не могут принять эту задержку в 1 с. Мы также предлагаем другое решение для решения этой проблемы. См. главу о Globa Zone ниже.
3. Почему бы не упростить и разделить по ID пользователя?
Али делит единицы в соответствии с модулем идентификатора пользователя, который относительно прост. Если мы также используем идентификатор для сегментации, пользователей, продавцов и гонщиков в том же месте можно разделить на разные эзоны, и в компьютерных комнатах будет больше звонков, что с большей вероятностью вызывает задержки, и трудно обеспечить реальное Производительность времени. Поэтому наша местная модель дистрибутива определяет необходимость разделить услуги по географическому местоположению.
Маршрутизация трафика:
На основе правил географического разделения мы разработали унифицированный уровень маршрутизации трафика (API Router), который отвечает за маршрутизацию вызовов API от клиентов и направление трафика в правильную зону. API-маршрутизатор развертывается в нескольких компьютерных залах общедоступного облака, и пользователи могут получить доступ к API-маршрутизатору общедоступного облака поблизости, что также может улучшить качество доступа.
Внешнее приложение было переработано, и каждый запрос имеет метку шунтирования.API-маршрутизатор проверит метку шунтирования в трафике, преобразует метку шунтирования в соответствующий идентификатор сегмента, а затем запросит eZone, соответствующий идентификатору сегмента. В какую зону направлять трафик.
Самый простой тег сортировки — это географическое местоположение. Благодаря географическому местоположению AR может вычислить правильную атрибуцию сегмента. Но бизнес очень сложный, и не все звонки могут быть напрямую связаны с определенным географическим местоположением.Мы используем многоуровневую схему маршрутизации.Основной логикой маршрутизации является географическое местоположение, но он также поддерживает некоторые другие ключи разделения высокого уровня, эти ключи разделения преобразуются APIRouter в основные Sharding Keys, как показано на рисунке ниже. Это не только снижает нагрузку на трансформацию бизнеса, но и расширяет возможности методов разделения.
В дополнение к маршрутизации на входе мы также разработали SOA Proxy, который используется для маршрутизации вызовов SOA и основан на тех же правилах маршрутизации, что и API Router. APIRouter и SOAProxy составляют канал маршрутизации трафика, позволяя нам гибко управлять направлением различных вызовов в мультиактивной среде.
Репликация данных:
Чтобы реализовать принцип приоритета доступности, все компьютерные залы будут иметь полные данные, чтобы пользователи могли переключаться в другие компьютерные залы в любое время, и полные данные необходимо реплицировать в режиме реального времени.Мы разработали соответствующее промежуточное программное обеспечение для mysql, zookeeper, очередь сообщений и данные перерисовки копируются.
Инструмент репликации данных Mysql DRC:
Mysql имеет самый большой объем данных. Данные, сгенерированные в каждой компьютерной комнате, копируются в другие ezone через DRC. Пространство значений первичного ключа каждой ezone — это ezoneid + фиксированный размер шага, поэтому сгенерированные идентификаторы различаются. Возникает конфликт первичных ключей. . Согласно правилам раздела, при нормальных обстоятельствах каждая эзона будет записывать только свои собственные данные, но в случае исключения, если две эзоны обновят одни и те же данные одновременно, возникнет конфликт. DRC поддерживает разрешение конфликтов на основе временных меток.Когда часть данных изменяется в двух компьютерных залах одновременно, последние измененные данные будут сохранены, а старые данные будут перезаписаны.
Репликация ZooKeeper:
Некоторая глобальная информация о конфигурации должна быть полностью согласованной во всех компьютерных залах.Мы разработали инструмент репликации zookeeper для синхронизации информации ZK в нескольких компьютерных залах.
Очередь сообщений и репликация Redis:
Репликация MQ и Redis аналогична репликации ZK, также были разработаны соответствующие инструменты репликации.
Сильная гарантия согласованности:
Для приложений с высокими требованиями к индивидуальной согласованности мы предлагаем решение с сильной согласованностью (глобальная зона).Глобальная зона – это механизм разделения чтения и записи в компьютерных залах.Все операции записи направляются в главный компьютерный зал для обеспечения согласованности операций чтения. может быть выполнено в подчиненной библиотеке каждого компьютерного зала или может быть привязано к главному компьютерному залу.Все это делается на основе нашего уровня доступа к базе данных (DAL), и бизнес в основном не знает.
Процесс переключения и различные защиты от исключений:
Очень важно избегать ошибок данных, так как в процессе отключения или переключения сети особенно велика вероятность генерации ошибочных данных. Например, из-за задержки репликации статус заказа несовместим, и пользователь может совершать повторные платежи. Во избежание этого мы предприняли некоторые меры предосторожности, чтобы избежать ошибок при переключении.
- Когда сеть прерывается, если в этом нет необходимости, не переключайтесь, потому что любой отдельный компьютерный зал может предоставить полные услуги.
- Если требуется переключение, порядок в процессе блокировки переключения не будет разблокирован до тех пор, пока переключение не будет завершено и репликация данных не будет нормальной. Этот процесс также реализуется через DAL
- Для данных записи, помеченных как другие компьютерные комнаты, DAL защитит их и откажется от записи.
- DRC проверяет наличие ошибок записи и сообщает о них, что упрощает поиск скрытых проблем.
Благодаря защите вышеуказанных 4 элементов мы обеспечиваем правильность данных, а частое переключение не приведет к ненормальным бизнес-данным.
Обновление кэша нескольких компьютерных залов:
Информация об изменении данных передается в несколько компьютерных залов через DRC для обновления кэша и обеспечения согласованности кэша каждого компьютерного зала.
весь кадр
Вышеизложенное представило различные аспекты рассмотрения.Теперь мы можем рассмотреть его всесторонне.Общая структура голода выглядит следующим образом:
Трансформация бизнеса:
Осведомленность о бизнесе является основным принципом.Благодаря услугам, предоставляемым промежуточным программным обеспечением, бизнес-стороне будет доступна многоактивная логика, такая как зона, к которой принадлежит текущая служба, стратегия маршрутизации, фрагмент данных и т. д. На основе этой информации бизнес может выполнять множество логических операций. включать:
- Фоновые задачи могут отфильтровывать нелокальные данные ezone.
- Когда происходит переключение, может выполняться определенная логика для запуска определенных действий.
- Бизнесу необходимо подготовить некоторую логику восстановления данных, чтобы в случае несоответствия вручную или автоматически исправить данные.
Реализация: Мультиактивное базовое промежуточное ПО
Ниже приводится краткое введение в промежуточное программное обеспечение, которое поддерживает вышеуказанные функции.Мы суммируем их в 5 основных компонентов, а затем будет серия статей, посвященных конкретной реализации каждого базового компонента.
APIRouter: служба распределения маршрутов
API Router — это обратный HTTP-прокси и балансировщик нагрузки.Он развертывается в общедоступном облаке в качестве точки входа для трафика HTTP API.Он может идентифицировать шард, к которому принадлежит трафик, и перенаправлять трафик в соответствующую зону в соответствии с сегментом. . API Router поддерживает различные ключи маршрутизации, которые могут быть географическими местоположениями, идентификаторами продавцов, идентификаторами заказов и т. д., которые в конечном итоге сопоставляются с единым идентификатором Sharding с помощью API Router.
Служба глобальной зоны: глобальный координатор состояния
GZS поддерживает всю активную таблицу маршрутизации, и все другие службы подписываются на информацию о маршрутизации от GZS. Операция переключения аппаратной также выполняется в пульте ГЗС. Таблица маршрутизации включает в себя: информацию о геозоне, информацию об атрибуции от сегмента к ezone, а также сопоставление уровней логики маршрутизации, таких как идентификатор магазина/идентификатор заказа с идентификатором сегмента и т. д. GZS устанавливает кэш на стороне SDK, чтобы гарантировать, что логика сегмента может выполняться с максимальной скоростью и, по сути, не требует взаимодействия с GZS. службы могут быть быстро уведомлены после изменения данных.
Прокси-сервер SOA: внутренний шлюз
Прокси-сервер SOA реализует маршрутизацию вызовов SOA и выполняет логику, аналогичную маршрутизатору API, но только для связи между компьютерными комнатами. Предприятиям, использующим SOA Proxy, требуется внести некоторые изменения в код, чтобы добавить информацию о маршрутизации в контекст вызова.
Центр репликации данных: репликация данных
DRC отвечает за двунаправленную репликацию данных Mysql в реальном времени, гарантируя, что задержка между машинным помещением не превышает 1 с. Обеспечивает разрешение конфликтов на основе времени для обеспечения согласованности данных в компьютерных залах. В дополнение к копированию данных DRC также предоставляет уведомления об изменениях данных во внешний мир, чтобы предприятия могли воспринимать изменения данных в других компьютерных залах и выполнять соответствующую обработку, например очистку кэша. В дополнение к DRC у нас также есть инструменты репликации ZK, инструменты репликации RMQ и инструменты репликации Redis, По сути, каждый уровень данных имеет соответствующую схему репликации.
Уровень доступа к данным: доступ к данным
Уровень доступа к данным поддерживает логику Globa Zone, а также обеспечивает последнюю защиту, отказываясь от неправильного маршрута записи данных, что является нижней поддержкой мультиактивности.
Будущее: планы на дальнейшую жизнь
В настоящее время услуги Ele.me развернуты в удаленных компьютерных залах 2. На следующем этапе мы расширимся до 3-4 компьютерных залов и создадим новую зону в общедоступном облаке, чтобы в полной мере использовать мощные возможности расширения общедоступное облако.В будущем мы сможем быстро построить центры обработки данных по всему миру и быстро использовать различные общедоступные облачные инфраструктуры для достижения высокой доступности и масштабируемости в глобальном масштабе.
Цитируется:
Latency numbers every programmer should know
об авторе:
Ли Шуантао, старший архитектор отдела Ele.me Framework Tools, участвовал в разработке и реализации Ele.me. За свою карьеру я дважды участвовал в этой крупномасштабной трансформации всего сайта, один раз в Cisco Webex и один раз в Ele.me, и накопил ценный опыт.