Предварительное исследование архитектуры микро-интерфейса и моего инвентаря технологий фронт-энда.

внешний интерфейс внешний фреймворк
Предварительное исследование архитектуры микро-интерфейса и моего инвентаря технологий фронт-энда.

предисловие

Последние годымикро интерфейсЭто всегда была горячая тема в мире фронтенда, она похожа наМикросервисыАрхитектура, в основном на стороне браузера, может разделить сложное и огромное отдельное приложение на несколько подприложений с четкими и независимыми функциональными модулями и вместе обслуживать одно и то же основное приложение. Каждое подприложение может работать независимо, независимо развиваться и развертываться независимо.

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

ты получишь

  • Что такое микросервисы и что микросервисы могут дать предприятию
  • Концепции и решения микроинтерфейсной архитектуры
  • Решение микроинтерфейсной архитектуры под управлением umi
  • Технический обзор и прогноз программиста

текст

В итогеАрхитектура микроинтерфейсаПрежде давайте посмотримМикросервисычто.

1. Что такое микросервисы и что микросервисы могут дать предприятиям

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

Традиционная архитектура разработки веб-приложений часто показана на следующем рисунке:

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

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

Из приведенного выше рисунка мы можем найти преимущества, которые нам приносят микросервисы:

  • Разберите огромный мономер на несколько подсервисов, что значительно упростит разработку.
  • Границы задачи четко разделены, каждая подслужба разрабатывается отдельно, а разные службы могут разрабатываться разными разработчиками параллельно для повышения эффективности разработки.
  • Более детальный усовершенствованный модульный процесс, более высокая ремонтопригодность и читабельность
  • Пока соглашение об API сформулировано между командами, разные участники или команды могут использовать разные технологии для разработки сервисов.
  • Доступны общие сервисы, позволяющие комбинировать различные подсервисы для достижения более сложных функций.
  • Каждая микрослужба может быть развернута и выпущена независимо, что делает автоматизациюCI(непрерывное интегрирование)/CD(непрерывная доставка) возможно

Но микросервисы подходят не для всех сценариев.Цель микросервисов — достаточно декомпозировать приложение, чтобы облегчить гибкую разработку и развертывание с непрерывной интеграцией. При развертывании микросервисов нам необходимо сделать соответствующие граничные разделения и решить проблемы параллелизма между различными микросервисами.Это проблемы для всего проекта и требуют контроля со стороны более профессиональных технических специалистов.В настоящее время также существует множество сред микросервисов с открытым исходным кодом, таких какDubbo, Spring CloudПодождите, предыдущая компания автора использовалаSpring CloudЭто хорошее решение для микросервисной архитектуры.

2. Концепции и решения микроинтерфейсной архитектуры

2.1 Понимание архитектуры микроинтерфейса

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

  1. микро интерфейсПрименительно к стороне браузера он в основном разбирает веб-приложение и, наконец, объединяет различные подсистемы (модули) в законченное приложение.
  2. микро интерфейсОсновная цельполимеризация, то есть объединить различные подсистемы в большую систему, иМикросервисыАрхитектура в настоящее время больше связана с развязкой, то есть развязкой зависимостей между различными сервисами.

Давайте начнем с рассмотрения некоторых мыслителей микро-интерфейсов.

Майкл Гирс опубликовал некоторые мысли о микро-фронтендах, содержание которых примерно можно резюмировать следующим образом:

«Микро-интерфейс» — это расширение концепции микросервисов на область внешнего интерфейса. Чтобы создать мощное браузерное приложение (также известное как одностраничное приложение), текущая общая тенденция состоит в том, чтобы строить его поверх архитектуры микросервисов. Но со временем внешний слой, обычно разрабатываемый независимой командой, разрастается, и его становится сложнее поддерживать. Идея Micro Frontends состоит в том, чтобы рассматривать веб-приложение как комбинацию функций, принадлежащих отдельным командам. У каждой команды есть своя область бизнеса или миссии, связанная со своими заботами и опытом. Каждая команда может развивать свою функциональность через функции и от начала до конца, от базы данных до пользовательского интерфейса.

Как показывает следующий пример:

