Как ByteDance попал на микро-интерфейс

Автор: ByteDance Terminal Technology - Чжоу Сяо

Решения микроинтерфейса Garfish, упомянутые в этой статье, имеют открытый исходный код:GitHub.com/modern-is-the-…(В настоящее время Garfish, как наиболее широко используемое микроинтерфейсное решение в различных отделах ByteDance, обслуживает более 100+ клиентских команд и 400+ проектов), а современная система веб-инженерии ByteDance скоро будет с открытым исходным кодом. (Modern.js), глубокая интеграция Garfish обеспечивает встроенную поддержку микроинтерфейсов, предоставляя больше готовых возможностей, так что следите за обновлениями!

Предыстория и значение появления микрофронтендов

Что такое микро-интерфейс: микро-интерфейс — это архитектура, похожая на микросервисы. Это архитектурный стиль, который состоит из нескольких приложений интерфейса, поставляемых независимо. Он разбивает приложения интерфейса на более мелкие и простые, которые можно разрабатывать независимо друг от друга. которые протестированы, развернуты и по-прежнему представляются пользователям как единый продукт.

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

Интерфейс Micro зародился на все более сложной сцене веб-приложений, потому что с улучшением скорости сети, уровня компьютерного оборудования и развитием веб-стандартов пользовательский опыт веб-приложений в прошлом намного уступал традиционному прикладному программному обеспечению. Разрыв в пользовательском опыте между ними постоянно сокращается, и из-за высокой скорости разработки веб-приложений и особенностей ходьбы после использования один конечный результат заключается в том, что «приложения, которые могут быть реализованы с помощью веб-технологий, в конечном итоге будут реализованы через паутина." В последние годы появилось большое количество отличных продуктов, которые можно увидеть только в традиционном программном обеспечении для ПК, таких как: Photoshop, Web Office, Web IDE. Несмотря на эволюцию веб-стандартов, фронтенд-инжиниринг также развивается, от модульности к компонентизации и текущему инжинирингу, но в условиях крупномасштабной межгрупповой разработки и межкомандной совместной работы приложений на уровне предприятия существующие подразделения, управляющие шаблоны проектирования по-прежнему кажутся бессильными.

Дилемма крупномасштабных веб-приложений

Несмотря на взрывной рост сложности и участия веб-приложений, нет нового архитектурного шаблона, который бы решил существующую дилемму и учитывал как DX (опыт разработчика), так и UX (пользовательский опыт).

Взяв в качестве примера «промежуточную платформу НИОКР» в ByteDance, в повседневной работе НИОКР требуется множество систем НИОКР, таких как: управление кодом, построение кода, управление доменными именами, публикация приложений, управление ресурсами CDN, хранилище объектов, и т.п. С точки зрения исследований и разработок всей компании наилучшей формой продукта является размещение всех систем исследований и разработок в одном продукте.Пользователь не может понять, что он использует разные продукты.Для пользователя нет чувства разделения в одном продукте Вам не нужно изучать несколько платформ, вам просто нужно изучить и понять «среднюю платформу исследований и разработок» в ByteDance.

Этот тип приложений можно увидеть повсюду в ByteDance. Из-за большого количества бизнес-направлений в ByteDance каждое бизнес-направление будет генерировать большое количество систем среднего уровня, и оно все еще растет в геометрической прогрессии.Возьмем бизнес электронной коммерции в Например, ByteDance. Повседневная работа в сфере электронной коммерции фактически аналогична ежедневной работе по исследованиям и разработкам, которая вращается вокруг: товаров, продавцов, брендов, контроля рисков, маркетинга и т. д., так что самое главное. эффективная работа электронной коммерции для операций электронной коммерции?Что касается системы, поскольку вся система включает в себя широкий спектр, в фактическом процессе исследований и разработок она неизбежно будет разделена по вертикали на более мелкие подсистемы на основе функциональных или бизнес-требований. опыт разработчика, но пользовательский опыт в определенной степени снижается. Можно ли использовать новую архитектурную модель не только для удобства разработчиков, но и для улучшения взаимодействия с пользователем?

Плюсы и минусы традиционных веб-приложений

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

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

