Руководство: Если вы подведете итоги самых горячих интерфейсных технологий в 2019 году, то микро-интерфейсы определенно найдут свое место. Тем не менее, большинство людей понимают архитектуру микро-интерфейса-выскочки до сих пор в состоянии невежества.Эта статья подробно расскажет о прошлом и настоящем микро-интерфейса и покажет вам, как архитектура микро-интерфейса эволюционировала из реальных потребностей. шаг за шагом И практика построения набора средних и серверных систем, усовершенствованных автомобильной одеждой Xiaoju на основе микро-интерфейса.

1. Что такое микрофронтенд

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

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

2. Зачем вам микрофронтенды?

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

Много лет назад Сяохун и Сяолань решили заняться бизнесом и открыть интернет-магазин. Они нашли общий язык и быстро разработали прототип версии 1.0. Используя самые примитивные Jquery и Html, они создали набор торговых сайтов для пользователей и для Отображается фон управления:

Чтобы облегчить понимание, давайте проигнорируем внешнюю систему покупок и сосредоточимся на внутренней системе управления.Поскольку на ранней стадии проекта необходимо удовлетворить только самые основные потребности в покупках, все потребности управления в то время были сосредоточены в одной системе управления, а коды собраны на складе.Архитектура следующая:

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

Позже, по мере того, как бизнес становился все больше и больше, управление товарами постепенно разделялось на управление отдельными товарами и общее управление товарами, управление запасами разделялось на управление запасами партнеров и самостоятельные запасы, управление заказами и управление пользователями становилось все более и более масштабным. стало вот так:

Хорошо видно, что со сложностью бизнеса управление каждым модулем становится все более и более раздутым, и всем командам становится все труднее поддерживать разные функции в одной системе, поэтому Сяохун и Сяолань решили запустить 2.0. Версия, отделяет и разделяет всю внутреннюю систему управления и поддерживает разные модули разными командами. Команда A отвечает только за управление продуктом, команда B отвечает только за управление запасами, а остальные модули аналогичны, так что каждый развертывает их отдельно в разработке, не мешая друг другу.

В режиме 2.0, когда бизнес становится все больше и больше, Сяохун и Сяолань решают создать еще две команды по маркетингу и каналам для выполнения некоторых маркетинговых мероприятий и мероприятий по каналам соответственно, в систему фонового управления также необходимо добавить управление каналами и модуль управления маркетингом, следуя описанной выше логике разделения, две команды создадут новую систему каналов и систему маркетинга для управления ими по отдельности.Каждый создает свой собственный код и поддерживает свои собственные системы, что значительно повышает масштабируемость.

В то же время, с развитием фронтенд-технологий, фреймворки Jquery и Html постепенно отстают, а главной силой вдруг стали одностраничные приложения, такие как Angular, React и Vue. начали реконструировать собственные системы Система управления продуктом использует фреймворк React, а управление заказами Система использует фреймворк Vue и т.д. друг с другом, что удовлетворяет потребность в разделении кода в начале.

Все в режиме 2.0 выглядит идеально, но так ли это на самом деле, и вскоре вылезает проблема:

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

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

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

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

Затем систему фонового управления всего электронного торгового центра можно реструктурировать, используя идею микроинтерфейса, то есть режим 3.0:

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

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

Гибкая агрегация бизнеса в систему:Связывание функций продукта: при взаимодействии с пользователями несколько различных бизнес-функций объединяются в бизнес-систему.
Совместим с многотехнологичным стеком:Будь то технологический стек Vue, React или Angular, он может отлично работать в одной системе.
Самостоятельная разработка и развертывание:Хранилища между подприложениями независимы и могут разрабатываться независимо.После развертывания уровень контейнера выполнит автоматические обновления синхронизации.
Повторное использование ресурсов зависимостей:Извлекайте общедоступные ресурсы, от которых зависят разные приложения, и загружайте несколько сторон одновременно для повторного использования, тем самым повышая производительность.

3. Выбор технологии микроинтерфейса

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

маршрутизируемое распределение

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

iframe-контейнер

Это вторая из старейших реализаций технологии микро-фронтенда.Простая, но эффективная, iframe всегда была одной из спецификаций браузера.За исключением некоторых версий на уровне ископаемых, почти все браузеры полностью совместимы. Страница Iframe отделена от родительской страницы и совершенно не зависит от CSS родительской страницы или глобального JavaScript. Это в определенной степени похоже на «изоляцию песочницы», но если система загружает слишком много фреймов, опыт будет очень недружелюбным. , и будет повторяться одна и та же загрузка Зависимость, влияющая на скорость загрузки веб-страниц.

Служба виджетов

