Автор: Free Fish Technology - Bridge Mud
1. Предыстория проекта
Автор получил уведомление о наличии централизованного проекта, который необходимо перенести для сборки отделом. Проект представляет собой платформу публикации микросервисов, включающую Xianyu, Taobao, Alipay, Tmall и многие другие отделы, все из которых развернуты на этой платформе. Из-за неудобства эксплуатации, обслуживания и использования из-за централизованного метода развертывания, чтобы избежать рисков безопасности и избежать сбоев, вызванных взаимодействием нескольких сервисов во время Double Eleven, сторона платформы информирует каждую бизнес-сторону о необходимости построения микросервиса. платформа сама по себе.
Время выполнения этого проекта является срочным, и в общей сложности он займет 16 рабочих дней до крайнего срока, что составляет около трех недель. Из-за разбора предыстории проекта, базового чтения кода и понимания документов по миграции основные проблемы заключаются в следующем:
- Код проекта сложен, существует много зависимостей промежуточного ПО, а процесс проекта длительный.
- Для переноса данных в проекте есть и mysql и nosql.Это необходимо для того, чтобы данные были непротиворечивы и не могли повлиять на старый бизнес.
- Функциональная проверка сложна.В дополнение к базовой бизнес-логике также необходимо проверить функцию промежуточного программного обеспечения, и существует несколько способов взаимодействия приложений.
- Для обеспечения стабильности новые и старые проекты должны быть полностью изолированы и не могут влиять друг на друга.
Я думаю, что все сталкивались с подобными проблемами в той или иной степени в процессе миграции проектов, далее давайте рассмотрим реальные случаи обработки, автор быстро и безопасно преодолевает эти трудности.
2. Преодолевайте трудности
Для удобства читателей приводим краткое введение в функции переносимого проекта.
Ниже, в сочетании с конкретными трудностями, давайте рассмотрим детали миграции.
2.1 Код сложного проекта
Мигрируемый проект должен быть старым проектом с огромным объемом, сложной логикой и плохим запахом кода. Столкнувшись с таким проектом, как нам быстро завершить запуск нового проекта и сделать первый шаг Великого похода?
Во-первых, самый быстрый способ написать код - это вставить чужой код (а такого нет), давайте напрямую клонируем старую кодовую базу,git remote set-url origin {new repo}Укажите на новый репозиторий кода.
Далее, конфигурации, методы развертывания и даже работающие серверы новых и старых проектов должны быть разными. Ну, некоторые основные замены должны быть сделаны:
- Замена имени проекта, старое имя проекта заменяется глобально
- Замена конфигурации (код/промежуточное ПО), подать заявку на новое промежуточное ПО, заменить в файле конфигурации
- Замена доменного имени, в консоли есть интерфейсная страница, и нужно настроить соответствующее доменное имя
- Имя пакета кода заменено. Чтобы полностью отличаться от старой службы, новая служба должна предоставлять новый пакет jar/war.
- Замена Dockerfile, элемент запуска dockerfile будет содержать информацию, связанную с проектом, и его необходимо заменять единообразно.
Наконец, проведите этот этап приемки:
- Службу можно запустить локально
- Локальная упакованная версия верна
При выполнении ряда операций по замене нам не требуется глубокое понимание старого проекта для успешного выполнения. Этот процесс обязательно столкнется со многими неудачами при запуске, и мы также можем извлечь уроки из ошибок и понять необходимые условия для запуска проекта. Этот процесс начинается 9.23 и заканчивается 9.27, всего 4 рабочих дня.
2.2 Миграция данных
В процессе миграции проекта миграция данных является неизбежной и важной частью. Суть сервисов заключается в притоке и оттоке данных, а миграция сервисов должна включать миграцию потоков данных.
Вообще говоря, службы будут полагаться на mysql для постоянного хранения сложных данных и nosql для кэширования или хранения других простых структур. Постоянное хранилище должно быть перенесено; кэши с коротким сроком действия, как правило, не нужно переносить, поскольку срок их действия истекает автоматически; другие простые структуры, хранящиеся в nosql, также необходимо переносить.
После проведенного выше анализа для решения проблемы обеспечения согласованности данных при миграции данных автор провел следующую обработку:
В процессе миграции необходимо учитывать несколько моментов:
- Новая и старая базы данных проекта полностью различаются. Избегайте записи грязных данных
- Согласованность структуры библиотечных таблиц. Избегайте проблем после выхода в эфир
- Регулярно проверяйте согласованность данных, чтобы избежать влияния на бизнес, вызванного асинхронностью данных.
Благодаря простой сортировке зависимостей и использованию инструментов миграции рабочие затраты и операционные риски могут быть сведены к минимуму, а задачи могут выполняться быстро. Автор, наконец, обработал его в течение 2 рабочих дней.
2.3 Функциональная проверка
Проект децентрализации на этот раз представляет собой микросервисную платформу, которая включает в себя много промежуточного программного обеспечения и взаимодействия с другими сервисами Процесс проверки очень долгий. Если вы не планируете регрессионное тестирование, сложно обеспечить полную доступность функций, а также это принесет риски безопасности при последующем использовании. Чтобы успешно пройти комплексную функциональную проверку, в начале принятия проекта мы должны иметь четкое представление о различных процессах проекта, заранее перечислить контрольные точки и иметь оценку возможных рисков и проблем. Если взять этот проект миграции в качестве примера, основными бизнес-контрольными точками являются:
- Заявка на разрешение входа
2. Отображение списка микросервисов
3. Создание микросервиса
4. Релиз микросервиса
Технические контрольно-пропускные пункты включают в себя:
- Чтение и запись базы данных
- очередь сообщений, публикация/потребление
- Другое использование промежуточного программного обеспечения
- конфигурация сети
Выше автор разобрал бизнес/технические контрольные точки проекта. После успешного запуска проекта, как правило, необходимо пройти тестирование - предварительный выпуск - производство и проверку трех сред.После успешного развертывания каждой среды необходимо проверить указанные выше контрольные точки.
В качестве примера возьмем проверку миграции очереди сообщений:
Во время этого процесса автор также столкнулся с некоторыми проблемами, такими как ситуация, когда потребление было успешным, но микросервисы не могли быть обновлены полностью, потому что сообщение не было передано и отправлено. Может быть множество причин, по которым очередь сообщений не может быть нормально открыта.Производство, путь сообщения и потребление должны быть тщательно проверены.
Подводя итог, в бизнесе мы наблюдаем, нормально ли работает бизнес-процесс, технически мы проверяем техническими средствами:
- Наблюдайте за сервисными журналами, журналами промежуточного программного обеспечения
- Инструмент отладки наблюдает за выполнением кода.Для java-разработки можно использовать инструмент arthas, удаленную отладку идеи и т.д.
- Проверка чтения и записи данных базы данных, проверка отправки и получения сообщений из очереди сообщений и т. д.
В процессе функциональной верификации мы неизбежно сталкиваемся с различными проблемами: имеем психологические ожидания, назначаем правильное лекарство и быстро решаем проблему, что может эффективно повысить эффективность работы и ускорить процесс миграции. Вышеупомянутый процесс начинается с 29 сентября и заканчивается 13 октября, через 4 рабочих дня.
2.4 Гарантия стабильности
После переноса и запуска нового проекта остается очень важное звено: обеспечение стабильности. Как обеспечить стабильность сервиса новых проектов? Как сделать так, чтобы использование функций новых проектов не повлияло на старые проекты? Как завершить передачу и замену новых и старых проектов? Именно эти вопросы мы обсудим далее.
Прежде всего, мы должны сначала обеспечить стабильность нового проекта, Вообще говоря, необходимо настроить мониторинг самого приложения, включая, но не ограничиваясь:
- Мониторинг производительности сервера
- JVM-мониторинг
- Мониторинг сервисного интерфейса
- Мониторинг промежуточного программного обеспечения службы
Затем подтвердите изоляцию нового и старого проектов, вообще говоря, достаточно полностью изолировать базу данных, очередь сообщений и другие промежуточные зависимости нового и старого проектов, а также полностью изолировать сервер развертывания.
Далее необходимо определить план замены для передачи новых и старых проектов, В общем случае процесс выглядит следующим образом:Несколько замечаний:
- После того, как время доставки будет подтверждено в бизнесе, необходимо обеспечить одновременную доступность нового и старого проектов.
- При возникновении проблемы старый проект можно использовать в качестве резервной копии для выполнения бизнес-функции. Разобравшись с проблемами нового проекта, продолжайте резать поток.
- После того, как весь проект будет переведен в оперативный режим, требуется период непрерывного наблюдения, чтобы убедиться, что в течение периода наблюдения не возникнет непредвиденных проблем, прежде чем миграция может быть официально завершена.
3. Резюме
Платформа микросервисов, которую перенес автор, наблюдалась в течение двух недель после того, как она была запущена в сеть, и было выпущено несколько микросервисов. Подтвердите, что приложение полностью децентрализовано, бизнес-функции работают нормально, а сервис работает стабильно.
Полный рабочий процесс миграции выглядит следующим образом:Изучив весь процесс, от развертывания проекта до запуска проекта, функциональной проверки и окончательного стабильного наблюдения, автор столкнулся с различными проблемами.Однако с помощью продуманного плана миграции, достаточной подготовки и с помощью многих студенты, миграция по-прежнему была завершена в течение десяти рабочих дней. Оглядываясь назад, можно выделить три основных момента:
- Разделяйте сложные проблемы и преодолевайте одну за другой
- Хорошо продуманный план снижения рисков
- Полностью понять проект для обеспечения бизнеса
Миграция полна угроз безопасности. Мы должны смело идти навстречу рискам, терпеть риски и предлагать комплексные решения. Я надеюсь, что опыт миграции, представленный в этой статье, может помочь читателям и сделать миграцию более безопасной и эффективной.