В этой статье будет использоваться теоретическое введение для общего понимания концепции микроинтерфейса.Большая часть теоретических знаний не будет слишком обширной.Если читатели заинтересованы в некоторых деталях, они могут оставить сообщение или выполнить поиск связанных понятий. .
Что такое микрофронтенд?
Микрофронтенды — это архитектура, похожая на микросервисы, которая применяет концепцию микросервисов к стороне браузера, то есть превращает веб-приложение из единого монолитного приложения в приложение, объединяющее несколько небольших интерфейсных приложений в одно. Каждое внешнее приложение также может работать независимо, разрабатываться и развертываться независимо.Micro-front-end — это не просто front-end фреймворк или инструмент, а набор архитектурных систем., эта концепция была впервые предложена в конце 2016 года, вы можете обратиться к поиску Micro-Frontends в Google, верхней части рейтингаСообщение в блоге от micro-frontends.org, в котором предлагается ранняя модель микро-интерфейса.
Почему существуют микрофронтенды
Появление любой новой технологии заключается в решении технических болевых точек при существующих сценариях и требованиях, и микрофронтенд не исключение:
- Разделить и уточнить: В текущей области фронтенда одностраничное приложение (SPA) является одной из самых популярных форм проектов, и с течением времени и обогащением функций приложения одностраничные приложения перестают быть одиночными, а становятся более крупными. и крупнее.Сложно обслуживать, часто приходится менять одно место и двигать весь корпус, да и стоимость публикации все выше и выше. Смысл микрофронтенда в том, чтобы разделить эти огромные приложения, а затем отделить их друг от друга.Каждая часть может поддерживаться и развертываться отдельно для повышения эффективности.
- Интеграция исторических систем: Во многих компаниях есть более или менее исторические проекты.Большинство из этих проектов основаны на системах управления B-side, которые используют старые фреймворки, подобные (Backbone.js, Angular.js 1).Систему необходимо интегрировать в использовать новую структуру, которую нельзя отбрасывать, и у нас нет причин тратить время и энергию на переписывание старой логики. Микро-интерфейс может интегрировать эти системы, и в то же время он совместим с новой и старой системами для параллельной работы, в основном не изменяя логику.
Какие есть решения для реализации микрофронтендов?
Основываясь исключительно на понимании концепции, легко подумать, что важная идея реализации микро-фронтенда состоит в том, чтобы разобрать и интегрировать приложение, как правило, родительское приложение плюс несколько подприложений, а затем использовать аналогичный Nginx для настройки перенаправление разных приложений или использование iframe Для интеграции нескольких приложений вместе и т. д. это на самом деле решения для реализации микроинтерфейса. Сравнение между ними следующее:
| строить планы | описывать | преимущество | недостаток |
|---|---|---|---|
| Переадресация маршрута Nginx | Настройте обратный прокси через Nginx для отображения разных путей к разным приложениям.Например, www.abc.com/app1 соответствует app1, а www.abc.com/app2 соответствует app2.Само это решение не относится к преобразованию интерфейсный уровень Подробнее Что такое конфигурация эксплуатации и обслуживания. | Просто, быстро и легко настроить | Обновление браузера запускается при переключении приложений, что влияет на работу |
| вложение iframe | Родительское приложение представляет собой отдельную страницу, а каждое дочернее приложение вложено в iframe, а связь родитель-потомок может использовать postMessage или contentWindow. | Реализация проста, а суб-приложения имеют свои песочницы, естественно изолированные и не влияющие друг на друга. | отображение стилей iframe, совместимость и т. д. имеют ограничения, слишком простые и низкие |
| Web Components | Каждое подприложение должно использовать чистую технологию веб-компонентов для написания компонентов, что является новым режимом разработки. | Каждое под-приложение имеет независимый скрипт и css, а также может быть развернуто отдельно | Из-за высокой стоимости исторической трансформации системы связь между подприложениями более сложна и ее легко наступить на яму. |
| Комбинированное распределение маршрутизации приложений | Каждое дочернее приложение создается и развертывается независимо, а родительское приложение обрабатывает управление маршрутизацией, загрузку приложений, запуск, выгрузку и механизмы связи во время выполнения. | Чистая трансформация интерфейса, хороший опыт, можно переключаться без восприятия, а суб-приложения изолированы друг от друга. | Его необходимо спроектировать и разработать.Поскольку родительские и дочерние приложения работают на одной странице, необходимо решить такие технические вопросы, как конфликты стилей дочерних приложений, загрязнение переменными объектами и механизмы связи. |
В вышеописанном варианте осуществления каждый со своими собственными преимуществами и недостатками наиболее примитивным обратным прокси-сервером NGINX расположен для разделения с точки зрения уровня доступа к системе, но требует конфигурации работы и обслуживания и вложенного IFrame является самая простая и скорая программа Но также не могут избежать недостатков IFRame, а программа веб-компонентов требует много затрат на ремонт, окончательная стоимость реконструкции среднего составных приложений распределена схема распределенного маршрутизации и может соответствовать большинству потребностей, не влияет на опыт каждого фронта Конечные приложения, каждая услуга присутствует схема, обычно используемая, описана позже в этом варианте осуществления, в основном описанном в зависимости от этого.
Из каких модулей состоит микрофронтенд?
Исходя из вышеизложенного, текущий микро-интерфейс в основном использует комбинированную схему маршрутизации приложений.Основой этой схемы является идея «главный-подчиненный», то есть она включает в себя базовое (MainApp) приложение и несколько микро-(MicroApp) приложений. приложений, а базовое приложение большое.Большинство из них представляют собой интерфейсные проекты SPA, в основном отвечающие за регистрацию приложений, сопоставление маршрутов, доставку сообщений и т. д., тогда как микроприложения являются независимыми интерфейсными проектами. Эти проекты не ограничиваются для разработки React, Vue, Angular или JQuery.Каждое микро-приложение регистрируется в базе.В приложении оно управляется базой, но к нему также можно получить доступ отдельно, если оно удалено из базы.Базовый процесс показано на следующем рисунке:
Когда вся микроинтерфейсная структура запущена, взаимодействие с пользователем похоже на показанное ниже:
Краткое описание состоит в том, что в базовом приложении есть несколько пунктов меню. Щелчок по каждому пункту меню может отображать соответствующее микро-приложение. Переключение этих приложений осуществляется чисто внешним интерфейсом, поэтому, исходя из текущего решения, микро- Передняя база Каркас сиденья должен решать следующие проблемы:
- Проблема распределения коммутации маршрутов.
- Проблемы с изоляцией основного микроприложения.
- проблемы со связью.
Эти вопросы объясняются ниже.
Распределение маршрутов для микрофронтендов
Как базовое приложение микроинтерфейса, оно является входом всего приложения и отвечает за отображение текущего микроприложения и пересылку других микроприложений маршрутизации. обычно состоит из следующих шагов:
- Как базовое SPA-приложение представляет собой набор чистых front-end проектов.Чтобы отобразить страницу микро-приложения, помимо использования iframe, сначала нужно подтянуть содержимое страницы микро-приложения, что требуетМеханизм дистанционного вытягивания.
- Механизмы удаленного натяжения обычно используют API-интерфейс FETCH, чтобы сначала получить микровыделенный HTML-контент, а затем извлечь микрозависимый JavaScript и CSS, используя метод EVAL для запуска JavaScript, и добавить CSS- и HTML-контент к базе. слева в область микродемонстрации, и когда микроустройства переключаются, синхронный удаляет содержимое, которое является презентацией текущего приложения.
- Конечно, этот процесс будет включать загрязнение стилей CSS и загрязнение глобальных объектов JavaScript.Проблема изоляции будет рассмотрена позже.В настоящее время существуют готовые библиотеки для этого процесса механизма удаленного извлечения.Вы можете обратиться кimport-html-entryа такжеsystem.js.
Для распределения маршрутизации возьмем в качестве примера приложение SPA на пьедестале, разработанное vue-router, в основном следующий процесс:
- Когда путь браузера изменится, vue-router будет прослушивать событие hashchange или popstate, чтобы получить время переключения маршрута.
- Маршрутизатор базы получает это изменение первым. Запрашивая регистрационную информацию, он может получить микроприложение, на которое пересылается. После некоторой логической обработки модифицированный метод хеширования или метод pushState используется для отправки информацию на маршрут микроприложения.Приложение может вручную отслеживать получение событий hashchange или popstate или использовать React-router и vue-router, чтобы взять на себя маршрутизацию, а последующая логика контролируется самим микроприложением.
Изоляция приложений для микроинтерфейсов
Проблемы изоляции приложений в основном делятся на основное приложение и микроприложение, изоляцию среды выполнения JavaScript между микроприложением и микроприложением и изоляцию стилей CSS.Давайте сначала поговорим об изоляции CSS.
Изоляция CSS: Когда основное приложение и микроприложение отображаются на одном экране, некоторые стили могут загрязнять друг друга. Если вы хотите полностью изолировать загрязнение CSS, вы можете использовать модуль CSS или пространство имен, чтобы присвоить каждому модулю микроприложения определенный префикс. убедитесь, что они не будут мешать друг другу, вы можете использовать плагин postcss для веб-пакета, чтобы добавить определенный префикс при упаковке.
Для изоляции CSS между микро-приложениями и микро-приложениями это очень просто: каждый раз, когда приложение загружается, все ссылки и стили приложения помечаются. После удаления приложения синхронизируйте соответствующую ссылку и стиль на странице удаления.
Изоляция JavaScript: Всякий раз, когда JavaScript микроприложения загружается и запускается, его ядро на самом деле является модификацией глобального объекта Window и изменениями некоторых глобальных событий, таких как jQuery, после запуска js он будет монтироватьwindow.$Objects и для других библиотек React, Vue не является исключением. Для этого необходимо максимально исключить подобные конфликты и влияния при загрузке и выгрузке каждого микроприложения, наиболее распространенным подходом является использование механизма песочницы (SandBox).
Суть механизма песочницы заключается в том, чтобы позволить локальной среде выполнения JavaScript контролировать доступ и модификацию внешних объектов, то есть независимо от того, как выполняется внутренняя операция, внешние объекты не будут затронуты. Обычно модуль vm можно использовать на стороне Node.js, в то время как для браузера необходимо объединить ключевое слово with и объект window.Proxy для реализации изолированной программной среды на стороне браузера.
Обмен сообщениями для микроинтерфейсов
Существует много способов связи между приложениями, но, конечно, для связи между несколькими отдельными микроприложениями промежуточные носители или глобальные объекты по существу остаются неразделимыми. Таким образом, механизм связи в режиме подписки на сообщения (pub/sub) очень удобен. Событие центра событий будет определено в базовом приложении, и каждое микроприложение будет регистрировать событие отдельно. центр будет распределять его равномерно.Это составляет основной механизм связи, и поток выглядит следующим образом:
Конечно, если пьедестал и микроприложения используют React или Vue, их можно использовать в сочетании с Redux и Vuex для связи между приложениями.
Какие существуют фреймворки для микрофронтендов?
Основываясь на тщательно проработанной общей концепции и теории внешнего интерфейса, в отрасли существует множество сред, помогающих разработчикам легко интегрировать архитектуру внешнего интерфейса, например следующие:
- Mooa: Сервисный микрофреймворк на основе Angular.
- Single-Spa: Самая ранняя среда микроинтерфейса, совместимая с различными стеками интерфейсных технологий.
- Qiankun: Основанная на Single-Spa, Alibaba представляет собой микроинтерфейсную среду с открытым исходным кодом.
- Icestark: Alifeibing micro front-end framework, совместимый с различными стеками передовых технологий.
- Ara Framework: среда микро-интерфейса, расширенная за счет рендеринга на стороне сервера.
Вышеуказанные фреймворки, автор не будет здесь слишком распространяться, если интересно, можете попробовать сами.
Использовать ли микро-интерфейс
Micro-end помогает разработчикам решать практические задачи, но для каждого бизнеса подходит ли использование micro-end, и правильно ли использовать micro-end, или нужно следовать некоторым из следующих принципов:
-
Лучшими сценариями использования микроинтерфейсов являются некоторые системы управления на стороне B, которые совместимы с интеграцией старых систем и интеграцией новых систем, не влияя на исходный интерактивный опыт.
-
Общий микро-фронтенд — это не только интеграция системы, а улучшение всей системы микро-фронтенда, включающее в себя:
1): Возможность автоматического развертывания базовых приложений и микроприложений.
2): Возможности управления конфигурацией микроприложений.
3): Возможности локальной разработки и отладки.
4): онлайн-мониторинг и статистические возможности и т. д.
Только когда вся система возможностей установлена, можно сказать, что весь процесс системы микроинтерфейса совершенен.
-
Когда выясняется, что использование микрофронтендов снижает эффективность, а простые изменения усложняются, значит, микрофронтенды неприменимы.