Если несколько систем используются для обслуживания в рамках одного проекта:

Преимущество:
лучшая производительность
С частичными обновлениями, бесшовный пользовательский интерфейс
Заранее загружать следующую страницу пользователя
Унифицированное управление разрешениями и унифицированные возможности разработки Open API
Лучшее повторное использование кода, повторное использование базовых библиотек
Унифицированные возможности управления операциями
Различные системы могут хорошо взаимодействовать
Особые преимущества SPA-приложений
Недостаток:
Проблемы с контролем доступа к коду
Время сборки проекта долгое
Релизы спроса блокируют друг друга
Хаос фиксации кода, хаос веток
Унификация технических требований к системе
Невозможно одновременно использовать несколько функций продукта в оттенках серого.
Откат кода влияет друг на друга
Мониторинг ошибок нельзя разбить на мелкие детали

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

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

Если разделить на несколько складов для обслуживания

Преимущество
Код может быть разделен в измерении проекта, чтобы решить проблему контроля разрешений.
Создавайте только код этого проекта, скорость сборки высокая
Могут использоваться различные технические системы
При поддержке одного и того же репозитория не возникает путаницы с коммитами и ветвями.
Функции оттенков серого не влияют друг на друга
недостаток
Пользовательский опыт фрагментирован при использовании, и они будут переключаться между разными платформами, что не может обеспечить пользовательский опыт, обеспечиваемый приложениями SPA.
Его можно разделить только по размеру страницы и нельзя разделить на блоки. Его можно разделить только по бизнес-измерению.
Сложность многосистемной односерой стратегии
Повторная загрузка общей базовой библиотеки пакетов
Отсутствие прямой связи между различными системами
Публичная часть может быть реализована только независимо для каждой системы, и трудно уведомить об одной и той же операции и обслуживании.
Разрешения продукта не могут быть объединены единообразно

Принятие схемы 2 в определенной степени улучшает опыт разработки, но снижает удобство для пользователя.Исследования и разработки должны использовать большое количество платформ в повседневной работе по разработке, но при этом необходимо переходить на разные платформы для повседневной работы в области исследований и разработок и общего взаимодействия с пользователем. бедных. Причина неудачного опыта заключается в том, что такой продукт, как общий «центр исследований и разработок», разделен по проектному измерению, так что каждый продукт представляет собой независимый остров, а взаимный переход между системами — это MPA в традиционном смысле. необходимо перезагрузить всю страницу, за исключением того, что производительность намного ниже, чем у приложений SPA, и нет прямой связи между приложениями, что еще больше усиливает ощущение разделения пользователя при использовании продукта.

Краткое изложение предыстории и значения

В двух приведенных выше сценариях можно обнаружить, что, когда веб-приложения постепенно заменяют традиционное программное обеспечение для ПК, крупномасштабные веб-приложения не могут одновременно гарантировать DX и UX из-за высокой сложности и участия большого количества членов команды. Традиционная стратегия «разделяй и властвуй» оказалась не в состоянии справиться со сложностью современных веб-приложений, поэтому был создан новый архитектурный шаблон, такой как микроинтерфейс. шаблон проектирования, но с новым методом для достижения.

Решения для микроинтерфейса

В предыдущем разделе кратко изложены предыстория и значение микроинтерфейсов, а также рассмотрены два традиционных режима разработки веб-приложений: SPA (одностраничное приложение) и MPA (многостраничное приложение), в которых задействован широкий круг персонала и высокая сложность проекта. Ввиду недостатков, вызванных этим сценарием, как насчет новой архитектуры, которая может иметь преимущества как архитектуры SPA, так и архитектуры MPA и одновременно улучшать DX (опыт разработчика) и UX (пользовательский опыт)?

В идеальной ситуации ожидается, что сложное монолитное приложение может быть вертикально разделено на более мелкие подсистемы в соответствии с функциональными или бизнес-требованиями и может обеспечить следующие возможности:

Разработка и выпуск между подсистемами изолированы от пространства
Подсистемы могут использовать разные технические системы
Повторное использование кода базовой библиотеки может быть выполнено между подсистемами.
Связь между подсистемами может быть завершена быстро
Итерации требований между подсистемами не блокируют друг друга
Подприложения могут быть постепенно обновлены
Подсистемы могут двигаться к одному и тому же управлению версиями в градациях серого.
Обеспечить централизованный контроль разрешений подсистемы
Пользовательский опыт Вся система представляет собой единый продукт, а не островки друг друга
Мониторинг проекта можно доработать до подсистем

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

Общая архитектура микрофронтенда

Итак, как предоставить набор решений, которые не только обладают пользовательским интерфейсом SPA, но и обладают гибкостью, обеспечиваемой приложениями MPA, и могут обеспечить одинаковые оттенки серого между приложениями, а мониторинг также может быть улучшен для подсистем? Микроинтерфейсное решение "Garfish", применяемое в настоящее время в ByteDance, представляет собой такой набор решений. Решение в основном разделено на три уровня: сторона развертывания, среда выполнения фреймворка и инструменты отладки, использующие архитектуру SPA.

Общая архитектура решения

Платформа развертывания микроинтерфейса

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

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

Время выполнения микро-фронтенда

Why not iframe

Когда дело доходит до темы, которую не могут обойти микрофронтенды, именно поэтому iframe не используется в качестве контейнера для переноса приложений микрофронтенда, ведь из нативного решения браузера iframe является едва ли не самым надежным микрофронтендом. решение с точки зрения опыта. Основное приложение загружает подприложения через iframe. Собственный стиль iframe и механизм изоляции среды делают его естественным механизмом песочницы, но он также не подходит в качестве загрузчика для загрузки подприложений из-за его изоляция.Характеристики iframeЭто не только приведет к ухудшению пользовательского опыта, но и вызовет больше проблем в повседневной работе НИОКР.Ниже резюмируются некоторые недостатки iframe как вспомогательного приложения:

Использование фреймов значительно увеличит память и вычислительные ресурсы, поскольку страницы, размещенные в фреймах, требуют новой и полной среды документов.
iframe и верхнее приложение не приводят к одному и тому же контексту документа
Основное приложение перехватывает действие сочетания клавиш
События не могут всплывать на верхний уровень, а ограничение по времени обрабатывается единообразно для всего приложения.
Всплывающие события не проникают в основное дерево документов, когда фокус находится в подприложении, событие не может быть передано в предыдущий поток документов.
Путь перехода не может быть синхронизирован с верхним документом, обновите статус потерянного маршрута
Элементы в iframe будут ограничены деревом документа, а ширина и высота окна ограничены.
Состояние входа в iframe не может быть передано, и вспомогательному приложению необходимо снова войти в систему.
Службы платформы iframe недоступны, если сторонние файлы cookie отключены.
Не удалось загрузить приложение iframe, произошла ошибка содержимого, и основное приложение не смогло ее воспринять
Сложно определить производительность, когда iframe является частью страницы.
Невозможно предварительно загрузить кешированное содержимое iframe
Невозможно поделиться базовой библиотекой для дальнейшего уменьшения размера пакета
Коммуникация о событиях обременительна и ограничена

Архитектура микроинтерфейса на основе SPA

Хотя использовать iframe в качестве загрузчика для приложений с микроинтерфейсом сложно, это может относиться к его конструктивной идее.Возможность традиционного iframe для загрузки документов можно разделить на четыре уровня: возможность загрузки документа, рендеринг HTML, выполнение JavaScript, стиль изоляции и операционная среда JavaScript. Тогда базовые возможности библиотеки микроинтерфейса также могут относиться к ее дизайнерским идеям.

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

Погрузчик
Тип записи HTML, дизассемблировать HTML Dom, Script, Style
Тип записи JS, предоставляющий базовый контейнер Dom
Отвечает за регистрацию списка приложений, предоставленного стороной платформы.
Отвечает за загрузку и анализ ресурсов входа подприложения.
возможность предварительной загрузки
Анализ экспорта подприложений
Изоляция песочницы (Sandbox)
Предоставляет возможности выполнения кода и собирает побочные эффекты, возникающие при выполнении кода.
Предоставляет возможность уничтожить побочные эффекты коллекции
Поддержка нескольких экземпляров песочницы, сбор побочных эффектов разных экземпляров
Хостинг маршрутов (Роутер)
Решить проблему рассинхронизации маршрутизации между разными приложениями
Предоставляет возможность перехвата маршрутизации для управления маршрутизацией подприложений в основном приложении.
Возможность предоставления возможностей на основе маршрутизации для сборки полной платформы.
Связь между подприложениями (Магазин)
Стройте коммуникационные мосты
предоставить механизм обмена