Виджетизация означает, что приложение имеет все полные и замкнутые функции, скомпилированные заранее разработчиком, а другие приложения могут быть непосредственно встроены в веб-страницу без каких-либо изменений или компиляции для прямого запуска и отображения. Если раньше многие приложения внедрялись таким образом, инкапсулируя собственные приложения в пакеты sdk, и пользователи могли удаленно загружать код javascipt для генерации соответствующих компонентов и встраивания их на страницу, то позже, с ростом популярности npm, он постепенно развивался. в приложение, которое использует пакеты NPM.Преимущество этого метода заключается в том, что его можно развертывать и упаковывать отдельно и гибко.Недостаток в том, что если вводятся несколько виджетов приложения, могут возникнуть проблемы взаимного вмешательства, а связь между приложениями затруднена. , а устаревшие приложения требуют слишком много изменений.

Web Components

Веб-компоненты — это стандарт веб-компонентов, который обеспечивает базовую поддержку браузера, независимую от поддержки различных фреймворков и компиляции веб-пакета, так что люди также могут использовать компоненты. Веб-компоненты инкапсулируют компонент стандартизированным, ненавязчивым способом, и каждый компонент организует свой собственный HTML, CSS и JavaScript, не мешая другому коду на странице. Метод использования подобен методу фрейма. Компоненты имеют свои собственные независимые сценарии и стили, а также соответствующие доменные имена для независимого развертывания компонентов. Внутренние ресурсы очень связаны, область действия независима, а загрузка контролируется сама собой. Кажется, что веб-компоненты действительно являются хорошим выбором архитектуры микро-интерфейса, но, к сожалению, текущая поддержка браузеров не идеальна, и поддержка в Safari, то есть и в Firefox, не идеальна.Если вы не считаете поддержку нескольких браузеров Совместимость , Веб-компоненты — хороший выбор.

Сервис микроприложений с самодельным фреймворком

Служба микроприложений означает, что система существует в виде одного микроприложения в начале, и эти приложения загружаются и объединяются структурой системы только тогда, когда они работают, чтобы сформировать полную систему. Будь то фреймворк react и vue на основе виртуального дерева или фреймворк Angular на основе веб-компонентов, прототип всех фреймворков неотделим от загрузки элементов в html, значит, нам нужно только упаковать и скомпилировать единую систему в микро приложение заранее.DOM вводится или создается в подходящем месте на странице, так что приложение срабатывает, когда пользователь работает, и приложение может быть удалено, когда пользователь переключается.Поэтому ядро этой службы микроприложений заключается в конструкции загрузчика, который может загружать и переключать различные приложения в режиме реального времени, а также эффективно изолировать приложения для предотвращения взаимных помех. Single-SPA — это относительно зрелый фреймворк с открытым исходным кодом, который может интегрировать несколько разных фреймворков на одной странице и даже не требует обновления страницы при переключении, поддерживает React, Vue, Angular 1, Angular 2, Ember и т. д. ., если вы хотите легко применять инженерные микроприложения, вы можете рассмотреть возможность использования этой платформы.

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

Как отличить среду разработки от онлайн-среды после использования
Как изолировать JS и избежать конфликтов CSS
Механизм совместного использования общих ресурсов между приложениями
Сторонние модули перекрываются
Обрабатывать выборку данных и учитывать начальное состояние загрузки пользователя.
Как получить доступ к разрешениям
Как сократить время первоначальной загрузки
Как эффективно тестировать

Поэтому, как и микросервисы, микрофронтенды требуют ряда технических резервов, чтобы действительно войти в практику. В настоящее время Xiaoju Car Service построила полнофункциональную платформу доступа к продуктам в сочетании с реальной бизнес-формой, которая решает технические трудности в вышеупомянутом микроинтерфейсе и предоставляет набор общих решений для построения средняя и задняя системы.

4. Практика микропередка в автомобильной одежде

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

С этой целью команда решила предоставить набор микроинтерфейсной архитектуры системы, основанной на интеграции возможностей LASS в текущую среду группы и обслуживания транспортных средств, от ресурсов страниц до микроприложений до построения и управления на системном уровне. Унифицированные возможности, а именно платформа Midway.

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

Нижний уровень Midway основан на single-spa, который изолирует стили и области действия между подприложениями.Посредством регистрации приложений, ссылок на хуки и других методов он контролирует полный жизненный цикл подключенных приложений и обеспечивает связь между приложениями, публичные загрузка ресурсов. Ниже представлены различные базовые функции, такие как загрузка приложений по запросу, предварительная загрузка приложений и мониторинг журналов.

Регистрация приложения