Когда в нашей системе есть несколько разных подмодулей, и между подмодулями есть относительно независимые и полные функциональные системы, когда подмодулей становится все больше и больше, все приложение становится очень большим и раздутым, и разработка Стоимость сопровождения и сопровождения сильно увеличивается.Если мы будем использовать режим SPA для разработки в этом сценарии, более поздний этап проекта станет невообразимым, а загрузка первой страницы станет очень медленной (автор однажды испытал, что разработка сложная системная страница возьмет на себя первую загрузку, чтобы загрузиться в первый раз, это заняло более 20 секунд, поэтому нам пришлось использовать MPA, чтобы справиться с этим); но мы приняли режим MPA (многостраничное приложение), хотя проблема раздутое приложение было решено, но еще предстоит решить много проблем, таких как переключение модулей для обновления страницы, общедоступные компоненты не могут использоваться совместно, подмодули являются прямыми, проблемы связи между родительскими и дочерними модулями, громоздкая разработка и развертывание и т. д. Это все проблемы, встречающиеся в традиционных моделях разработки.

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

Часто промежуточные и серверные системы предприятий больше подходят для использования микро-интерфейсной архитектуры, потому что большая часть B-end ориентирована на бизнес, и эти предприятия часто очень сложны, такие как Saas, Paas и другие системы. , Подобно облачным платформам, CRM, ERP-системам, часто является спасательным объектом архитектуры микро-интерфейса.

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

Автор писалНаучу строить компонентную систему фронтенд команды от 0 до 1 (обязательно для продвинутых и продвинутых)В этой статье я кратко упомянул некоторые знания о микро-фронтендах, а здесь давайте воспроизведем простую диаграмму, сделанную автором ранее, чтобы каждый мог понять архитектуру микро-фронтенда.

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

2.2 Решение архитектуры микроинтерфейса

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

1. Архитектура микроинтерфейса на основе MPA + iframe + requirejsЭто самый ранний проект, который взял на себя автор, в основном обслуживающий систему ERP на предприятии. В то время использовался стек технологий, в основном, jquery + layui + requirejs. Я помню, что это был проект, в котором я участвовал, когда только что закончил учебу. в основном использует модульный механизм AMD для повторного использования кода, в то время код проекта был огромным и сложным, общая структура выглядит следующим образом:

Традиционный метод реализации, как правило, состоит в том, чтобы отделить приложение от нескольких страниц и использовать модульный механизм загрузки для импорта повторно используемых компонентов.Общий тип между системами использует хранилище+window.opener+iframe.Например, домашняя страница большой системы может be Там будут страницы из разных подсистем, которые вшиты в виде iframes.Разные подсистемы обслуживаются разными людьми.Хотя режим микро-фронтенда достигается, но есть еще много недостатков.
Общее разделение труда при изменении архитектуры заключается в том, что архитектурная группа в основном отвечает за формулирование архитектурных стандартов и спецификаций, а также за поддержание общедоступных модулей (по аналогии с текущими компонентами, в то время из-за использования экологии jquery это может быть просто называется обслуживанием общедоступных подключаемых модулей пользовательского интерфейса); бизнес-группа в основном отвечает за написание бизнес-кода, который реализует определенные взаимодействия и функции системы.

2. Архитектура микроинтерфейса на основе MPA + iframe + WebpackРеализация архитектуры микроинтерфейса на основе MPA + iframe + Webpack аналогична реализации традиционной архитектуры, описанной выше, за исключением того, что она использует обновленный стек технологий и настоящую модульную и компонентную технологию. Система Saas, которую я сделал ранее, является типичным примером этого решения:

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

Недостаток двух вышеупомянутых решений заключается в том, что библиотеку компонентов можно использовать только повторно и нельзя по-настоящему совместно использовать, а переключение маршрутов приведет к повторному отображению и обновлению страницы. Связь между родительской подсистемой затруднена, и iframe по-прежнему требуется в качестве контейнера для связи. (О различных способах связи родительско-дочерней страницы iframe автор находится вВспомните проблему межстраничной связи в старом проекте и фронтальную реализацию функции скачивания файлов)

3. Архитектура микроинтерфейса на основе umi + qiankunВ настоящее время на рынке также есть очень зрелые решения для архитектуры микроинтерфейса, такие как single-spa, предыдущая архитектура микроинтерфейса Meituan Takeaway и архитектура микроинтерфейса qiankun, разработанная Ant Financial на основе на одинарном курорте, все из которых являются очень хорошими решениями.

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

Его программа имеет следующие характеристики:

  • Поддержка параллелизма подприложений
  • Поддержка среды песочницы js (изоляция js)
  • css-изоляция
  • HTML Entry, упрощающий использование разработчиками
  • нагрузка по требованию
  • загрузка общедоступных зависимостей
  • Механизм связи между родительскими и дочерними приложениями
  • Вложенность подприложений

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