жизненный цикл приложения

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

этап визуализации
Если тип записи — HTML, он начнет синтаксический анализ и дизассемблирование ресурсов субприложения.
Если тип записи — JS, создайте DOM точки подвеса подприложения.
Основное приложение запускает рендеринг подприложения посредством монтирования на основе маршрута или вручную.
Начните загружать содержимое ресурсов приложения и инициализируйте среду выполнения песочницы дочернего приложения.
Определить тип записи
Подприложение имеет «побочные эффекты» (контент, который может повлиять на текущую страницу), которые должны обрабатываться песочницей.
Начать рендеринг дерева DOM дочернего приложения
Запускайте хуки рендеринга для подприложений
фаза разрушения
Если изменение маршрута выходит за пределы области активации подприложения или активно запускает функцию уничтожения, приложение уничтожается.
Устраняет побочные эффекты приложения во время рендеринга и во время выполнения.
Удалить элементы DOM из дочерних приложений

Дизайн погрузчика

Общая концепция дизайна загрузчика на самом деле очень похожа на React-loadable со следующими возможностями:

Загружать ресурсы компонента асинхронно
Ресурсы могут быть предварительно загружены
Ресурсы компонентов могут кэшироваться
Экземпляр компонента кэша

В отличие от компонентов, микрофронтенды используются в качестве архитектурной модели, которая может разобрать одно приложение на несколько подприложений.В отличие от компонентов, лучший режим НИОКР для разделения этих подприложений — это разработка, тестирование и развертывание. от среды хоста, само под-приложение должно иметь автономные возможности, тогда оно очень похоже на возможности, предоставляемые iframe.iframe загружает ресурсы всего под-приложения в виде загрузки HTML-документов, затем под- Само приложение можно использовать как самостоятельный сайт.Естественно есть возможность самостоятельной разработки и тестирования. Таким образом, загрузчик Garfish предоставляет два типа ввода приложения: тип HTML и тип ввода JS, но следует отметить, что Garfish не делит его на другой поток документов, как iframe, а обрабатывает его как тот же документ, что и основное приложение. используется, чтобы избежать проблемы фрагментации опыта, вызванной разным потоком документов.

Поскольку тип записи HTML, естественно, обладает характеристиками независимости, разработки и тестирования, в общей архитектуре микро-интерфейса для совместной работы между командами лучшая модель НИОКР — это снижение затрат на связь, а лучший способ сократить расходы на связь до Нет связи, поэтому общий тип проекта рекомендует пользователям как можно больше использовать тип записи HTML.

Итак, что нужно сделать для загрузчика типа записи HTML, ниже представлена схема процесса рендеринга браузера:

Процесс рендеринга для браузера также можно разделить на: загрузку текста HTML, разборку HTML в синтаксическое дерево, разборку контента с «побочными эффектами» в синтаксическом дереве (контент, который может повлиять на текущую страницу), например скрипт , Стиль, Ссылка обрабатывается песочницей для пост-рендеринга. В отличие от обычных подприложений, подприложения должны предоставлять поставщиков. Поставщик включает в себя жизненный цикл рендеринга и уничтожения подприложений. Эти два хука можно использовать для дальнейшего улучшить приложение в режиме кеша скорость рендеринга и производительность.

дизайн песочницы

Зачем нужна песочница

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

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

Возьмите Webpack4 JsonpFunction в качестве примера.

Важной функцией, представленной в Webpack 5, является Module Federation.С введением Module Federation в Webpack 5 важной конфигурацией, которая изменилась в Webpack 4, являетсяJsonpFunctionсобственность становитсяchunkLoadingGlobal, и исходным значением по умолчаниюwebpackJsonpстановится по умолчаниюoutput.libraryимя или контекстpackage.jsonИмя пакета как уникальное значение (webpack.js.org/issues/3940).

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

