Автор: Xianyu Technology - Камбоджа Чао
задний план
В 2018 году мы внедрили на практике интегрированное в облако решение для исследований и разработок flutter+Dart Faas.Это решение использует Serverless, чтобы быть легким (ориентированным на бизнес), быстрым (единый интерфейс и единая функция, быстрая разработка и развертывание) и NoOps ( платформа эксплуатации и обслуживания) Это снижает порог исследований и разработок уровня сборки бизнеса на стороне сервера, так что студенты на стороне клиента также могут иметь возможность и возможность участвовать в развитии бизнеса на стороне сервера, уменьшая проблему клиент- эффективность совместной работы серверов и повысить итеративную эффективность новых предприятий. Однако в традиционной архитектуре приложений Xianyu также есть аналогичный слой бизнес-сборки, имя этого приложения — idleapi.Из-за нечеткого вертикального разделения бизнес-границ приложения и иерархического дизайна архитектуры почти все бизнесы повторяются на idleapi. Новые бизнесы продолжают накапливаться, старые бизнесы продолжают повторяться, а устаревшие бизнесы не могут быть своевременно очищены, что приводит к постоянному расширению масштаба приложений. Согласно статистике, по состоянию на Double Eleven в 2020 году Idleapi предоставил более 1200 шлюзовых интерфейсов, из которых более 500 не имеют бизнес-трафика (бизнес-офлайн), но код все еще работает и не был вовремя очищен. В результате в Idleapi есть в общей сложности 70+ строк кода, более 2000 бизнес-переключателей и сотни бизнес-модулей. Так много предприятий, кодов и разработок связаны с одним приложением, что вызывает ряд проблем с изоляцией:
Стабильность в сети:
Сотни бизнес-модулей работают в процессе приложения и мешают друг другу, что может легко привести к проблемам с изоляцией. Например, если есть проблема с бизнес-модулем (исчерпание памяти или переполнение пула потоков), другие бизнес-модули, развернутые на том же компьютере, не будут иметь доступных ресурсов, откажут в обслуживании и повлияют на основной бизнес, развернутый на том же компьютере. , вызвать сбой. Такие примеры каждый год.
Низкая эффективность НИОКР:
Десятки студентов R & D развиваются и поддерживают сотни бизнес-модулей. Каждый выпуск будет иметь более десятка филиалов. Каждый раз, когда добавляется бизнес-филиал, он столкнется с риском конфликтов кода. Чем больше разрыв между базовой версией филиала. И базовые версии других ветвей, тем больше конфликтов решены, тем дольше она берет. Согласно статистике, предварительное освобождение IDLEAPI занимает около 30 минут, из которых 20 минут ждут студентов развития для разрешения конфликтов, а эффективность развития низкая.
Деловой вертикальный конфликт:
Чтобы лучше развивать бизнес и сосредоточиться на бизнес-показателях, Xianyu реорганизовала структуру персонала в соответствии с бизнес-сферой, но структура приложения была слишком поздно для продолжения. Хотя одна и та же бизнес-группа может автономно координировать свои действия и эффективно взаимодействовать, когда все предприятия объединены в одно приложение, для межгруппового сотрудничества между предприятиями по-прежнему требуется много энергии.
Управление - Сплит
Структуры больших систем, как правило, разрушаются в процессе разработки, качественно больше, чем малых систем. Организации, разрабатывающие системы, вынуждены создавать проекты, которые являются копиями коммуникационных структур этих организаций. Согласно закону Конвея: большие системы всегда находятся в разработке. , он имеет тенденцию к декомпозиции и реорганизации для достижения определенного гомоморфизма архитектуры системы и структуры персонала. Чтобы решить различные проблемы с idleapi, мы решили разделить его. В процессе расщепления есть несколько моментов, которые необходимо четко продумать заранее:
1. Что является продуктом расщепления? Это традиционное монолитное приложение, разделенное по бизнес-доменам, или это функция FaaS, основанная на бизнес-интерфейсах? 2. Все ли бизнес-коды в процессе разделения переписываются или используются повторно? Как бороться с избыточным бизнес-кодом? 3. Как перенести конфигурацию, мониторинг и сигнализацию сервисов? 4. Как быстро проверить? 5. Как сгладить оттенки серого? Как откатиться? Как реагировать на новые требования в процессе миграции бизнеса? 6. Предусмотрены ли какие-либо меры для предотвращения повторного возникновения проблемы раздувания приложения/Faas после запуска приложения? Вышеупомянутые проблемы являются ключевыми моментами процесса разделения и определяют, может ли план разделения быть успешно реализован. Далее анализируем один за другим:
Традиционные приложения против функций FaaS
Первая направленная проблема, которую необходимо решить путем расщепления: каков целевой продукт расщепления? Есть примерно две идеи: 1. В соответствии с бизнес-сферой он делится на небольшие традиционные приложения и независимые исследования и разработки, развертывание, эксплуатацию и обслуживание 2. В соответствии с интерфейсом шлюза он делится на соответствующие функции FaaS. Согласно исследованиям и сравнениям за последние несколько лет: мы считаем, что FaaS очень подходит для решения проблем, с которыми сталкивается Idleapi.
Срок ввода в эксплуатацию
Прежде всего, в период отладки в традиционных приложениях несколько интерфейсов разрабатываются параллельно в одном приложении, и существует риск конфликтов слияния кода при выпуске разных кодов ветвей, а предварительная версия занимает около 30 минут. развертывание. В Faas интерфейс шлюза соответствует функции Faas, и каждая функция Faas имеет свой собственный независимый репозиторий git и среду развертывания. Faas не зависят друг от друга и физически изолированы.Разработчики могут с уверенностью модифицировать собственный код и базовую версию, а также могут инициировать удаленную отладку в любое время, не беспокоясь о том, что другие разработчики не смогут отладить ее. Более того, поскольку каждая функция FaaS фокусируется только на одном интерфейсе бизнес-шлюза, объем кода и зависимых сторонних сервисов функции FaaS намного меньше, чем у традиционных приложений. развертывание, которое почти в 10 раз быстрее, чем традиционные приложения.
время выполнения
Во время выполнения каждая функция FaaS выполняется в отдельном кластере.Эта естественная физическая изоляция не позволяет функции FaaS вызывать сбои изоляции. Если служба функции Faas исчерпывает пул потоков и выполняет запись на диск, это не повлияет на функции, развернутые в ее кластере (за исключением бизнес-ассоциаций).
Период кодирования:
Хотя функция Faas имеет преимущества в период отладки, период работы, а также период эксплуатации и обслуживания, традиционное монолитное приложение имеет преимущество в периоде кодирования, например: Возможность повторного использования кода: коды нескольких предприятий находятся на складе проекта, и базовые инструменты Классы, классы менеджеров и сервисы верхнего уровня могут вызываться напрямую, а повторное использование кода является простым и прямым; в то время как в режиме FaaS разные интерфейсы шлюза находятся в разных репозиториях кода, а повторное использование кода: копирование кода или общедоступный код для второй стороны требуется.В пакетах или службах домена это вызовет проблемы с обслуживанием кода. Обновление версии программного обеспечения: когда необходимо обновить Pandora или двухсторонний пакет: традиционным приложениям необходимо обновить только версию программного обеспечения, от которой зависит приложение, и повторный выпуск может решить проблему обновления. В режиме FaaS: если каждая функция должна быть изменена и выпущена студентами, изучающими бизнес-разработки, одна за другой, рабочая нагрузка повторяющейся работы будет в сотни раз выше, чем у традиционных приложений, что сильно влияет на эффективность разработки. Мы также пытаемся решить эту проблему с помощью некоторых платформенных инструментов или многоуровневых мер.
Разделить инструмент
После того, как план разделения будет определен, idleapi будет разделен из гигантского монолитного приложения на сотни функций FaaS с интерфейсами шлюза в качестве единицы. Повторно реализовать такое количество сервисов нереально, поэтому лучший способ — повторно использовать бизнес-код в монолитном приложении.Проанализировав код, мы обнаружили, что в idleapi коды каждого бизнеса ссылаются друг на друга, образуя сложную гигантскую сетевую структуру. Бизнес-интерфейс связан с кодами пяти или даже десяти других бизнес-интерфейсов, а количество задействованных исходных файлов составляет почти 1000, что составляет 1/4 от общего числа исходных файлов кода idleapi, что не достигает нашей цели. упрощение бизнес-кода вообще. В дополнение к записи бизнес-шлюза существуют различные другие неявные записи функций, такие как: сериализация json автоматически вызывает функцию set класса, функцию инициализации bean-компонента и т. д. Разделить бизнес-код вручную — большая проблема. С этой целью мы разработали и внедрили инструмент разделения кода, который может помочь предприятиям анализировать классы, методы и свойства, от которых зависят функции входа в бизнес в переплетенном коде, и исключать классы, методы и свойства, которые не вызываются. Этот инструмент может дополнительно сократить количество исходных файлов, от которых зависит одна бизнес-запись, примерно до 100 (70% из которых являются типами данных интерфейса). В сочетании с бизнес-платформой Faas, которую мы разработали и внедрили, когда студенты-бизнесмены мигрируют, они могут разделить бизнес-код, создать функции Faas и развернуть их в предварительной среде одним щелчком мыши Весь процесс занимает менее получаса. Для конфигурации бизнес-переключателя мы также предоставляем инструмент миграции, который может переносить онлайновые или предварительно выпущенные конфигурации в новые функции в пакетном режиме одним щелчком мыши, устраняя необходимость ручной миграции для проверки и утверждения копий одну за другой.
Автоматическое регрессионное тестирование
Тестирование — последний барьер для обеспечения качества разделенного бизнес-кода. Чтобы уменьшить дополнительную рабочую нагрузку, вызванную разделением приложений на бизнес-студентов и студентов-тестировщиков, мы сотрудничали с платформой Faas и платформой автоматизированного регрессионного тестирования, чтобы адаптировать функции регрессионного тестирования, такие как запись и воспроизведение, к архитектурам SideCar и Pod платформы Faas. . Разработчикам нужно только записывать онлайн-трафик в традиционных приложениях после выпуска функции FaaS, а затем импортировать трафик в функцию FaaS для тестирования для автоматического регрессионного тестирования. Подключившись к платформе автоматизированного тестирования, разработчики могут самостоятельно выполнять регрессионное бизнес-тестирование. Это снижает риск бизнес-миграции и тестовую нагрузку на тестируемых студентов, а также повышает эффективность миграции.
Эксплуатация и обслуживание
С точки зрения эксплуатации и обслуживания бизнеса FaaS, мы делаем все возможное, чтобы сохранить привычки разработчиков в эксплуатации и обслуживании: разделенная функция FaaS сохраняет имя журнала в одном приложении, формат организации журнала, кодировку и т. д. ., а также сохраняет за разработчиками удаленный логин возможностей машины. В то же время мы адаптируем персонализированные бизнес-журналы к функции журнала белого экрана платформы Faas.Разработчики могут просматривать и искать все журналы на любом компьютере через платформу управления и контроля, что намного эффективнее, чем вход в систему. машины для просмотра их один за другим. В то же время системе мониторинга и оповещения на основе журналов необходимо только обновить путь бизнес-журнала соответствующего мониторинга, чтобы завершить миграцию мониторинга.
Эволюция архитектуры
Для проблемы повторного использования бизнес-кода после того, как приложение разделено на мелкие функции Faas, есть примерно два решения: 1. Сначала управление, а затем разделение: сначала преобразование и рефакторинг отдельного приложения, перенос кода, повторно используемого каждым бизнесом (переход в общедоступный сторонний пакет или переход на сервисный уровень бизнес-поля), а затем переход к разделению одного приложения. в несколько функций Фааса. У этого решения есть две проблемы: 1. Зомби-код составляет только половину, что приведет к недопустимой рабочей нагрузке рефакторинга 2. Рефакторинг исходного приложения, а новая бизнес-итерация и рефакторинг AB смешиваются для разработки. рискованно. два. Управление после разделения: сначала разделите бизнес одного приложения, игнорируйте проблему повторного использования кода на данный момент и ждите разделения функций, некоторые бизнес-студенты будут выполнять преобразование повторного использования кода в соответствии с фактическими потребностями бизнеса в последующем развитии обработать. Код повторного использования в бизнесе либо независим от стороннего пакета для работы, либо встроен в службу домена. По сравнению с первым решением решение проблемы повторного использования между четко изолированными базами кода функций снизит сложность и риск. Поэтому мы выбрали второй вариант.
доход
В настоящее время более 30 интерфейсов шлюза были отделены от монолитных приложений и предоставлены для развития и обслуживания бизнеса, что еще раз подтверждает применимость этого решения для разделения и управления монолитными приложениями. В будущем мы предоставим раздельный план разработчикам, которые сами разделят миграционный бизнес. После разделения бизнес сохраняет первоначальные привычки развития и работы. В то же время правило, что один интерфейс бизнес-шлюза соответствует одной функции, заставляет функцию Faas фокусироваться только на одном интерфейсе бизнес-шлюза, что решает проблему постоянного расширения традиционных приложений в сценарии непрерывных бизнес-инноваций. Этот фокус также делает объем функционального кода менее чем на 3% по сравнению с традиционными приложениями (и большинство из них являются типами данных), а для бизнес-релиза (Java) требуется всего 5 минут.
Суммировать
В целом, с помощью автоматизированных инструментов разделения студенты-бизнесмены могут разделить бизнес-интерфейс одним щелчком мыши в течение получаса и предварительно развернуть его.Промежуточный процесс не требует ручного вмешательства, а функции разделения поддерживают исходную операцию разработки. , Привычки обслуживания, низкие затраты на миграцию и могут быть приняты бизнес-студентами. Кроме того, с помощью функций, ориентированных на бизнес, один интерфейс — это одна функция, и каждая функция не имеет помех от других служб в период разработки, с высокой тестируемостью и быстрой скоростью развертывания. В течение рабочего периода каждая функция выполняется на разных физических машинах.Эта естественная физическая изоляция значительно повышает стабильность рабочего периода и снижает затраты на эксплуатацию и обслуживание бизнеса.
Перспектива
В настоящее время функциональная платформа Faas все еще быстро развивается, и все еще есть некоторые области для улучшения: Стоимость машины и функция малого потока Высокая стоимость машины: в соответствии с высокими требованиями безопасности производства группы, даже для функций небольшого потока, два набора требуется каждое машинное помещение Машины расточительны, и платформа рассматривает различные меры по улучшению использования машин за счет снижения спецификаций машин и перепродажи. Эластичность: когда восходящие и нисходящие каналы службы относительно длинные, эластичность одной точки не может решить все проблемы, которые необходимо рассматривать и решать комплексно. Стоимость обслуживания Унифицированное обновление: при выпуске группового байонета каждую функцию необходимо исправить и повторно выпустить, что является огромной рабочей нагрузкой, и мы изучаем соответствующие решения на практике.