3. Архитектурное решение микроинтерфейса под управлением umi

Далее я подробно расскажу, как использовать Qiankun для построения нашей архитектуры микроинтерфейса.Поскольку мы используем umi внутри компании, мы напрямую используем плагин @umijs/plugin-qiankun, предоставленный им для его реализации. (Преимущество в том, что стоимость модификации практически нулевая) Во-первых, давайте реализуем такой сценарий: у нас есть основное приложение в качестве базового проекта, а затем есть 3 подсистемы, которые создаются и поддерживаются независимо и могут управляться разными git-репозиториями. Когда мы переключаем маршруты в основном приложении, мы переключаемся на соответствующую подсистему без обновления страницы, полный опыт SPA, давайте реализуем его подробно.

Здесь мы используем umi2.0 для разработки, как установить и использовать umi, здесь подробно описываться не будет.

  1. Создать проект
mkdir mainSystem subSystemA subSystemB subSystemC
// 分别进入各系统目录下,执行以下命令创建我们的项目
yarn create umi
  1. Установите плагин @umijs/plugin-qiankun под каждую систему
yarn add @umijs/plugin-qiankun
  1. Конфигурация под основным приложением
// .umirc.js
export default {
  plugins: [
    [
      '@umijs/plugin-qiankun',
      {
        master: {
          // 注册子应用信息
          jsSandbox: true, // 是否启用 js 沙箱,默认为 false
          prefetch: true, // 是否启用 prefetch 特性,默认为 true
        },
      },
    ],
  ],
};
// app.js
const isDev = process.env.NODE_ENV === 'development'
export const qiankun = {
  apps: [
    {
      mountElementId: 'root-subapp-container',  // 洗子应用挂载的节点
      name: 'subSystemA', // 唯一 id,和package对应的name字段最好保持一致
      entry: isDev ? '//localhost:8001' : '/subSystemA/index.html', // html entry
      base: '/subSystemA',  的路由前缀,通过这个前缀判断是否要启动该应用,通常跟子应用的 base 保持一致
      history: 'browser', // 子应用的 history 配置,默认为当前主应用 history 配置
    },
    {
      mountElementId: 'root-subapp-container',
      name: 'subSystemB',
      entry: isDev ? '//localhost:8002' : '/subSystemB/index.html',
      base: '/subSystemB',
    },
    {
      mountElementId: 'root-subapp-container',
      name: 'subSystemC',
      entry: isDev ? '//localhost:8003' : '/subSystemB/index.html',
      base: '/subSystemC',
    }
  ],
  fetch: url => {
    return fetch(url)
  }
};

Выше приведена базовая конфигурация.Конечно, мы также можем добавить хуки, такие как жизненные циклы, в app.js для управления поведением в различных жизненных циклах.

В подприложении нам также нужно ввести плагин @umijs/plugin-qiankun, Конкретная конфигурация выглядит следующим образом:

export default {
  base: `/${appName}`, // 子应用的 base,默认为 package.json 中的 name 字段
  plugins: ['@umijs/plugin-qiankun', { slave: true }],
};

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

Однако стоит отметить, что мы используем только ресурсы, предоставляемые devServer в среде разработки, для получения ресурсов между доменами.Если приложение опубликовано в Интернете, если разные подприложения используют разные доменные имена, нам также необходимо решить кросс- доменная проблема (кросс-доменное решение. Также существует множество схем и механизмов безопасности, которые уже не являются проблемой). Есть еще много вопросов, которые нам нужно рассмотреть в реальной среде разработки.Это только краткое введение.Однако, согласно официальному API, он может удовлетворить большинство сценариев спроса, поэтому его все же стоит попробовать. Позже автор также напишет реальный кейс микрофронтенда и опубликует его на github, чтобы мы могли общаться и учиться вместе.

4. Технический обзор и прогноз программиста

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

1. Связанный с узлом

2. Инженерное дело

3. Шаблоны проектирования

4. Реакция связана

5.vue/угловые связанные

6. css связанные

7. Связанный с алгоритмом

8. Игры Н5

9. Дизайн и упаковка собственной библиотеки классов javascript

10. Резюме рабочих задач

наконец

Если вы хотите узнать большеигра Н5, webpack,node,gulp,css3,javascript,nodeJS,визуализация данных холстаВ ожидании передовых знаний и реальных сражений, добро пожаловать в нашу техническую группу в общедоступном аккаунте «Интересный передний конец», чтобы вместе учиться и обсуждать, а также вместе исследовать границы переднего плана.