Эта статья объяснит предысторию рождения микро-интерфейса, подробно объяснит причину концепции микро-интерфейса и его глубокое понимание, после прочтения этой статьи я полагаю, что у вас есть более полное представление о микро-интерфейсе. , понять, какие проблемы он может решить для вашей команды и всего предприятия, какую прибыль он приносит.
1. Предпосылки
В настоящее время многие предприятия в основном физически изолируют код приложения, внедряют одно приложение и одну библиотеку, замыкают цикл развертывания и обновляют тестовую среду, предварительную среду и формальную среду. Поэтому наше обсуждение основано на различных приложенияхразные библиотекиа такжеАвтономное развертываниеВ случае, как добиться несколькихзаявлениемеждуОбмен ресурсами?
Раньше чем больше методов обработки былоформа пакета npmИзвлечение и ссылка, например, между несколькими проектами приложений, может быть модуль бизнес-логики или другие, которые можно использовать повторно, поэтому они извлекаются, управляются и используются в виде пакетов npm. Но это приносит следующие проблемы:
- Неэффективность публикации. Если вам нужно повторить логический бизнес в пакете npm, вам нужно сначала опубликовать пакет npm, а затем обновить версию пакета npm для каждого приложения, использующего пакет npm, а затем собрать и опубликовать его отдельно.громоздкий процесс. Если задействовано больше приложений, будет потрачено больше рабочей силы и усилий.
- Сотрудничество в нескольких командах может быть нерегулярным. Пакет npm, содержащий общий модуль, является общим активом, и «все» им владеют, но на практике это обычно означает, что он никому не принадлежит. это будет скорополный беспорядкаизнепоследовательный стилькод без четких соглашений или технического видения.
Эти вопросы заставили нас осознать, что масштабирование фронтенд-разработки для облегчениянесколько командМогуПараллельная разработкаБольшой и сложный продукт – этоважный, но сложныйизпроблема.
Итак, еще в 2016 году родилась концепция микро-фронтенда.
2. Концепция микроинтерфейса
Официальный сайт Micro FrontendsКонцепции микроинтерфейса определены:
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
перевести на китайский:
отОфициальный сайт Micro FrontendsМожно понять, что концепция микроинтерфейса происходит отМикросервисОн является производным от расширения концепции обслуживания, отказа от крупномасштабного монолитного подхода и разложения интерфейса в целом на небольшие и простые блоки, которые можноНезависимая разработка, тестирование и развертывание, в то же времяполимеризацияЧтобы продукт появился перед покупателями. Можно понять, что микро-фронтенд — этоВозможна доставка самостоятельнонебольшое внешнее приложениеполимеризацияв целомархитектурный стиль.
Стоит отметить несколько моментов:
- микро интерфейсне конкретная технология, но интегрирует приемы, стратегии и методы, возможно, с каркасами, вспомогательными плагинами и нормами для ограничения такихЭкосфераформа, это макроскопическаяАрхитектура. Эта архитектура в настоящее время имеетРазличные варианты, есть свои плюсы и минусы, но пока применим текущий бизнес-сценарий, это хорошее решение.
- микро интерфейсОтсутствие ограничений стека технологий. Дизайн каждого микроинтерфейсного решения основан на реальных потребностях. Если несколько команд используют стек технологий реагирования единообразно, может не быть требований к использованию стека кросс-технологий решения микроинтерфейса; если несколько команд используют стек технологий реагирования и vue одновременно, требования к стеку кросс-технологий для микро-интерфейса может быть относительно высоким.
3. Преимущества микроинтерфейса
Обновление синхронизации
Сравнивая метод пакета npm с методом извлечения, давайте поймемОбновление процессов и эффективностиважность. Поскольку микро-интерфейс представляет собой совокупность нескольких подприложений, если несколько бизнес-приложений полагаются на функциональные модули одного и того же приложения-службы, необходимо обновлять только приложение-службу, а другие бизнес-приложения можно обновлять немедленно, что сокращает время ожидания. процесс обновления и экономия стоимости обновления.
Инкрементное обновление
Из-за исторической нагрузки некоторые команды до сих пор используют устаревшие и огромныеФронтальная монолитная модель, сдерживается устаревшим стеком технологий или качеством кода, написанного в спешке, до такой степени, что люди хотят отказаться от переписывания. дляИзбегайте риска полной перезаписи, мы более склонны конвертировать старые приложенияремонт шаг за шагом, продолжая предоставлять нашим клиентам новые функции.
Микрофронтенды дают нам больше свободы в принятии решений о частях продукта.независимое решение, чтобы команда могла постоянно добавлять новые функции и вносить небольшие изменения в исходное целое, чтобы наша архитектура, зависимости и взаимодействие с пользователем могли бытьИнкрементное обновление.
Кроме того, если в основной структуре есть критическое обновление, несовместимое с совместимостью, каждый микро-интерфейс может выбрать обновление, когда это необходимо, вместо того, чтобы прерывать текущую разработку и немедленно обновляться. Если мы хотим попробовать новые технологии или новые способы взаимодействия, общее влияние будет меньше.
Простая несвязанная кодовая база
каждый человекПроект микро-фронтендаРепозиторий исходного кода будет далеко неменьше, чемОдинМонолитный фронтенд проектрепозиторий исходного кода. Эти небольшие кодовые базы будутлегче развивать. Что еще более важно, мы избегаем непреднамеренной неуместной связи между несвязанными компонентами. Расширяя границы приложения доУменьшить возникновение таких случайных соединений.
Конечно, автономный, высокоуровневый архитектурный подход (такой как микроинтерфейсы) не предназначен для замены старого доброго кода чистыми спецификациями. Мы не пытаемся избежать оптимизации кода и улучшения качества кода. Вместо этого мы усложняем принятие неверных решений,Повысить вероятность правильного решения, тем самым ставя нас в ловушку успеха. Например, мы усложняем совместное использование моделей предметной области через границы, поэтому разработчики вряд ли будут это делать. Точно так же микрофронтенды заставляют вас иметь четкое и продуманное понимание того, как данные и события передаются между различными частями вашего приложения, что мы давно должны были начать делать!
Автономное развертывание
Как и микросервисы, микрофронтендыАвтономное развертываниеэто ключ. Это уменьшает объем развертывания и, следовательно, связанные с ним риски. Независимо от того, где размещен ваш интерфейсный код, у каждого микроинтерфейса должен быть собственный канал непрерывной доставки, который можно построить, протестировать и развернуть на всем пути к производству. Мы должны быть в состоянии развернуть каждый микросервис, не принимая во внимание другие кодовые базы или каналы. Даже если исходный монолитный проект будет исправлен и выпущен вручную ежеквартально, или другие команды отправят незаконченный или проблемный код в свою основную ветку, это не повлияет на текущий проект. Если проект микрофронтенда готов к производству, он должен иметь эту возможность, и решение остается за командой, которая его создает и поддерживает.
автономная команда
Преимущество высшего порядка отделения нашей кодовой базы от цикла выпуска состоит в том, что мыполностью независимая команда, могут участвовать в разработке, производстве и последующем процессе собственной продукции. Каждая команда имеет все ресурсы, необходимые для создания ценности для клиентов, что позволяет имбыстро и эффективнодействие. Чтобы достичь этого, наша команда должнаБизнес-функцииРазделены по вертикали, а не по категориям технологий. Простой способ сделать это — сегментировать продукт на основе того, что увидит конечный пользователь, поэтому каждый микроинтерфейс инкапсулирует одну страницу приложения и несет единоличную ответственность за одну команду. Это делает командную работу более эффективной, чем формирование команд на основе технических категорий или «горизонтальных» проблем, таких как стили, формы или проверка.сплоченность.
4. Типы микроинтерфейсных решений
В настоящее время отечественные микроинтерфейсные решения можно условно разделить на:
- Режим док-станции: управление подприложениями путем создания базы и настройки центра. Например, более общее решение Qiankun, основанное на SIngle Spa, также есть индивидуальные решения, основанные на бизнесе их собственной команды.
- режим самоорганизации: Интермодуляция по соглашению, но возникнут проблемы, такие как работа со сторонними зависимостями.
- Децентрализованная модель: вне режима док-станции каждое приложение может делиться ресурсами друг с другом. как на основеWebpack 5 Module FederationосуществленныйМикро интерфейсное решение EMP, что позволяет нескольким приложениям совместно использовать ресурсы друг с другом.
Среди них в настоящее время стоит отметить, чтоДецентрализованная модельсерединаМикро интерфейсное решение EMP, можно добитьсяВызовы между технологическими стеками, и может использоваться между приложениями одного и того же технологического стекаГлубокая настройка общих ресурсов, если вы только начинаете исследовать микрофронтенды, то можете попробовать сначала разобратьсяМикро интерфейсное решение EMP, это может принести вам хороший опыт.
Конкретный многоплановый углубленный сравнительный анализ будет в следующей статье.«Сравнение различных микроинтерфейсных решений»Подробное объяснение, добро пожаловать всех, чтобы обратить вниманиезапись в вики-блогеПервое обновление.
Запись в вики-блоге микроинтерфейса EMPОбновить каталог:
-
Базовый анализ знаний
Сравнение различных микроинтерфейсных решений
-
Быстрый старт
Как использовать и получить доступ к EMP в реактивном проекте
-
Расширенный учебник
Как проекты Vue и React звонят друг другу удаленно