После поддержки федерации модулей через Webpack 4 и Webpack 5 можно обнаружить, что в сценарии, где базовая библиотека не учитывает совместимость по умолчанию с несколькими экземплярами, необдуманное использование ее в качестве нескольких экземпляров может привести к сбою запуска приложения. как и ожидалось. А если серьезно, я думал, что оно работает нормально. На самом деле приложение испытало серьезные утечки памяти или непредсказуемые ситуации. Если приложение, созданное Webpack, динамически запускать на странице много раз, будет обнаружено, что серьезные утечки памяти были вызваны, потому что Webpack будет увеличиваться Большое количество модулей и информация о зависимостях монтируются в переменные куска глобального хранилища.Проще говоря, каждый раз, когда код подприложения, созданный Webpack, выполняется, большой объем данных будет помещен в массив webpackJsonp, что в конечном итоге приведет к утечке памяти, пока страница не выйдет из строя.

Основные возможности песочницы

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

Основные возможности песочницы в Garfish Runtime также построены вокруг этой возможности.Типы побочных эффектов, которые могут быть созданы для подприложений, в основном делятся на две категории: одна — статические побочные эффекты, а другая — динамические побочные эффекты. К чему здесь относятся статические побочные эффекты и динамические побочные эффекты?Статические побочные эффекты относятся к содержимому статических тегов в HTML, таких как: теги сценария, теги стиля, теги ссылок, которые включены в поток документа HTML, и другая часть из побочных эффектов относятся к динамическим побочным эффектам, динамические побочные эффекты динамически создаются JavaScript.Например, JavaScript может динамически создавать стиль, динамически создавать скрипт, динамически создавать ссылку, динамически выполнять код, динамически добавлять элементы DOM, добавлять глобальные переменные, добавлять таймеры, сетевые запросы, контент, имеющий побочные эффекты на текущей странице, например localStorage.

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

Две идеи дизайна песочницы

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

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

Снимок песочницы

Как следует из названия, текущая среда выполнения сохраняется в режиме моментального снимка до запуска приложения, а среда выполнения до приложения восстанавливается после его уничтожения, что используется для изоляции и устранения побочных эффектов между приложениями. Как и в «SL Dafa», среда сохраняется при сохранении, а режим среды загружается при загрузке.

Идеи реализации кода

Краткое описание основных идей дизайна:

Предоставьте класс Patch для каждого побочного эффекта, который должен предоставлять методы сохранения и загрузки.
Save соответствует хранилищу моментальных снимков среды побочного эффекта, а Load соответствует среде уничтожения и восстановления, которая уничтожает побочный эффект.
И для каждого патча так же может сохранять свои изменения в процессе работы, не весь код используется при оптимизации сцены, восстанавливается только среда исполнения

Песочница виртуальной машины

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

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

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

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

Ссылаясь на конструкцию модулей ВМ в Node и характеристики лексической области действия JavaScript, можно спроектировать песочницу ВМ, но есть и отличия от традиционных ВМ.Он не может выполнять ненадежный код, поскольку его возможности изоляции ограничены контекст.

Это приводит к следующему дизайну

Какие контексты нужны для изолированной среды

Для типов побочных эффектов: глобальные переменные, глобальные события, таймеры, сетевые запросы, localStorage, стили Style, DOM-элементы, предусмотрены новые контексты выполнения:

Window
Используется для изоляции глобальной среды
document
Соберите побочные эффекты DOM
Собирайте побочные эффекты стиля и обрабатывайте их
Соберите скрипт и продолжайте размещать обработку в песочнице
Используется для захвата динамически создаваемых узлов DOM, стилей, скриптов.
тайм-аут, интервал
таймер обработки
localstorage
изолировать локальное хранилище
listener
Собирайте глобальные события

Откуда берется новый контекст выполнения?

Новый контекст выполнения исходит из двух источников:

из текущей среды
Среда выполнения, полученная из iframe

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

