Конференция раннего чата по интерфейсу, новая отправная точка для развития интерфейса, была проведена совместно с Nuggets. Добавьте WeChat codingdreamer в эксклюзивную группу микро-интерфейса конференции и выиграйте на новом стартовом рубеже.
14-я сессия Front-end Growth and Promotion, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):
Текст выглядит следующим образом
Эта статья — 39-я сессия фронтенда раннего чата, седьмого микрофронтенда, отИнтерфейсная команда Taobao - KunchenСовместное использование - Кратко организованная версия выступления (пожалуйста, смотрите записанное видео и PPT для полной версии, включая демонстрацию):
Введение
Привет всем, меня зовут Кун Чен из фронтенд-команды Taobao. Я в основном отвечаю за построение миддл и бэкэнд архитектуры системы отдела Taobao. Тема, которой я в основном поделюсь с вами сегодня, — это «Как спроектировать решение микроинтерфейса в крупномасштабной архитектуре приложения».
2. Введение содержания
Ядро будет разделено на четыре части для введения:
1. Прежде всего кратко представлю понятие микро-фронтенд.Сегодня специальная сессия микро-фронтенда.Что за понятие так называемый микро-фронтенд,думаю необходимо иметь предварительное представление . 2. Основываясь на внутреннем бизнес-фоне отдела Дао, включая потребности сообщества, я расскажу, как разработать архитектуру микроинтерфейса. 3. В третьей части контента будет рассказано о возможностях микроинтерфейса, в том числе о некоторых наших дизайнерских концепциях и мышлении. 4. В заключение я расскажу вам о ценности, которую в настоящее время приносит бизнесу микроинтерфейсное решение, а также о типичных бизнес-сценариях, которые оно может охватывать.
2.1, концепция микроинтерфейса
Микроинтерфейс был предложен еще в 2016 году на технологическом радаре ThoughtWorks, и фактически он родился из концепции серверных микросервисов. В прошлом за одно веб-приложение, как правило, отвечала команда, включая интерфейсную и серверную части. С развитием технологий распределение обязанностей будет более дробным в зависимости от области, а ответственная команда проекта будет разделена на команду переднего плана и команду заднего плана. В этом сценарии серверные возможности фактически объединены.
С появлением концепции микросервиса серверная часть будет разделять некоторые возможности серверной части в соответствии с функциональным измерением, а затем добавлять уровень агрегации к среднему уровню при взаимодействии до и после, например **graphQL, или полагаться на некоторые уровни BFF. Для агрегации данных, включая некоторую обработку шлюза.
Как архитектура, подобная микросервису, микро-интерфейс фактически применяет концепцию микросервиса к стороне браузера. Мы также разделяем одно интерфейсное веб-приложение в соответствии с функциональными размерами, а затем объединяем его в единое целое. Ниже архитектуры приложения, здесь это концепция микро-интерфейса.
2.2 Предыстория бизнеса
Какие сценарии потребуют такой технической архитектуры? Есть два основных сценария:
- Первая сцена Сцена верстака, основанная на широте опыта продукта
- Второй сценарий — крупномасштабное отдельное приложение, которое больше ориентировано на оптимизацию с технической точки зрения.
Сценарий workbench на самом деле означает, что в некоторых компаниях будет много системных платформ, а межсистемные операции будут задействованы в ежедневном рабочем процессе, поэтому будут возникать несоответствия в опыте взаимодействия между различными системами, а также будут возникать некоторые ненужные переходы на страницы. будет неэффективность.
Более того, в многонезависимой системе, будь то уровень BFF или какие-то промежуточные уровни обработки шлюза, или какие-то базовые возможности внешнего интерфейса, будет много повторяющихся конструкций. Несколько систем независимы друг от друга, и большинство систем фактически не могут контролировать свою конкретную логику реализации. Думая с точки зрения общего продукта, дублирование и неконтролируемые ситуации, несомненно, неприемлемы.
Второй сценарий относительно более распространен: большие монолитные приложения — это то, что мы обычно называем мегалитическими приложениями. Характеристики этого типа приложений очевидны, а его системный объем очень велик. Например, с точки зрения размера файла, созданного пакетом, один файл может превышать 10 МБ. Такой объем сборки серьезно повлияет на опыт и эффективность разработки при ежедневной отладке и разработке.
Еще одна ключевая проблема заключается в том, что когда бизнесу необходимо выполнить функциональную итерацию или обновить техническую архитектуру для монолитного приложения, затраты на разработку и совместную работу очень высоки. Из-за большого размера влияние изменений также очень велико. Наконец, если есть какие-то двусторонние требования и функции, когда вы хотите повторно использовать эту возможность напрямую, это на самом деле сложно сделать на основе текущей архитектуры SPA, в основном вам нужно реализовать то же самое в существующей системе. логика.
В сочетании с двумя вышеупомянутыми сценами мы больше надеемся, что существует подходящая техническая архитектура, которая поможет бизнесу построить систему, которая будет иметь хорошее и устойчивое обслуживание.
2.3. Технический отбор
Основываясь на вышеуказанных требованиях, какие технические решения ждут нас?
2.3.1. Боулдеринг
Приложение Boulder также является технической архитектурой SPA/MPA. Здесь я хотел бы отдельно упомянуть, что для сценария взаимодействия с продуктом простое SPA-приложение определенно может дать общее впечатление от системы и контролировать техническую сложность системы. Но если система будет становиться все более и более раздутой, она столкнется с упомянутой выше проблемой технической широты.
2.3.2, iframe
До популярности решений для микроинтерфейса iframe был лучшим решением. Будь то двухсторонний или трехсторонний доступ, он может хорошо удовлетворить потребности. Но у него есть фатальная проблема — пользовательский опыт. Для общей проблемы, если iframe не выполняет какой-либо специальной обработки, проблема с двойной полосой прокрутки встроенной страницы, маршрутизация не может быть синхронизирована, включая некоторые взаимодействия с всплывающими масками внутри iframe, эти проблемы очень недружелюбны с точки зрения опыта. . . . Проблема пользовательского опыта на самом деле очень фатальна для некоторых продуктов, поэтому мы также отказались от решения iframe.
2.3.3, компоненты рамы
Схема компонентов кадра, обычно в некоторых распространенных сценариях, где используется общая логика заголовка или потолка. Обычно используемая логика инкапсулирована в компонент, который фактически представлен в виде пакета npm.
У этого метода есть очевидные проблемы, он не решает по существу проблем, упомянутых выше, включая обновление технической архитектуры и оптимизацию пользовательского опыта. Например, общие компоненты макета могут гарантировать наличие в системе унифицированного интерактивного слоя визуального макета. Хотя кажется, что эти две системы одинаковы, на самом деле это разные системы, и межсистемные операции по-прежнему требуют перехода.
2.3.4 Преимущества и недостатки четырех схем
Кратко подытоживая, можно сказать, что каждый из четырех методов имеет свои преимущества и недостатки. Основной бизнес-сценарий микроинтерфейсного решения — найти баланс между опытом и эффективностью.
Основываясь на вышеуказанных исследованиях и сравнениях, было окончательно принято решение выбрать техническое решение микроинтерфейса для обновления бизнес-архитектуры.
2.3.5 Решение микроинтерфейса
Вышеупомянутая микроинтерфейсная архитектура была реализована в Департаменте Дао, что является более представительной сценой. Поскольку планируется, что эта платформа будет выполнять множество функций и будет выводить много страниц, сцена больше соответствует крупномасштабному одиночному приложению, которое мы только что упомянули, то есть сцене приложения Boulder. При проектировании архитектуры мы разделяем общую систему по функциональным параметрам. Например, согласно его записи, управление учетными записями, включая возможности, связанные с контентом, возможности, связанные с данными и т. д., оно разделено примерно на 20 независимых приложений, которые объединены в одну платформу. Это фактически завершает обновление, основанное на архитектуре микроинтерфейса, что повышает удобство обслуживания платформы.
3. Архитектурный дизайн
Почему микроинтерфейсная архитектура может обеспечить такую возможность интеграции нескольких систем? Далее я расскажу о возможностях и идеях микроинтерфейсного решения icestark в архитектурном дизайне.
Этот контент будет разделен на 6 частей для ознакомления Прежде всего, я представлю возможности следующего микро-интерфейса в целом, а также основную концепцию архитектурного проектирования, когда мы будем делать это техническое решение. Позже я представлю основные концепции, представленные микро-интерфейсом, включая работу микрофронтенда.Принцип, и напоследок два технических момента, которые всех больше волнуют: схема изоляции и схема микромодуля.
3.1. Микроинтерфейсное решение
Далее давайте посмотрим, что будет включать в себя общее решение микро-фронтенда. Это общая картина решения микроинтерфейса в целом.Сегодня мы в основном фокусируемся на возможностях, предоставляемых icestark. Микроинтерфейс icestark в основном распределяет приложения в соответствии с изменениями маршрутизации, включая управление жизненным циклом приложений, загрузку приложений, обмен данными, изоляцию и работу в песочнице. Когда приложение платформы обращается к микроинтерфейсу, ему не нужно заботиться об обработке, связанной с микроприложением, а ядру нужно только завершить настройку микроприложения. В дополнение к конфигурации микроприложения в приложении платформы также могут быть некоторые бизнес-практики, такие как логика аутентификации или скрытая логика приложения. Сегодня наше ядро будет разбирать возможности, предоставляемые архитектурой icestark.
3.2 Концепция дизайна
В качестве решения для микроинтерфейса архитектура icestark придерживается четырех концепций.
Первый момент — стек технологий не имеет значения, когда подключается микроприложение, нам все равно, какой у него стек технологий, использует ли оно React, Vue или Angular, это даже древний код (jQuery). можно получить доступ. Но почему на практике рекомендуется унификация стека технологий единой технологической системы? Кажется, что это два противоречащих друг другу понятия, но на самом деле мы думаем, что микрофронтенды могут интегрировать некоторые независимые системы или приложения в одну систему за счет несвязанных возможностей технологического стека. В процессе интеграции больше надежды на то, что он сможет сделать какую-то техническую унификацию, а не на то, чтобы не делать никакого контроля и позволить ему бурно разрастаться. Таким образом, в конкретном практическом процессе архитектуры микроинтерфейса концепция, которую мы поддерживаем, заключается в том, что в рамках единой системы требуется техническое единство.Даже если текущая миграция не основана на соображениях стоимости, в долгосрочной перспективе техническая система должны постепенно сходиться.
Например, Alibaba Group требует использования React в своей технической архитектуре, если есть какая-то существующая система Vue, она также будет интегрирована, но при последующей разработке дополнительных требований она обязательно будет итеративно модернизирована технической системой React. . В прошлом необходимо было учитывать сосуществование нескольких технологических стеков, и микроинтерфейсная архитектура, естественно, поддерживает это, что обеспечивает базовую гарантию плавной миграции системы.
Вторая концепция дизайна — последовательный опыт разработки.Внедрение решения микроинтерфейса в техническую архитектуру сегодня не означает, что есть много новых концепций для изучения, включая новый синтаксис, логику построения и даже изменения в общем методе кодирования. , чего мы не ожидаем увидеть. Поэтому при проектировании одним из основных предложений является недорогая или даже нулевая миграция.Разработчикам не нужно изучать какие-то новые концепции и процессы, и они сохраняют исходную логику разработки.
Третий пункт на самом деле является основной возможностью микро-интерфейсного решения — возможностью маршрутизации.В icestark маршрутизация фактически представляет собой централизованное управление.Вся информация о маршрутизации хранится в приложении платформы, а маршрутизация выполняется в соответствии с изменениями маршрутизации.Распределение и управление .
Четвертый пункт, независимая разработка и развертывание, фактически в определенной степени будет отражать последовательный опыт разработки, упомянутый выше. Предыдущее приложение разрабатывалось и развертывалось самостоятельно, и оно осталось таким же и сейчас, и оно не менялось до того, как его подключили к архитектуре микрофронтенда.
3.3 Основные концепции
Icestark представил внутри основной концепции два основных момента: фрейм-приложение и микро-приложения. Он отвечает за общую структуру приложения с конфигурацией приложения микромакета и рендерингом регистрации. Как видно из приведенного выше изображения, есть общий заголовок кадра приложения Заголовок, боковая панель siderBar, в дополнение к макету, информация о конфигурации, необходимая для микроприложений, такая как URL-адрес информационного пакета, например, эталонный маршрут. На самом деле это бизнес-измерения микроприложения, отделяющие некоторые приложения, вообще говоря, это, вероятно, приложение SPA, и оно будет включать по крайней мере одну или маршрутизацию на несколько страниц.
3.4 Регистрация микроприложений
На приведенном выше рисунке показано, как приложение платформы регистрирует информацию о микроприложении на уровне кода. В информации о конфигурации путь представляет собой эталонный маршрут, то есть он объявляет, какой адрес маршрута будет загружаться микроприложением, а другой — это URL-адрес, который представляет связанные ресурсы приложения. Ресурсы пакетов могут быть разных типов. Это может быть ресурс JS или он может содержать пакеты CSS. В дополнение к JS и CSS, особенно когда такие фреймворки, как Angular, сильно зависят от логики содержимого HTML во время выполнения, мы также предоставляет способ напрямую установить запись для импорта html.
3.5 Принцип работы
3.5.1 Процесс
Во-первых, давайте взглянем на общий рабочий процесс после доступа к архитектуре микроинтерфейса. Мы можем посмотреть на эту картинку с двух точек зрения: одна точка зрения — это режим разработки микроприложения справа. Разработка микроприложений имеет независимый склад, независимые процессы разработки, тестирования и развертывания. После развертывания разработки и тестирования опубликованные продукты приложения единообразно регистрируются в приложении фреймворка.Эти продукты могут быть пакетами JS или html-ресурсами.
Слева показан общий процесс приложения фреймворка, который поддерживает регистрационную информацию микроприложения. Когда пользователь получает доступ к системе, в соответствии с зарегистрированной ранее информацией о маршрутизации он может точно сопоставить информацию о приложении, которое необходимо загрузить, загрузить ресурсы приложения в соответствии с соответствующей информацией и, наконец, отобразить приложение.
Когда пользователь щелкает, чтобы инициировать переход, если изменение маршрутизации вызывает внутренний переход приложения, приложение будет напрямую отображать страницу в соответствии с логикой маршрутизации внутри приложения. Если задействованы некоторые переходы между приложениями, он вернется к процессу поиска указанной выше маршрутизации.
3.5.2, правила маршрутизации
Далее мы разберем основной процесс в фреймворковом приложении.Во-первых, давайте разберемся, как осуществляется перехват маршрутизации. Перехват маршрутизации — важная возможность решения для микроинтерфейса.Если вы не перехватите маршрутизацию приложения, вы не сможете определить, какой ресурс приложения необходимо загрузить в данный момент, и не сможете решить, какой интерфейс отображать.
Правила маршрутизации в icestark относительно просты.Студенты, знакомые с react-router, легко обнаружат, что в их конфигурации много общего. Например, правила настройки пути и точного пути аналогичны правилам react-router.
Когда мы посещаем страницу приложения фреймворка, icestark выполняет внутреннее распределение маршрутизации. На приведенном выше рисунке регистрируются три конфигурации микроприложений при доступе к/sellerПри маршрутизации сопоставляется первая регистрационная информация, а при доступе/data или/messageКогда вторая регистрационная информация совпадает, при доступе/seller/aкогда? В результате совпал третий маршрут, обратите внимание на атрибут excat в первой конфигурации регистрации. Если вы установите путь в архитектуре микроприложения к/Микроприложение , то это фактически нижний маршрут для всей системы, и все конфигурации маршрутизации, которые не соответствуют зарегистрированному маршруту, будут отображаться по нижнему маршруту. Нижний маршрут будет использоваться в качестве целевой страницы, нижней части страницы 404 или страницы выхода в используемом сценарии.Как правило, это будет обычная страница, которая будет иметь сильную связь с приложением фреймворка. Так что на практике мы также используем нижнюю маршрутизацию в качестве рендеринга собственной маршрутизации фреймворка.
Почему такая операция распределения маршрута может быть завершена? Через изменение URL-адреса, как происходит внутренний захват и как определить, какое зарегистрированное приложение необходимо загрузить? Это включает в себя наш принцип перехвата маршрутизации.
3.5.3 Перехват маршрутизации
icestark связался с двумя типами событий маршрутизации, одним из которых является popstate и hashChange в API истории, а другим — событиями маршрутизации pushState и replaceState в окне.Эти два события запускаются, когда браузер выполняет операции вперед и назад.
Как только происходит переход между приложениями, соответствующая информация о маршрутизации может быть получена путем перехвата вышеуказанных событий, а затем, в соответствии с совпадением маршрутов, определяется, какое микроприложение монтировать.
Микроприложение может иметь несколько настроек маршрутизации. Если нет перехода между приложениями, ресурс не будет загружаться снова, поскольку текущее микроприложение совпадает. Логика перехода внутренней маршрутизации основана на самом микроприложении. Конфигурация маршрутизации определяет рендеринг.
Если конфигурация микроприложения всего фреймворкового приложения удалена, угнанный контент будет удален в это время и восстановлен в исходное состояние, тем самым завершая процесс всего приложения от основ маршрутизации до мониторинга изменений URL-адресов и загрузки микроприложений. . . .
3.6 Загрузка и рендеринг микроприложений
Как конкретно загружается и отображается микроприложение? Вышеприведенный код представляет собой логику преобразования icestark для микроприложений. Стоимость преобразования невелика. В основе всего две вещи. Одна — это жизненный цикл монтирования приложения, который выполняется после загрузки ресурсов приложения, а другая Жизненный цикл удаления приложения, после переключения приложения эта функция регистрации будет выполнена.
Вообще говоря, когда мы делаем SPA-приложение, нам не нужно заботиться о времени загрузки и выгрузки. Потому что ресурсы приложения обязательно будут загружены после загрузки, а при удалении приложения либо прыгает все приложение, либо закрывается весь браузер.
Однако в архитектуре микрофронтенда нужно знать логику выгрузки микроприложения, только из сценария React, если не определить его логику выгрузки нагрузки, при переключении микроприложения вполне вероятно, что будет выполняться много циклов.События и функции размонтирования и размонтирования компонентов не могут быть запущены, что приведет к некоторым побочным эффектам при выполнении других приложений.
Поэтому помимо основной логики рендеринга нам также нужно позаботиться о логике выгрузки микроприложения. Жизненный цикл регистрации будет взаимодействовать с логикой загрузки ресурсов и, наконец, завершит отрисовку или переключение микроприложения.
Когда микроприложение загружено, в середине будет выполняться слой кэширования ресурсов.Если ресурс не кэширован, icestark проанализирует ресурс в соответствии с информацией о конфигурации, зарегистрированной в приложении фреймворка. В целом, существует два способа настройки ресурсов: один — это URL-адрес, который может включать ресурсы JS и ресурсы CSS, а другой — запись в формате html, для которой требуется больше ресурсов. Могут быть отдельные JS, отдельные CSS и даже некоторые встроенные теги скрипта и теги стиля. После того, как ресурсы будут загружены, icestark вставит эти ресурсы в приложение фреймворка.
Прежде чем вставить метку ресурса, ресурсы приложения идентифицируются, потому что при переключении микроприложения необходимо знать, какие ресурсы связаны с приложением, и соответствующую информацию о ресурсах можно правильно найти с помощью идентификации ресурса. . После идентификации он, наконец, переходит к процессу монтирования приложения, который должен выполнить логику в зарегистрированном жизненном цикле registerAppEnter. Удаление приложения относительно просто. Найдите все ресурсы, которые необходимо удалить, в соответствии с идентификатором ресурса приложения. И выполнить функцию, прописанную в жизненном цикле registerAppLeave, которая завершает деинсталляцию всего микроприложения.
Кроме того, в процессе загрузки ресурсов микроприложения используется оценка кеша ресурсов.В некоторых бизнес-сценариях будут встречаться сценарии с низкой производительностью.Если ресурсы перезагружаются каждый раз для выполнения, это нанесет серьезный ущерб производительность браузера большая нагрузка.
Поэтому мы добавили процесс кэширования ресурсов посередине. Сохраняйте загруженные ресурсы и исполняемую логику в памяти и выполняйте функцию монтирования кэшированного микроприложения немедленно каждый раз, когда вы входите в кэшированное микроприложение, исключая процесс загрузки и выполнения ресурсов. Однако в этом процессе будет проблема: если ресурсы микроприложения не будут удалены, это фактически вызовет загрязнение ресурсов, в том числе загрязнение CSS и загрязнение JS. Таким образом, инициатива этой возможности передается разработчику.Если микроприложение необходимо кэшировать, необходимо правильно оценить, не будут ли загрязнены другие подключенные микроприложения.
3.7 Связь между приложениями
Далее кратко расскажем о схеме связи приложения. Просто сейчас многие студенты были больше обеспокоены этим.
Возможно ли какое-то общение или мониторинг событий между фреймворком и микроприложением или между микроприложением и микроприложением? На самом деле, исходя из принципа разработки микрофронтенда, мы не хотим слишком полагаться на возможности, предоставляемые фреймворковыми приложениями или другими микроприложениями для микроприложений. В некоторых сценариях некоторые разработчики хотят совместно использовать некоторую сложную логику, например общую логику utils, посредством связи между приложениями для достижения совместного использования функций между различными приложениями. Это технически осуществимо, но такой дизайн сильно повлияет на удобство сопровождения приложения.
Как мы упоминали ранее, каждое микроприложение может разрабатываться, развертываться и выпускаться независимо друг от друга. Если микроприложение сильно зависит от каких-то внешних возможностей, то при самостоятельной разработке необходимо создать макет среды разработки, что увеличит опыт разработки и стоимость трансформации.
icestark предоставляет механизм связи приложений, который рекомендуется использовать в более легком процессе разработки. Например, этот механизм связи обеспечивает согласованность только многоязычных настроек фреймворка и микроприложения.При переключении многоязычной настройки микроприложение может отслеживать изменения. Другой — обмен событиями между приложениями.В большинстве сценариев система микроприложений уведомляет приложение платформы об активном получении данных. Основываясь на таком сценарии, мы можем использовать возможность связи приложений для выполнения некоторых облегченных уведомлений.
3.8 Логика реализации
мы в@ice/stark-dataПакет npm обеспечивает возможность взаимодействия между приложениями.Ядро на самом деле представляет собой механизм EventBus.Взаимодействие между приложением фреймворка и микроприложением использует глобальную переменную, такую как окно, в качестве моста. Таким образом, можно получить доступ как к событиям или данным, добавленным микроприложением, так и к событиям или данным, добавленным приложением платформы.
3.9 Изоляция микроинтерфейса
Далее я расскажу о схеме изоляции в icestark. Прежде чем говорить о конкретной реализации, я хотел бы поделиться с вами некоторыми мыслями icestark при разработке схемы изоляции. Во-первых, мы считаем, что опыт НИОКР выше, чем изоляция. Если я предлагаю идеальное решение для изоляции, но оно требует от меня большого количества дополнительной логики обработки, то это решение определенно неприемлемо. Это сильно повлияет как на стоимость преобразования, так и на опыт разработки.
Другой принцип заключается в том, что сторонняя сцена выше, чем сторонняя сцена. Поскольку большинство сценариев применения микрофронтендов представляют собой двухсторонние сценарии, единую и независимую систему, редко можно встретить полностью неконтролируемый сторонний продукт. Логика и безопасность доступа двухстороннего сценария контролируются.
Основываясь на этих двух факторах, мы не обязательно говорим, что нам нужно реализовать идеальное решение для изоляции, прежде чем мы сможем это сделать. В сценарии, отвечающем базовым бизнес-требованиям, простое решение для изоляции может лучше позволить бизнесу двигаться вперед.
Вернемся к решению по изоляции. В основном это два сценария изоляции: один — изоляция CSS, а другой — изоляция JS.
3.9.1, изоляция стиля
С точки зрения изоляции стилей, большая изоляция основана на некоторых соглашениях, и используется недорогой метод изоляции, чтобы стили не влияли друг на друга.
Изоляция стиля делится на две части. Одна обычно представляет собой изоляцию стиля в собственном бизнес-коде разработчика. Рекомендуется изолировать бизнес-код с помощью метода CSSModule, который может автоматически генерировать имя стиля с суффиксом хеш. стили, созданные каждым отдельным приложением, в изоляции естественны.
Другим аспектом является изоляция базовых компонентов по стилю.Некоторые базовые компоненты в большинстве сообществ разрабатываются с учетом замены префиксов стилей. Базовые компоненты могут поддерживать метод префикса CSS.Вы можете добавить префикс ко всем стилям.На практике префикс фреймворка и префикс микроприложения различаются для полной изоляции стиля. Если есть стили, которые не поддерживают префикс CSS, мы также можем добавить пространства имен в стили компонентов с помощью возможностей сообщества PostCSS, а фреймворковые приложения и микроприложения стилизуются через разные пространства имен.
Давайте посмотрим на решение теневого DOM, почему мы не использовали теневой DOM напрямую. Основная причина заключается в том, что готового решения для теневого DOM недостаточно, и мы также постоянно изучаем опыт использования теневого DOM в реальном процессе разработки. В настоящее время теневой DOM по-прежнему имеет определенную стоимость для преобразования бизнеса.Например, если используемая базовая библиотека зависимых компонентов не предназначена для того, чтобы всплывающие слои, такие как Dialog, могли вставлять структуры в указанные узлы dom, всплывающие слои все уйдут из вашего текущего теневого DOM. После побега это нестилизованная коробка с пулями. Такой нестилизованный блок-маркер неприемлем для бизнеса, поэтому логика блока-маркера должна быть совместимой, и даже базовые компоненты должны быть изменены.
Другой заключается в том, что в сценарии React использование теневого DOM будет связано с проблемой механизма событий, поскольку механизм событий React делегирован документу, но на основе обработки теневого DOM он может блокировать события на своем хост-уровне. где вы визуализируете теневой DOM. Хотя у сообщества также есть соответствующие пакеты для некоторой обработки совместимости, это все равно будет связано с некоторыми затратами на реализацию для бизнеса. Помимо этого есть и другие проблемы. Например, CSS @font-face или некоторые свойства шрифта, svg будут иметь несовместимую сцену.
Несмотря на то, что с теневым DOM все еще остается много проблем, мы продолжим исследовать и постепенно улучшать эту область, и, по крайней мере, мы сможем предоставить готовое решение для включения теневого DOM без особых затрат.
3.9.2 Изоляция скрипта
Когда несколько пакетов приложений выполняются несколько раз, легко загрязнить глобальные переменные.Icestark реализует изоляцию скриптов через механизм прокси-песочницы.
Основной принцип песочницы Prxoy — блокировать прямой доступ к окну в коде в виде with + new Function, а также перехватывать доступ и запись в оконную переменную с помощью Proxy.Изоляция песочницы предотвращает код прямого доступа к окну.Объект, с помощью новой функции ES6 Proxy, логика получения/установки может быть настроена таким образом, что некоторые изменения глобальных переменных в окне могут быть записаны моментальными снимками, чтобы можно было восстановить микроприложение при переключении.
Кроме того, при инициализации некоторых приложений в окне будут установлены setTimeout и setInterval, если они не обрабатываются должным образом на этапе удаления, это повлияет на выполнение следующего смонтированного микроприложения. Поэтому для такого рода методов в песочнице проводится специальная обработка, соответствующий метод перехватывается до монтирования песочницы и восстанавливается при удалении.
3.9.3, трехсторонняя изоляция
Наконец, давайте поговорим о трехсторонней изоляции.Самый простой и безопасный способ изолировать ненадежные трехсторонние — это iframe. Эталонный маршрут может быть легко определен в icestark.path, а затем с помощью пользовательского метода рендерингаrenderВизуализируйте содержимое, связанное с iframe.
3.10 Микромодуль
Наконец, поговорим о возможности дополнить возможности микрофронтенда — микро модулях. Некоторые из технических решений, технических архитектур и решений, упомянутых выше, в основном представляют собой загрузку микроприложения, основное решение которого заключается в подключении одного приложения SPA к фреймворку. Каков сценарий микромодуля?
3.10.1 Три основных бизнес-сценария микромодулей
Первый сценарий — сценарий многомодульного сосуществования, для актуального требования, если необходимо реализовать многотабовое решение под техническую систему микрофронтенда. На основе исходного загруженного микроприложения открывается новая вкладка, а содержимое внутри обрабатывается независимым ресурсом пакета. Представьте, как будет выглядеть решение с наименьшими затратами? Достаточно ли, чтобы несколько модулей нормально отображались в разных местах? На самом деле это основное требование сосуществования нескольких модулей.
Второй сценарий заключается в построении комбинации модулей. Страница будет иметь информационный модуль, модуль формы и модуль списка. В некоторых сценариях внешнего мультиплексирования вывода, если доступ ко всей странице осуществляется напрямую, ее универсальность не особенно сильна, но если каждый модуль можно свободно комбинировать, страницы с различными потребностями можно комбинировать по мере необходимости.
Последний — модуль динамического рендеринга. Содержимое страницы определяется данными, возвращаемыми интерфейсом. Данные предоставят содержимое модулей, которые необходимо визуализировать, например сцену строительства беспроводной сети, которая на самом деле является сценой приложения микромодуля.
3.10.2, Архитектура микромодуля
icestark будет иметь четкое определение сценариев применения микромодулей, которые больше не будут разделять маршрутизацию. Вышеупомянутое микро-приложение представляет собой, по сути, SPA, в котором есть как минимум один маршрут или одна страница, но мы хотим, чтобы использование микромодулей было как можно более простым, потому что когда несколько модулей связаны с большим количеством маршруты, это усложнит обработку маршрутизации.
При стандарте модуля микромата непосредственно упакована в UMD, а пакет упакован в этот стандартный режим даже в виде пакета NPM, его можно использовать нормально. В дополнение к способу модуля экспорта по умолчанию, в дополнение к методу модуля экспорта по умолчанию, также необходимо определить жизненный цикл монтажа (размонтирования).
Сценарий приложения микрокомпьютера фактически является дополнением к микроприложению, которое больше подходит для более гранулированного функционального разделения и динамически выстраиваемых сцен.
4. Ценность для бизнеса
Выше было упомянуто много архитектурных проектов и решений.Может ли внедрение микроинтерфейсной архитектуры решить бизнес-проблемы, упомянутые в начале?
4.1 Анализ двух сценариев
Первый — это крупномасштабный сценарий с одним приложением, который имеет большой размер страницы и влияет на эффективность разработки, включая стоимость миграции стека технологий.
В сочетании с архитектурой микроинтерфейса мы можем разделить его на независимые приложения в соответствии с функциональным измерением. Дополнительные обновления бизнес- и технической архитектуры могут выполняться в отдельных приложениях по низкой цене.
Второй сценарий — рабочий стол, который больше подходит для решения проблем, связанных с опытом работы с продуктом и эффективностью работы. Архитектура микро-интерфейса может принести опыт независимого SPA, не нарушая процесс исследований и разработок независимой разработки и независимого развертывания. При этом разные приложения единообразно подключаются к приложению фреймворка, что также позволяет осуществлять определенный контроль над приложениями доступа, избегая некоторого дублирования построения и бесконтрольного выбора технологий.
Основываясь на двух приведенных выше сценариях, архитектура микроинтерфейса может дать свой ответ.
4.2. Бизнес-лендинг
На самом деле, icestark был проверен большим количеством компаний в Alibaba Group.В настоящее время он внедрил более 20 приложений на уровне платформы, охватывающих Taobao, Cainiao, Fliggy, бизнес-платформы и другие отделы.В то же время, Сообщество также может предоставить icestark дополнительные предложения по сценариям ведения бизнеса.
4.3. Резюме
Наконец, кратко изложите техническую архитектуру микроинтерфейса, которая предлагает решение по оптимизации технической архитектуры для крупномасштабных сценариев отдельных приложений и рабочих мест (система портала), а также устраняет проблемы и узкие места, с которыми сталкивается текущая система, путем внедрения технических архитектура микро-фронтенда Наконец, система может поддерживаться и повторяться в течение длительного времени.
4.4. Контактная информация
Если вас интересует архитектурное решение Feibing для интерфейсной части и техническая микроархитектура для внешней части, вы можете присоединиться к этой группе сообщества и общаться друг с другом. Добро пожаловать в Айсстарк:GitHub.com/ice-speaker/ice…
вопросы и ответы
Как icestark определяет ресурсы, которые нужно загрузить соответствующему микроприложению, перехватив маршрут?
icestark отслеживает изменения маршрутизации путем перехвата маршрута.Содержимое перехвата включает pushState и replaceState в API истории, а также события маршрутизации оконного браузера popstate и hashChange. После изменения маршрута информация об изменении URL-адреса получается путем перехвата, а затем сопоставляется в соответствии с правилами маршрутизации, зарегистрированными микроприложением. Если совпадение прошло успешно, прочитайте информацию о ресурсе, установленную микроприложением для загрузки.
Я также использовал with для реализации песочницы, но упакованный babel всегда будет сообщать об ошибке. Это не разрешено быть запросом в строгом режиме. Как вы это решили?
Песочница icestark выполняется на основе формы with + new Function. В настоящее время нет проблем с сообщением об ошибках в строгом режиме. Вы можете подробно посмотреть сценарии ошибок.
В этой статье используетсяmdniceнабор текста