Автор: Xianyu Technology - Девяносто семь
1. Предпосылки
idlecenter — ветеранское приложение сервера Xianyu.Idlecenter написал первую строку кода в июне 2013 года, а затем сопровождал Xianyu в течение 8 лет.
С постоянным расширением масштабов бизнеса Xianyu и ростом сложности бизнеса idlecenter постепенно выявил некоторые проблемы:
• Вертикальное разделение бизнес-границ и многоуровневость архитектуры приложения неясны.Бизнес-коды в разных областях повторяются на холостом центре, и бизнес-коды тесно связаны.Новый бизнес постоянно накладывается, старый бизнес не может быть очищен вовремя, а масштаб приложений постоянно расширяется.
Немедленные эффекты:
• Низкая эффективность НИОКР: десятки групп НИОКР в нескольких командах совместно обслуживают сотни предприятий, и каждый выпуск будет иметь более дюжины ответвлений, и каждое дополнительное ответвление столкнется с риском конфликтов кода. По статистике, на выпуск, сборку и развертывание приложения уходит полчаса, а на разрешение конфликтов веток уходит 20 минут, что серьезно влияет на эффективность разработки.
Долгосрочное воздействие:
• Стабильность: бизнес не может быть изолирован, основной и неосновной бизнес находятся в одном приложении и мешают друг другу, а стабильность не может быть гарантирована. Например, если непрофильный бизнес заполняет пул ресурсов, основная служба не сможет предоставлять услуги, что приведет к онлайн-сбоям • Конфликт по вертикали бизнеса: Xianyu также изменит свою кадровую и организационную структуру во время быстрого развития своего бизнеса. масштаб бизнеса. Хотя idlecenter представляет собой единое приложение, архитектура приложения и структура персонала различаются. В результате разрешения не могут быть закрыты, а спецификации не могут быть согласованы. При непрерывной итерации нерегулируемого бизнес-кода стоимость обслуживания приложения увеличивается в геометрической прогрессии.
Чтобы решить различные проблемы с idlecenter, в июле мы начали разделять и мигрировать idlecenter. На данный момент общий прогресс миграции нашего холостого центра составляет более половины, трудозатраты составляют менее 20 дней, а миграция не имеет сбоев.
Эта статья ускоряет наше мышление и практический опыт этой миграции, надеясь предоставить некоторые идеи для студентов, которые занимаются миграцией приложений.
Общая миграция делится на две части:
•
Миграция кода во время разработки
•
Миграция трафика во время выполнения
2. Миграция кода
В ссылке на миграцию кода в период разработки нам нужно подумать над следующими вопросами:
• Какой код следует перенести? • Как двигаться?
Здесь мы описываем универсальные принципы миграции кода:
• Уточнить границы миграции, которые состоят из двух частей: ограничений схемы миграции и степени детализации миграции.
• Уточните ограничения плана миграции и уточните службы, поддерживающие и не поддерживающие миграцию. Например, в этом процессе миграции мы уточнили требования к версии платформы RPC службы потребителя и пояснили, что миграция сообщений не поддерживается. При разборе сервисов миграции нам нужно изначально определить и выбрать сервисы за границей.В процессе миграции кода мы также должны обратить внимание на то, есть ли какие-то отсутствующие сервисы, которые не исключены. • Укажите степень детализации миграции.После исправления степени детализации приложение можно разобрать по вертикали, а границы приложения после разделения можно разумно спланировать. Например, в нашем решении миграция явно основана на RPC-сервисах.При разборе миграции каждый модуль миграции представляет собой вертикальный RPC-сервис.Атрибуция каждого RPC-сервиса понятна.Начиная с RPC-сервиса, для вывода решения который решает миграцию всех сервисов RPC по горизонтали.
• Сосредоточьтесь на самом разделении Процесс миграции поддерживает согласованность старого и нового кода приложения. Он должен:
• Отсутствие рефакторинга кода. Процесс переноса кода также является процессом проверки кода. В середине может быть обнаружено, что ранее написанный код не является элегантным или лаконичным или имеет недостатки в дизайне. В это время мы должны поддерживать согласованность код. Код, работающий в сети, часто проходит контрольные примеры QA и регрессионную проверку, чтобы гарантировать, что риск сходится в контролируемом диапазоне. Каждая строка кода, измененная в процессе миграции, может стать «миной», которая ускользает от тестовых случаев и регрессионной проверки. • Не перевозит личные вещи. Это немного пересекается с отказом от рефакторинга кода, т. е. процесс миграции кода должен быть чистым, а в процессе миграции кода нельзя внедрять дополнительную бизнес-логику и заниматься «расширением функций».
• Чтобы выполнить перенос без ошибок, перенос кода включает не только код внутри приложения, но также необходимо обратить внимание на конфигурацию и логику, связанные с приложением вне приложения:
• Конфигурация, связанная с промежуточным программным обеспечением: например, конфигурация инфраструктуры RPC в приложении, конфигурация промежуточного программного обеспечения базы данных, конфигурация коммутатора, конфигурация центра конфигурации и т. д. должны обращать внимание на то, привязаны ли они к приложению, и соответствующая конфигурация должна быть перенесена. Конфигурация, связанная с Тайванем: например, Xianyu может полагаться на ключевые слова для фильтрации среднего конца, а в процессе миграции кода также необходимо перенести конфигурацию, связанную с средним концом, и настроить разрешения среднего конца для новое приложение.
3. Миграция трафика
В ссылке миграции трафика во время выполнения мы в основном рассматриваем две проблемы:
• Стоимость миграции. Зависимости служб в idlecenter топологически сложны. Содействие миграции службы может включать несколько вышестоящих потребительских служб, требует сотрудничества нескольких команд и требует очень больших временных и трудовых затрат. Как снизить стоимость миграции. • Стабильность: Миграция трафика означает смену двигателей во время движения по трассе, поэтому нам необходимо обеспечить стабильность процесса миграции трафика.
3.1. План миграции
Слишком высокие затраты на миграцию добавят большое сопротивление продвижению проекта миграции, поэтому на этапе исследования плана вам необходимо обратить внимание на стоимость миграции. На этапе исследования программы мы определили цели:
• Поток процесса миграции является контролируемым и имеет возможность нарезать поток в оттенках серого, что является основой стабильности потока миграции • Миграция не требует модификации кода потребителя услуги. Стоимость трансформации минимальна, процесс миграции может быть прозрачным для потребителя услуги, а плавная миграция может быть выполнена без ведома потребителя услуги.
Наконец, мы разработали схему трансляции на основе функции маршрутизации HSF.
Полное название HSF — High-Speed Service Framework, представляющее собой RPC-фреймворк внутри группы. Прямым целевым продуктом является Dubbo. Общий механизм работы выглядит следующим образом:
Цитата из документации hsf-guide
Основные задействованные компоненты:
• Центр реестра: используется для обнаружения регистрации службы • Центр правил: вы можете настраивать и продвигать правила управления службой. Разработчики приложений могут редактировать и сохранять правила в консоли, а ПО промежуточного слоя центра правил будет отправлено на все указанные серверы.
Наша схема повторно использует возможности правила маршрутизации вызова службы в структуре HSF. Правила маршрутизации используются для вмешательства в логику выбора адреса потребителя услуг для завершения миграции трафика поставщика услуг.
На основе схемы релокации HSF мы добились:
• Нулевая стоимость трансформации для потребителей услуг. • Процесс миграции прозрачен для потребителей услуг.
Конечным результатом трудозатрат является то, что затраты на миграцию сведены к минимуму, и один человек может выполнить миграцию и запуск службы за неделю.
После решения проблемы стоимости миграции нам нужно решить самую важную проблему миграции: гарантия стабильности.
3.2 Стабильность конструкции
Что касается стабильности процесса миграции потока, наша идея состоит в том, чтобы повторно использовать методологию безопасного производства, накопленную внутри группы, — три оси безопасного производства: оттенки серого, наблюдаемое и откат. Создайте систему стабильности вокруг трех осей безопасного производства.
Оттенки серого на самом деле предназначены для проверки возможности оттенков серого схемы перемещения HSF, чтобы гарантировать, что распределение потока приложения может соответствовать ожиданиям в процессе перемещения. Вопросы, которые нам необходимо рассмотреть, следующие:
• Возможность оттенков серого: имеет ли решение миграции HSF возможность использования оттенков серого • Проверка перекоса трафика: будут ли правила маршрутизации HSF вызывать перекос трафика. Трафик между логическими машинными залами и равномерность распределения трафика машин в логическом компьютерном зале. • Проверка влияния RT: Насколько сильно влияние RT вызвано дополнительной маршрутизацией и выбором адреса правил маршрутизации HSF, и находится ли оно в допустимых пределах • Неразрушающая проверка отсечки трафика: В процессе корректировки оттенков серого вес, может ли это быть плавным, и не приведет ли к потере трафика
Во-вторых, нам нужно проверить возможность отката схемы трансляции HSF:
• Возможность отката: имеет ли план миграции HSF возможность отката. • Фактическое время отката: эффективное время отката плана миграции HSF.
В ответ на вышеуказанные пункты, которые необходимо проверить, мы провели проверку схемы POC в тестовой среде и подготовили технико-экономическое обоснование схемы перемещения HSF. Кратко о результатах проверки:
•Решение имеет возможности оттенков серого и возможность отката •Влияние RT находится в пределах 3 мс, что незначительно •В машинном зале трафик в компьютерном зале распределяется равномерно и не вызывает проблем с потерей трафика или перекосом трафика. время отката маршрута в пределах 1с
Возможности оттенков серого и отката решают проблему контролируемого воздействия в процессе выпуска. А наблюдаемость — это последняя преграда к нашей гарантии стабильности. То, является ли наблюдаемость точной и дотошной, определяет, сможет ли наш процесс перевода в градациях серого пройти гладко.
В нашей практике построение наблюдаемости делится на две части:
• Начиная с мониторинга аварийных сигналов, нам необходимо в каждом конкретном случае разобраться в предыстории бизнеса и целенаправленно настроить мониторинговые аварийные сигналы.Например, для службы фильтрации конфиденциальных слов нам нужно не только обращать внимание на ее показатель успешных вызовов, но и к частоте попаданий чувствительных слов службы. В дополнение к мониторингу на бизнес-уровне мы также сотрудничаем с мониторингом на уровне ресурсов конфигурации, таких как распределение трафика, количество запросов в секунду, а также использование ЦП и памяти, чтобы получить общее представление о состоянии работоспособности службы.После выпуска новой службы и запущен, нам нужно вмешательство QA для выполнения регрессионной проверки сервиса. Что касается службы перевода, мы фокусируемся на согласованности логики кода, предоставляемой новой и старой службами. С этой целью мы подключились к регрессионной платформе Phoenix внутри группы. Phoenix может записывать онлайн-трафик и воспроизводить его на назначенном компьютере в градациях серого, что позволяет быстро проверить согласованность новой и старой логики службы приложений.
При построении системы стабильности мы, наконец, добились безошибочной миграции.
4. Наконец
Наконец, есть очень важный момент, чтобы хорошо выполнить миграцию приложений: хорошо выполнить контрольный список. Шаги миграции сформулированы заранее, чтобы сократить ритм изгнания и объема; каждый раз, когда объем увеличивается, область воздействия может быть оценена на порядок, и процесс может быть полностью отрепетирован в тестовой среде перед запуском в жизнь. Здесь я перечисляю шаблон контрольного списка для нашего процесса миграции:
• Подтверждение миграции
• Версия инфраструктуры RPC, другие правила, исключающие правила маршрутизации • Конфигурация промежуточного программного обеспечения, подтверждение переноса конфигурации промежуточного уровня • Подтверждение разрешения нового приложения
• Сценарии потребления потребительских услуг
•Сценарии потребления, уровень QPS
•Оценка ресурсов•Наблюдение за конфигурацией сигналов тревоги•Стратегия регрессии•План на случай непредвиденных обстоятельств•Процесс выпуска
• Время переключения, вес переключения • Влияние на объем запроса • Правила маршрутизации переключения