Сравнение возможностей изолированной программной среды моментальных снимков и изолированной программной среды виртуальной машины

Проектирование системы маршрутизации

Из-за идеи дизайна современного MVC идея дизайна интерфейсной среды также постоянно меняется.Самая классическая возможность, предоставляемая современной веб-интерфейсной средой, — это изменение контроллера в MVC на маршрутизатор. В настоящее время почти основные интерфейсные фреймворки поддерживают представления на основе маршрутов, предоставляют только таблицу маршрутизации Router Map и могут выполнять обновление маршрутизации после перехода, не обращая внимания на управление каким-либо состоянием маршрутизации.

Благодаря предыстории и значимости микроинтерфейсов мы можем понять, что микроинтерфейсы в основном используются для решения: добавочных обновлений приложений, сосуществования мультитехнологических систем и создания крупномасштабных веб-приложений корпоративного уровня. Затем в архитектуре микроинтерфейса на основе SPA мы также можем узнать, что текущий микроинтерфейс в основном использует режим приложения «разделяй и властвуй» + динамическая загрузка + приложение SPA для решения ряда проблем, вызванных крупномасштабными приложениями. В компонентном SPA-приложении нет необходимости заботиться о маршрутизации внутри компонента, но в микроинтерфейсе он в основном разделен по измерению приложения, поэтому разделенное приложение также может быть независимым SPA-приложением, тогда main Как организовать связь между приложениями и под-приложениями?

Идеальное планирование маршрутизации в микроинтерфейсных приложениях

Предположим, есть сайт Garfish, который состоит из основного приложения + трех подприложений, а базовое имя основного приложения —/demo, и есть три вкладки, соответственно указывающие на переход к различным приложениям, идеальный эффект маршрутизации:

После нажатия вкладки vue-app перейдите к/demo/vue-appПосле маршрутизации активировать отдельноvue-appПод типом Vue активируются приложение A и приложение B, а также активируется компонент Home в приложении A и приложении B.
Щелкните вкладку React-app, чтобы войти/demo/react-appПосле маршрутизации активировать отдельноreact-appЗатем для приложения React-типа C и активируйте компонент Home приложения C.
На основе активации приложения C нажмите кнопку Detail, чтобы перейти к/demo/react-app/detailи активируйте детальный компонент приложения C.
Нажмите кнопку «Назад» в браузере, чтобы отобразить, перейти/demo/react-app/detail, и активируйте компонент Home приложения C, тем самым завершив базовую возможность перехода по маршруту в браузере.

Сценарии, в которых не рассматривается обработка маршрутизации

Допустим, есть сайт Garfish, который состоит из основного приложения + подприложения. Поскольку Garfish использует архитектуру SPA, подприложение находится в том же контексте выполнения, что и основное приложение, и маршрутизация подприложения отражается в основном приложении как есть.

Затем перейдите к:/home,/detailКакие проблемы обнаружит маршрутизация?

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

В этот момент при переходе к:/home,/detail,/testПри маршрутизации соответствующие представления компонентов запускаются соответственно, но если маршрутизация подприложения также существует/detailЧто касается точки зрения, поскольку разработка приложений использует модель «разделяй и властвуй», разработка приложений разделена в пространстве и времени, и нет гарантии, что маршруты между приложениями не будут вытеснены.

"Невозможно гарантировать, что приложение может инициировать обновление представления через переход маршрутизации истории". Когда используется переход маршрутизации через API истории, обновление представления приложения не может быть инициировано. Предположим, что есть приложение React A и компонент view Test, которые предоставляются React соответственно.

Шаблоны маршрутизации хэшей и истории

В настоящее время основные интерфейсные приложения SPA в основном поддерживают два режима маршрутизации: режим хеширования и режим маршрутизации по истории. раздельный режим разработки микро-фронтенда, какой режим маршрутизации выбрать в режиме отдельной разработки SPA-приложений микро-фронтенда и как должны быть устроены их маршруты в мульти-SPA-приложениях:

Предположим, адрес сайта:http://garfish.bytedance.net

нормальная маршрутизация

