Дизайн фреймворка микро-интерфейса

Управляемое чтение

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

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

Зачем нужны микрофронтенды

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

Одноклассник А пожаловался мне:
- Сцены:
  - В последнее время приходится принимать унаследованную back-end систему.Технология внутри не говоря уже о старой.Даже фреймворк колесо сделал сам,и документации нет.
- вопрос:
  - В ближайшем будущем в старую систему могут быть добавлены некоторые новые функции, но ее сложно преобразовать в исходную систему.
  - В будущем могут быть внесены некоторые изменения в существующие функции в старой системе, но исходная техническая система старая, и я хочу ее рефакторить на ts+react+webpack, но некоторые родовые страницы в ней, вероятно, не будут итерироваться , и их необходимо отрефакторить. оставайтесь на связи
Команда студента B также недавно столкнулась с проблемами:
- Сцены:
  - Команда, в которой они хотят нести ответственность за работу серверной системы, в настоящее время функции в системе очень велики, члены также очень активно участвуют в функциях внутри каждого подменю очень большое, каждое подменю может быть из-за разных команд, отвечающих за . А все текущие функции все в полимеризации внутри проекта
- вопрос:
  - Спецификация кода и выбор технической системы в рамках проекта вызовут споры между разными командами.
  - Функция в подменю была изменена, и весь проект необходимо переупаковать и развернуть, что увеличивает нестабильность и путаницу веток, а развертывание занимает много времени.
  - Существуют итерации спроса в разных подменю одновременно, и функции этих двух должны быть объединены, прежде чем их можно будет развернуть в предварительном выпуске и в автономном режиме. оперативность тестового выпуска, а также необходимо обеспечить отсутствие взаимного влияния

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

Основная ценность микрофронтенда

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

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

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

Техническая архитектура микроинтерфейса

why not iframe

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

Размер окна не синхронизируется (например, мы хотим центрировать всплывающее окно внутри iframe)
Проблема с синхронизацией файлов cookie состояния входа
Проблемы со связью между подприложениями
Много дублирования компонентов

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

Судя по пользовательскому опыту iframe, нам сложно использовать его в качестве стандартного решения для микро-фронтендов. Так что же нам нужно делать с микро-фронтенд-фреймворком? Из функции iframe мы можем примерно понять, что микросервис Фреймворк должен иметь следующие функции:

Загрузчик дочерних приложений (Loader)
Управление маршрутизатором (маршрутизатор)
Изоляция песочницы (Sandbox)
Связь между подприложениями (Магазин)

основная база проекта

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

Микроинтерфейс основных функций

Loader

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

Первый ненавязчивый, загружая соответствующие субприложения.index.htmlфайл, а затем путем разбора html-файла домашней страницы получаются и загружаются js-файл и css-файл подприложения.

Другой способ — упаковать субприложение в файл js.Согласно стандартному формату экспорта, основное приложение загружает толькоindex.jsдокумент. Получите соответствующие методы рендеринга и уничтожения.

let vm;
module.exports = {
 render () {
      vm = new Vue({
        render: (h) => h(Home),
      }).$mount(dom);
  },
  destroy() {
      vm.$destroy();
  }
}

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

Скачать исходный код подприложения
Компиляция и анализ содержимого экспорта подприложения
Внедрение общих зависимостей в подприложения

External

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

реализация загрузки commonJS

Module._catcheModule = {}
function req(moduleId){
  if(Module._catcheModule[p]){
    //模块已存在
    return Module._catcheModule[p].exports
  }
  //没有缓存就生成一个
  let module = new Module(p);
  Module._catcheModule[p] = module;
  //加载模块
  module.exports = module.load(p);
  return module.exports;
}
function Module(p){
  this.id = p
  this.exports = {}
  this.load = function(filepath){
    return Module._extensions(this)
  }
}
Module._wrapper = ['(function(exports,require,module,__dirname,__filename){','\n})']
Module._extensions = function(module){
    let fn = Module._wrapper[0] + fs.readFileSync(module.id,'utf8') + Module._wrapper[1]
    vm.runInThisContext(fn).call(module.exports,module.exports,req,module)
    return module.exports
}

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

Sandbox

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

Какие факторы нам необходимо учитывать при разработке песочницы в Интернете

глобальное загрязнение окружающей среды
событие загрязнения
загрязнение стиля
загрязнение таймера
локальное загрязнение хранилища

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

режим моментального снимка

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

прокси-режим

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

наконец

Прием на работу

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

О команде:ByteDance Web Infra Team is hiring

Возможна доставка через: zhouxiao.shaw@bytedance.com