Общее решение eBay по автоматизации для развития платформы

Для любого крупного онлайн-бизнеса платформа является основополагающей частью. Платформа eBay содержит программные фреймворки и инфраструктуру в своей серверной части. Поскольку платформа очень важна, обновления необходимы для поддержания стабильности и надежности приложений, включая основные операции, такие как поиск и оплата. На eBay имеется более 3000 приложений, которые обслуживают онлайн-бизнес. Они относятся к разным областям, включая платежи, продажи, маркетинговые технологии и многое другое. Чтобы эти приложения работали эффективно, платформа требует постоянных, согласованных обновлений, включая обновление инфраструктуры и инфраструктуры.

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

Платформа

В целом платформа состоит из двух частей. Первая — это структура, на которой основан код приложения; эта структура предоставляет все основные функции, такие как создание контекста запроса, предоставление метрик, предоставление общих библиотек и т. д. Во-вторых, это инфраструктура, в которой размещается приложение. На eBay это облачная система.

Эволюция платформы требует обновления обеих частей; нам нужно обновить инфраструктуру и создать новую инфраструктуру. Такие задачи подвержены ошибкам и требуют много ручного труда для обеспечения высокой стабильности и доступности.

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

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

Случаи использования

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

Все эти обновления, каждое из которых инициирует отдельную программу, сгруппированы в категорию эволюции платформы. На eBay они почти непрерывны из-за размера и сложности рынка. С другой стороны, обновление версии фреймворка происходит ежемесячно. Давайте рассмотрим некоторые типичные варианты использования.

Обновление фреймворка

Этот пример включает в себя обновление фреймворка, например, обновление фреймворка с версии a до версии b. Чтобы применить новую версию ко всем приложениям, использующим эту платформу, необходим конвейер автоматизации для каждого приложения, чтобы обновлять код до последней версии платформы, создавать его, тестировать и выпускать без проблем. Такой конвейер будет содержать три потока:

Миграция фреймворка

Типичная программа — перенос устаревшей платформы на современную. При миграции приложения, работающие на устаревшей платформе, должны быть плавно перемещены на новую платформу. Для процесса миграции требуются следующие потоки:

• Собрать коллекцию метаданных

• Настройка новых приложений и соответствующих пулов

• Перенести трафик

• Продолжайте отслеживать после миграции.

• Выведите из эксплуатации пулы, в которых размещается устаревшая платформа.

Миграция в облако

В этом примере eBay перемещает облачную инфраструктуру с openstratus на основе виртуальных машин на Kubernetes на основе контейнеров. Чтобы охватить новую облачную инфраструктуру, жизненный цикл разработки приложений также будет изменен; мы заменим манифест на основе библиотеки на манифест на основе образа, пул на основе виртуальных машин на пул на основе модулей, а баланс нагрузки оборудования — на новый баланс нагрузки программного обеспечения. Для осуществления миграции со старой облачной системы на новую необходимы следующие потоки:

Решение

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

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

• Общие задачи должны быть доступны для совместного использования

• Каждый рабочий процесс должен содержать несколько задач

• Каждая задача должна взаимодействовать с экосистемой для обработки действий

• Рабочий процесс и задачи должны легко управляться и организовываться

Архитектура

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

В этой архитектуре есть две основные части:

• Orchestrator: он разрешает соответствующий поток с предопределенными задачами на основе входных данных. Каждый поток можно разделить на более мелкие задачи, которые могут выполняться последовательно в соответствии с конфигурацией. Например, Orchestrator может разрешить один конкретный поток для поддержки миграции приложений-служб, а другой поток также может разрешить пакетную миграцию приложений. После этого оркестратор запускает каждую задачу, определенную в потоке, по очереди, регистрирует состояние выполнения задачи и обрабатывает исключение до тех пор, пока все задачи в потоке не будут выполнены. Перед оркестратором находится сервисный уровень, предоставляющий API для вызова оркестратора.

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

Выполнение потока

Для различных стеков приложений (обмен сообщениями, пакетная обработка, служба, Интернет) оценка платформы требует определенного потока с различными определениями задач. Например, миграция трафика приложения-службы — это не то же самое, что пакетное приложение (миграция запросов на основе HTTP и миграция пакетных заданий). Поток определяется как файлы yaml с классом задач.

Контекст задачи

Для запуска потока контекст задачи сохраняется оркестратором и восстанавливается перед запуском следующей задачи. Используя этот метод, каждой задаче можно передать необходимые параметры для независимого запуска. Еще одно преимущество: каждую задачу можно повторить на основе контекста, сохраненного при предыдущем запуске.

Оркестратор

Оркестратор будет последовательно обрабатывать задачу. Внутри оркестратора есть несколько компонентов:

1. Поток и задачи определяются как файлы yaml.

2. Диспетчер потоков обрабатывает основную логику.

3. Платформа > с открытым исходным кодом отвечает за запуск задач.

4. Mysql используется для сохранения потока, статуса задачи и контекста.

Кварц в качестве механизма задач выбран для выполнения задач в оркестраторе. Почему мы сделали этот выбор? Хорошо:

• > — это распределенная система, которая может максимально использовать вычислительные ресурсы;

• > может сохранять статус задания и поддерживает приостановку и возобновление задания;

• В > есть прослушиватель заданий, который отделяет задания > и отправляет действие.

Вот рабочий механизм внутри оркестратора.

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

Когда диспетчер потока получает запрос на обработку потока, следующие шаги показывают, как запускать задачи, определенные в потоке.

1. Сохраните поток в БД для этого запроса.

2. Запустите первую задачу потока с помощью механизма заданий >.

3. Кварцевый двигатель найдет поле для запуска Task1.

4. Как только Task1 будет выполнен, он вызовет прослушиватель заданий > в качестве обратного вызова.

5. Прослушиватель заданий сохранит полную задачу с контекстом и найдет следующую задачу для сохраненного потока.

6. Если у него есть следующая задача (Task2), прослушиватель задач вызывает диспетчер потока для отправки Task2.

7. Диспетчер потока отправляет Task2 в > Job Engine.

8. > Job Engine запускает Task2.

9. Повторяйте процесс до конца.

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

Краткое содержание

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

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

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

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