Режим истории основного приложения, режим истории вспомогательного приложения
основное приложение (basename: /example):
Все маршруты в основном приложении основаны на:http://garfish.bytedance.net/exampleпример
Например, перейдите к: /appA,http://garfish.bytedance.net/example/appA/сын
дополнительное приложение (basename: /example/appA):
Все маршруты для подприложений основаны на:http://garfish.bytedance.net/example/appA
Перейти на страницу /detail подприложения,http://garfish.bytedance.net/example/appA/detail
Функции:
Когда основное и вспомогательное приложения находятся в режиме истории соответственно, маршрутизация вспомогательного приложения основана на базовой маршрутизации основного приложения и обеспечивает собственную бизнес-маршрутизацию.
Маршрут синхронизируется с маршрутом основного приложения, а конфликт маршрута между основным приложением и другими приложениями изолируется через пространство имен области действия подприложения (подприложение A, которое обеспечивает область действия appA), а подприложение
Путь соответствует восприятию и пониманию пользователя и разработчика.
Поддерживайте использование вложенных уровней и по-прежнему обеспечивайте возможность чтения маршрутов в пространстве имен области.
Режим истории основного приложения, режим хеширования подприложения
основное приложение (basename: /example):
Все маршруты в основном приложении основаны на:http://garfish.bytedance.net/example
Например, перейдите к: /appA,http://garfish.bytedance.net/example/appA/
дополнительное приложение (basename: /example/appA):
Все маршруты для подприложений основаны на:http://garfish.bytedance.net/example/appA
Из основного приложения:http://garfish.bytedance.net/example/appA, перейдите на страницу /detail подприложения,http://garfish.bytedance.net/example/appA#/detailособый
Функции:
В определенной степени его преимущество в том, что основное и вспомогательные приложения находятся в режиме истории и не поддерживают использование вложенных уровней.
В настоящее время большинство фреймворков не поддерживают хеш-значение в качестве базового имени.
Читаемость приемлемая

Нештатная ситуация с маршрутизацией