Midway вызывает метод registerApplication single-spa для регистрации микроприложения и поддерживает входящую асинхронную функцию loadApp (просто возвращает Promise) и значения нефункционального типа. Если это тип, не являющийся функцией, он будет активно преобразовываться и выполнять некоторые функции до и после возврата хука и возвращенного хука:

Добавлены хуки beforeUnmount, afterUnmount, beforeMount, afterMount, beforeLoad для облегчения некоторой обработки до и после применения монтирования и загрузки.
Получите статические ресурсы в соответствии с компоновщиком отдельных страниц (Pegasus), добавьте хуки и связанные с ними конфигурации в файл entry.js страницы Pegasus и т. д.
В соответствии с типом записи, переданной при регистрации приложения, проанализируйте и обработайте для получения html, скриптов, стилей, идентификатора (страницы Pegasus) и другой информации о текущем приложении.
В соответствии с конфигурацией записи асинхронно извлеките соответствующие статические ресурсы и, наконец, верните шаблон кода шаблона и execScripts, используемые для рендеринга, которые используются для выполнения метода entry.js для получения перехватчиков.
Создайте среду песочницы (прокси) для текущего приложения, выполните execScripts в среде песочницы, чтобы получить функцию ловушки entry.js, и, наконец, loadApp вернет обработанную функцию ловушки.

Предварительная загрузка приложения

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

Отфильтровать смонтированные приложения.Ресурсы смонтированных приложений должны быть загружены, поэтому их предварительно загружать не нужно.
После того, как первое приложение в зарегистрированном микроприложении будет смонтировано, будут предварительно загружены другие настроенные предварительно загруженные приложения. . Итак, мы слушаем это событие, и когда первое микроприложение смонтировано, мы можем запустить задачу предварительной загрузки.
Используйте API window.requestIdleCallback для предварительной загрузки ресурсов приложения во время простоя браузера.В мобильных устройствах и слабом сетевом окружении мы не будем запускать предзагрузку задач. В браузерах, которые не поддерживают API window.requestIdleCallback, мы используем setTimeout для имитации.

JS-песочница

Слово «песочница» звучит грандиозно, но на самом деле мы давно общаемся. Конкретные понятия и детали здесь повторяться не будут, вы можете поискать сами. Проще говоря, когда вы хотите проанализировать или выполнить ненадежный js, когда вы хотите изолировать среду выполнения исполняемого кода, когда вы хотите ограничить объекты, доступные в исполняемом коде, песочница пригодится. Полезно.

изоляция стиля

Перехватывайте метод HTMLHeadElement.prototype.appendChild, перехватывайте appendChild и выполняйте операции создания и восстановления моментальных снимков стиля при применении монтирования и размонтирования. В будущем рассмотрите возможность использования схемы теневого дома для изоляции стилей, которая является более тщательной и безопасной.

кэш ресурсов

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

Использование Dexie.js для управления базами данных IndexedDB
Установите период кеша на 7 дней, ресурсы с истекшим сроком действия будут очищены.
Основные API — это cacheAssets, getCacheAssets, clearExpiredAssets.

5. Резюме

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

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

Набор команды

Техническая команда терминала автомобильной одежды Xiaoju под руководством Didi Chuxing - это молодая, ответственная, энергичная команда, стремящаяся к совершенству в технологиях.Большая техническая команда терминала с несколькими направлениями бизнеса, такими как Juyangche. Используемые стеки интерфейсных технологий включают vue, react, nodejs, flutter, апплет WeChat и т. д. В настоящее время в Ханчжоу и Пекине имеется большое количество долгосрочных вакансий, в том числе некоторые стажировки.

Позиции долгосрочного подбора:

Фронтенд-инженер
Инженер-клиент (Android/iOS)
Инженер по оборудованию AIoT (предпочтительно направление подключения автомобиля)
Выпускники 2021 г. (время выпуска: 20.11~21.10) стажер

Добро пожаловать, чтобы отправить свое резюме по адресу:diditech@didiglobal.comУкажите тему письма как «имя + отдел подачи заявки + направление подачи заявки». Мы серьезно отнесемся к каждой доставке и обеспечим максимальную скорость обработки!

об авторе

Окончил Пекинский университет почты и телекоммуникаций со степенью магистра, присоединился к Didi в 2019 году, любит домашних животных и увлекается технологиями. В настоящее время отвечает за работу, связанную с арендой автомобилей, в терминальной технологии автосервиса и стремится быть программистом, у которого есть идеалы и который любит жизнь.

**Добро пожаловать на официальный аккаунт Didi Technology!

Эта статья публикуется блогерами и другими операционными платформами.OpenWriteвыпускать