За последние несколько недель, после публикации статьи Кэма Джексона о микрофронтенде в блоге Мартина Фаулера, о микрофронтенде говорили повсюду. Как «эксперт» по микро-фронтенду, я также делюсь: как реализовать микро-фронтенд.
Микроинтерфейс — это архитектура, аналогичная микросервисам, которая применяет концепцию микросервисов к стороне браузера, то есть одностраничное интерфейсное приложение преобразуется из единого монолитного приложения в приложение, объединяющее несколько небольшие интерфейсные приложения в одно. Каждое внешнее приложение также может быть независимо разработано и развернуто независимо. В то же время их также можно разрабатывать параллельно, разделяя компоненты — этими компонентами можно управлять через NPM или Git Tag, Git Submodule.
Зачем нужны микрофронтенды?
Микрофронтенды — это не серебряная пуля, и, как и микросервисы, они создают множество проблем.
- Миграция устаревшей системы. Решение устаревших систем — самая важная причина, по которой люди выбирают микроинтерфейсные решения.
- Совокупность интерфейсных приложений. Микросервисная архитектура может отделить зависимости между серверными службами. С другой стороны, микроинтерфейсы сосредоточены на объединении интерфейсных приложений.
- Активное развитие. Новая технология, раз уж она очень живая, то изучайте ее.
Реализация микро-фронтенда означает разделение фронтенд-приложения. Цель разделения приложений состоит не только в том, чтобы хорошо выглядеть в архитектуре, но и в повышении эффективности разработки.
С этой целью микрофронтенды имеют ряд преимуществ:
- Автономность приложений. Нужно только следовать единой спецификации интерфейса или фрейму, чтобы система, интегрированная вместе, не зависела друг от друга.
- единая ответственность. Каждое внешнее приложение может сосредоточиться только на тех функциях, которые ему необходимы.
- Стек технологий значения не имеет. Вы можете использовать React и Vue одновременно с Angular.
- Разделение приложений зависит от конструкции инфраструктуры.Когда большое количество приложений зависит от одной и той же инфраструктуры, обслуживание становится проблемой.
- Чем меньше степень детализации разделения, тем сложнее архитектура и выше стоимость обслуживания.
- Как только стек технологий диверсифицирован, это означает, что стек технологий хаотичен.
Ведь серебряной пули не существует.
Как спроектировать архитектуру микро-фронтенда?
В нынешнем виде разработка микрофронтенд-приложения — непростая задача — лучших практик пока нет. В разных случаях посадки используются разные решения. Основная причина этого в том, что каждый проект сталкивается с разными ситуациями и использует разные технологии. Для этого нам нужно понять некоторые основные шаблоны микроинтерфейса.
Архитектурные узоры
С точки зрения взаимосвязи между микроинтерфейсными приложениями существует два типа: базовый режим (управляемый) и самоорганизующийся. Они также соответствуют разным архитектурным образцам двух:
- Режим док-станции. Управление другими приложениями через основное приложение. Сложность дизайна невелика и проста в использовании, но универсальность низкая.
- режим самоорганизации. Заявки равны, и нет модели взаимного управления. Конструкция сложная и неудобная в реализации, но универсальность высокая.
Что касается текущей ситуации, то пьедесталный режим более удобен в реализации, и решений здесь довольно много.
Вне зависимости от метода необходимо предусмотреть механизм поиска приложений, который в микрофронтенде называется сервисом.Режим реестра. Подобно микросервисной архитектуре, независимо от того, какой метод микроинтерфейса используется, также требуется служба реестра приложений, которая может быть файлом конфигурации с фиксированным значением, например файлом JSON, или динамически обновляемой конфигурацией. и Или динамическая служба. В основном он делает следующее:
- Обнаружение приложения. Пусть основное приложение найдет другие приложения.
- Регистрация приложения. То есть функция предоставления новых приложений микро-фронтенда и регистрация в реестре приложений.
- Регистрация стороннего приложения. То есть сторонние приложения могут получить доступ к системе.
- Права доступа и другие сопутствующие настройки.
Когда приложение развернуто, его можно зарегистрировать в службе реестра. Если приложение управляется на основе реестра, для разработки удобнее использовать режим дока.
концепт дизайна
В процессе практики микро-фронтенда я обнаружил следующие моменты, на которые нужно обращать внимание в процессе проектирования:
- Централизация: Реестр приложений. Этот реестр приложений содержит каждое приложение и соответствующую запись. Во внешнем домене прямым представлением записи может быть маршрутизация или соответствующее сопоставление приложений.
- Определить приложения. Нам нужен идентификатор для идентификации разных приложений, чтобы указанное приложение можно было найти при установке и удалении. Простой шаблон — называть приложения по закону Конвея.
- Управление жизненным циклом приложений.
- Высокая сплоченность, низкая связанность.
Жизненный цикл
Максимальная разница между микроархитектурой front-end и микроархитектурой back-end также заключается в жизненном цикле. Приложение Micro-end — это клиентское приложение, каждое приложение имеет свой жизненный цикл:
- Загрузите, решите, какое приложение загрузить, и привяжите жизненный цикл
- bootstrap, получить статические ресурсы
- Монтируйте, устанавливайте приложения, такие как создание узлов DOM
- Выгрузить, удалить жизненный цикл приложения
- Размонтировать, удалить приложение, например, удалить узлы DOM, отменить привязки событий
Содержание этой части на самом деле является одной из сложностей микро-интерфейса, как правильно загрузить приложение — в конце концов, каждый интерфейсный фреймворк отличается, и требуемый метод загрузки также отличается. Когда мы решаем поддерживать несколько фреймворков, нам нужно более подробно остановиться на этом разделе.
Как разделить?
Затем нам предстоит столкнуться с проблемой: как разделить приложение.
технический способ
С технической точки зрения архитектура микроинтерфейса может быть реализована следующими способами:
- распределение маршрута. Запрос направляется соответствующему приложению через функцию обратного прокси-сервера HTTP-сервера.
- Интерфейсные микросервисы. Конструктивные механизмы связи и загрузки в верхней части различных каркасов для загрузки соответствующих приложений на одной странице.
- Микроприложения. Благодаря разработке программного обеспечения в среде развертывания и построения несколько независимых приложений объединяются в одно приложение.
- Виджеты. Разработайте новую систему сборки для встраивания некоторых бизнес-функций в независимый фрагмент кода, который нужно будет загружать только удаленно.
- Фронтальная контейнеризация. Держите другие интерфейсные приложения, используя iFrame в качестве контейнера.
- Компонентизация приложения. Создавайте межфреймовые клиентские приложения с помощью технологии веб-компонентов.
Хотя существует множество способов реализации, все они адаптированы в соответствии со сценой. В некоторых сценариях может не быть подходящего метода, в некоторых сценариях можно использовать несколько решений одновременно.
распределение маршрутов
**Микрофронтенд с распределенным маршрутом, т. е. распределение различных сервисов между разными независимыми клиентскими приложениями посредством маршрутизации. **Обычно это можно реализовать через обратный прокси-сервер HTTP-сервера или маршрутизацию, поставляемую с инфраструктурой приложения. Как показано ниже:
На данный момент архитектура с распределенными маршрутами должна быть наиболее приемлемым и простым решением для «микроинтерфейса». но
Интерфейсные микросервисы
**Внешний микросервис — это реализация микросервисной архитектуры во внешнем интерфейсе. Каждое внешнее приложение полностью независимо (технический стек, разработка, развертывание и независимое построение) и работает автономно. Наконец, полная система собирается по модульному принципу. ** Его архитектура показана на следующем рисунке:
Использование этого метода означает, что на странице одновременно выполняются два или более интерфейсных приложения. В схеме распределения маршрутизации на страницу приходится только одно приложение.
Комбинаторная интеграция: микроприкладная
**Микроприложение, то есть при разработке приложения существуют в виде одиночных, микроприложений, а во время выполнения эти приложения сливаются через систему построения и объединяются в новое приложение. ** Его архитектура показана на следующем рисунке:
Микроприложение — это скорее метод разработки программного обеспечения для завершения разработки интерфейсных приложений, поэтому его также можно назвать комбинированной интеграцией. Для крупномасштабного клиентского приложения используемая архитектура часто заключается в использовании бизнес-каталога в качестве основного каталога, а затем размещении связанных компонентов в бизнес-каталоге и наличии некоторых общих общих шаблонов.
виджеты
**Виджет (виджет) относится к фрагменту кода, который может быть непосредственно встроен в приложение, предварительно компилируется разработчиком и не требует модификации или компиляции при загрузке. **Виджетизация под микроинтерфейсом означает, что каждая бизнес-команда пишет свой собственный бизнес-код и развертывает (загружает или размещает) скомпилированный код на назначенный сервер.Во время выполнения нам нужно только загрузить соответствующий бизнес-модуль. Соответственно, при обновлении кода нам нужно обновить только соответствующий модуль. На следующем рисунке схематически представлена виджетизированная архитектура:
В эпоху неодносторонних приложений особенно легко реализовать решение с виджетами. Соответствующий код JavaScript загружается удаленно, выполняется в браузере, генерируется соответствующий компонент и встраивается в соответствующую часть страницы. То же самое верно и для бизнес-компонентов: мы пишем наши бизнес-компоненты заранее, а затем отвечаем и выполняем, когда нужны соответствующие компоненты.
Фронтальная контейнеризация
Интерфейсный контейнер: iframe
iframe — это очень «старая» технология, которую все считают распространенной, но она всегда хорошо работала. Он может эффективно встраивать другую веб-страницу/одностраничное приложение в текущую страницу, CSS и JavaScript между двумя страницами изолированы друг от друга - за исключением кода части связи родитель-потомок iframe, код между ними полностью не- мешающие друг другу из. iframe эквивалентен созданию совершенно новой независимой среды хостинга, похожей на изоляцию песочницы, что означает, что интерфейсные приложения могут работать независимо друг от друга.
Создавайте с помощью веб-компонентов
Веб-компоненты — это другой набор технологий, которые позволяют разработчикам создавать повторно используемые пользовательские элементы (их функциональность инкапсулирована вне кода) и использовать их в веб-приложениях.
Основным фактором, который в настоящее время мешает продвижению технологии веб-компонентов, является степень поддержки браузерами. В браузерах Chrome и Opera поддержка веб-компонентов хорошая, но уровень поддержки браузеров Safari, IE и Firefox не так идеален.
разделение бизнеса
Как и в случае с микросервисами, разделение границ интерфейса — непростая задача. В настоящее время распространены следующие способы разделения микрофронтендов:
- Разделить по бизнесу.
- Разделить по разрешениям.
- Разделить по частоте изменений.
- Разделить по организационной структуре. Используйте закон Конвея для дальнейшего разделения интерфейсных приложений.
- Следите за отделом серверных микросервисов. Практика доказала, что DDD и event storm — достаточно эффективный режим разделения микро-фронтенда back-end, а также достаточно эффективен для front-end — непосредственное отслеживание back-end сервисов.
Каждый проект имеет свою особую предысторию, и способ сегментации микрофронтендов разный. Несмотря на то, что типы проектов похожи, есть некоторые тонкие различия.
Помимо микро-фронтендов
Если вам сложно работать с микроинтерфейсами, есть несколько отличных архитектурных шаблонов, которые можно использовать.
микроархитектура приложения
Микроархитектура приложения — это шаблон архитектуры внешнего интерфейса, который интегрируется во время разработки, разделяется во время создания и разделяется во время выполнения. То есть микроархитектура приложения начинается сВ одном коде создавайте несколько наборов целевого кода, подходящего для разных сред.. В реализации это один из:
- Разделить схему во время сборки.
- Архитектура удаления кода. Улыбнитесь, сформируйте каждое внешнее приложение, удалив код.
- Готовая микро-интерфейсная архитектура. То есть его можно в любой момент разбить на несколько интерфейсных приложений.
Из-за схожести с приложением микро, его обгонят по сравнению с микроприложениями. Другое дело с приложением micro, приложение представляет собой приложение micro-split при построении, а не разделение приложения в локальном режиме. Точно так же он также основан на варианте реализации сконструированной прикладной сплит-системы.
который:Микроприложение представляет собой готовую к слиянию архитектуру. А приложение микро, это структура, которую можно разделить в любой момент.
Это не просто архитектурный паттерн для передней части, это архитектурный паттерн для задней части..
Чистая интерфейсная архитектура
Чистая архитектура — это архитектурный шаблон, предложенный Робертом С. Мартином в 2012 году. У него есть некоторые характеристики: независимость от фреймворка, возможность тестирования, независимость от пользовательского интерфейса, независимость от базы данных и независимость от внешних агентств.
Для внешней архитектуры Чистая Архитектура на самом деле означает: Чистая Архитектура + MVP + Компонентизация. Как показано ниже:
Учитывая масштаб приложения, вот пример Angular + TypeScript:
Этот архитектурный шаблон особенно подходит для:Команды внутри организации, которые пишут как интерфейс, так и серверную часть. Интерфейсные и внутренние API легко сопоставить, и можно использовать вариант использования в качестве антикоррозийного слоя.
Серебряной пули не существует. Следует отметить, что для небольших команд недостатки, которые он приносит, могут намного перевешивать преимущества — много избыточного кода. Хотя Angular Schematics может генерировать код с помощью параметров, эта многоуровневая архитектура по-прежнему слишком сложна и трудна для использования в простых приложениях. Для проектов, в которых не пишутся тесты, варианты использования также не приносят тех преимуществ, которые они обещают.
В заключение
Микрофронтенды — это не серебряная пуля, и в настоящее время нет лучших практик, но это отличная возможность для обучения.
Выдержка из «Архитектура внешнего интерфейса: от начала работы до микроинтерфейсов»