Режим хеширования основного приложения, режим истории вспомогательного приложения
основное приложение (basename: /example):
Все маршруты в основном приложении основаны на:http://garfish.bytedance.net/example
Например, перейти к: /detail,http://garfish.bytedance.net/example#/appA
дополнительное приложение (basename: /example#/appA):
Все маршруты для подприложений основаны на:http://garfish.bytedance.net/example#/appA
Перейти на страницу /detail подприложения,http://garfish.bytedance.net/example/detail#/appA
Функции:
«Путаница с маршрутизацией», не соответствующая интуиции пользователя и разработчика
В настоящее время большинство фреймворков не поддерживают хеш-значение в качестве базового имени.
Режим хеширования основного приложения, режим хеширования подприложения
основное приложение (basename: /example):
Все маршруты в основном приложении основаны на:http://garfish.bytedance.net/example
Например, перейти к: /detail,http://garfish.bytedance.net/example#/appA
дополнительное приложение (basename: /example#/appA):
Все маршруты для подприложений основаны на:http://garfish.bytedance.net/example#/appA
Перейти на страницу /detail подприложения,http://garfish.bytedance.net/example#/detail
Функции:
«Путаница с маршрутизацией», не соответствующая интуиции пользователя и разработчика
В настоящее время большинство фреймворков не поддерживают хеш-значение в качестве базового имени.
Возможные конфликты маршрутизации с основным приложением или другими дочерними приложениями.

Как Garfish Router обрабатывает маршрутизацию

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

В настоящее время Garfish в основном предоставляет следующие четыре стратегии.

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

Router Map снижает затраты разработчиков на понимание

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

Автоматически вычисляет базовое имя, требуемое вспомогательным приложением.

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

Как эффективно запускать обновления представления между различными приложениями

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

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

Собирать события popstate, которые прослушивает фреймворк.
Активно запускать событие popstate

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

Лучшие практики для микро-интерфейсов на основе «современных веб-фреймворков»

Как новый тип веб-приложения, микро-интерфейс отличается от традиционной разработки веб-приложений в прошлом.Микро-интерфейс должен принять режим разработки разделения и завоевания основных и подприложений, что создает ряд новых проблем. проблемы включают, но не ограничиваются: разработка и отладка основных и вспомогательных приложений, как быстро превратить обычные веб-приложения в приложения микроинтерфейса, как поддерживать SSR приложения микроинтерфейса и обмен данными между основными и вспомогательными приложениями для запуска просматривать обновления.Modern.jsКак современная веб-инфраструктура поверх Garfish, она может решить эти проблемы и предоставить нестандартный опыт разработки.

Отладка и разработка микроинтерфейсных приложений

Поскольку приложение микроинтерфейса использует стратегию разработки «разделяй и властвуй», обслуживание и разработка между приложениями могут быть разделены во времени и пространстве, поэтому неразумно запускать все основные и вспомогательные приложения всего микроинтерфейса. проекта в среде разработки., необходимо не только клонировать другие склады и завершить работу приложения, но и обеспечить своевременность его кода. Modern.js предлагает лучшую стратегию:

Когда некоторые вспомогательные приложения необходимо обновить
Онлайн-среда основного приложения
Автономная среда разрабатываемого подприложения
Под-приложения, которые не нужно разрабатывать, находятся в сети
Когда нужно обновить основное приложение
Автономная среда основного приложения
Все суб-приложения в онлайн-среде

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

Традиционные веб-приложения поддерживают шаблоны микроинтерфейса.

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

Garfish интегрирован как инфраструктура верхнего уровня в Modern.js, которая изначально поддерживает микроинтерфейсные приложения.Преобразование типов микроинтерфейсных приложений можно выполнить с помощью простой настройки, помогая пользователям быстро создавать инфраструктуру приложений для сокращения свои затраты на обучение и быстро генерировать микроинтерфейсы приложения.

Как приложения Micro Frontend поддерживают SSR

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

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

Преимущества микро-фронтендов

Разработка масштабных веб-приложений
более высокая скорость разработки
Поддержка итеративной разработки и улучшений обновлений
Разобранная часть снижает затраты разработчика на понимание
Режим разработки с UX и DX

Недостатки микро-фронтендов

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

Когда использовать микрофронтенды

Разработка крупномасштабных корпоративных веб-приложений
Совместная разработка между командами и корпоративными приложениями
Долгосрочная доходность выше краткосрочной
Проекты с различными вариантами технологии
Части единого продукта требуют независимой публикации, оттенков серого и других возможностей.
Цель микрофронтендов не в том, чтобы заменить фреймы
Источник приложения должен быть надежным
Требования к пользовательскому опыту выше

Суммировать

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

Микро-интерфейс — это не серебряная пуля. После внедрения микро-интерфейса сложность не исчезает из воздуха. Вместо этого код обращается к инфраструктуре, что создает большие проблемы для проектирования архитектуры, и его необходимо спроектировать и предоставленные в рамках новой архитектуры периферийные инструменты и экология, чтобы помочь этой новой модели НИОКР.

Эта статья больше посвящена выяснению того, какими возможностями должно обладать микроинтерфейсное решение на уровне фона и дизайна, а также дизайна основных модулей. Каждая часть не содержит слишком подробных деталей.GitHub.com/modern-is-the-…Склад для деталей.

Ссылаться на

Как спроектировать планирование основной и вспомогательной маршрутизации в микро-интерфейсе:Tickets.WeChat.QQ.com/Yes/ta XP7IP DD…
Как хитро реализовать песочницу:Tickets.WeChat.QQ.com/Yes/mg3F U0w V Z…
Микросервисная архитектура и ее 10 наиболее важных шаблонов проектирования:Woohoo.info Q.can/article/broadband network…
одноместный спа:GitHub.com/single-afraid/…

Предварительный просмотр с открытым исходным кодом Modern.js

И Modern.js, и Garfish являются проектами с открытым исходным кодом «Современной системы веб-инженерии», инициированным ByteDance Web Infra. Modern.js изначально поддерживает микроинтерфейсы и предоставляет полные передовые методы микроинтерфейсов на основе Garfish.

Modern.jsПланируется выпустить версию 1.0.0 и станцию онлайн-документации 14 октября. Приглашаем обратить внимание и принять участие.

Нажмите, чтобы просмотретьХранилище сарганов.