簡単な導入によるマイクロフロントエンド MicroApp | JD Cloud テクニカルチーム

序文：

この記事は最近のプロジェクトからインスピレーションを受けています, 以前に技術スタックの統合を行ったことがあります. ant Design のプロテーブルを使用するために、PC 統合では React を使用しますが、vue に基づいた古いプロジェクトがいくつかあります。新しいページが多く、古いページへの変更はほとんどありません。また、古いプロジェクトはメニューを変更したいと考えているため、この機会に React で開発したいと考えています。少し考えた結果、React を使用するのに非常に適していることがわかりました。ニーズを満たした後、最終的には React を使用してベース (メインアプリケーション) を構築し、オリジナルの vue プロジェクトをベースに接続することにしました。開発だけでなく、古いプロジェクトを新しいプロジェクトに統合することもできます。

マイクロフロントエンドの概念

マイクロフロントエンドとは何ですか? マイクロフロントエンドは、マイクロサービスのアーキテクチャ概念を利用しています。複数のプロジェクトを 1 つに統合するだけでなく、プロジェクト間の結合を減らし、プロジェクトのスケーラビリティを向上させることもできます。完全なフロントエンドウェアハウスと比較して、マイクロフロントエンドは、エンドアーキテクチャフロントエンドリポジトリは、より小さく、より柔軟になる傾向があります。さまざまなサブアプリケーションのロードとアンロードを管理するベースアプリケーション (メインアプリケーション) があります。したがって、マイクロフロントエンドは、特定のライブラリ、特定のフレームワーク、または特定のツールを指すのではなく、理想的なアーキテクチャモデルを指します。マイクロフロントエンドの 3 つの基本原則: 独立した運用、独立したデプロイメント、独立した開発。

マイクロフロントエンドを使用する場合

(1) 非常に大規模なプロジェクトがますます大きくなり、将来の維持が困難になります。

(2) 一部の大規模な工場では、部門やチームを越えた共同開発プロジェクトが頻繁に行われるため、チームの効率が低下し、コミュニケーションコストが増加します。プロジェクトの場合、点在するサブプロジェクトをまとめるために必要なメインプロジェクトは 1 つだけです。

(3) 非常に古いプロジェクトは開発効率が低いですが、しばらく完全に再構築することはできませんが、この時点で新しい技術と新しいプロジェクトの新しい基盤を作成し、古いプロジェクトのページを接続することができます。新しいプロジェクト内部では、新しい要件はすべて新しいプロジェクトで開発されるため、古いプロジェクトに触れる必要はありません。

(4) シングルページアプリケーションをそれぞれ独立して導入したい。

(5) 初期ロード時間を改善し、コードのロードを遅延させます。

(6) 複数ページをベースにしたサブアプリケーションは管理が不十分で、仕様・規格が統一されておらず、見た目の表現や共有機能、依存関係などを統一的に管理できない。作業の重複が発生する。

マイクロフロントエンド基盤の作り方

1. マイクロフロントエンドフレームワークの選択

(1) 既存の枠組み

single-spa は、複数の単一ページアプリケーションを 1 つの全体的なアプリケーションに集約する JavaScript マイクロフロントエンドフレームワークです。

2. qiankun は、シングルスパパッケージングに基づくマイクロフロントエンドフレームワークです。

MicroAppは JD.com によって作成され、WebComponent のアイデアに基づいた軽量で効率的かつ強力なマイクロフロントエンドフレームワークです。

私たちのプロジェクトは umi+react+ts テクノロジースタックを使用しています。実際には、qiankun を使用する方が適しています。Qiankun は umi フレームワークを継承していますが、このフレームワークは設定がより面倒です。第二に、MicroApp は JD.com によって所有されています。

(2) MicroApp の利点

1. 使用コストが最も低く、すべてを WebComponent のようなコンポーネントにカプセル化するため、メインアプリケーションベースにコード行を埋め込むことでマイクロフロントエンドアプリケーションをレンダリングできます。

2. レンダリングロジックを変更して、single-spa や qiankun などのメソッドを公開するためにサブアプリケーションを要求する必要はなく、webpack 構成を変更する必要もありません。これは現在、マイクロフロントエンドにアクセスするための最も低コストのソリューションです。市場。

3. js サンドボックス、スタイル分離、要素分離、プリロード、データ通信、静的リソース補完などの一連の完全な機能を提供します。

4. 依存関係がないため、サイズが小さく、スケーラビリティが高くなります。

5. 各ビジネスの独立した開発と独立した展開機能を確保するために、マイクロアプリは多くの互換性を備えており、どのような技術フレームワークでも正常に実行できます。

(3) MicroApp コンセプトマップ

2. シーンデモンストレーション

バックエンド管理システムを例に挙げます。

最外層は ** ベースで、マイクロフロントエンドアプリケーション統合のための重要なプラットフォームです。同時に、公共資源、依存、規制を管理する責任も負っています。主に以下の業務を担当します。

(1) サブアプリケーションの統合、サブアプリケーション用のレンダリングコンテナーを提供

(2) 権限管理

(3) セッション管理

(4) ルーティングとメニュー管理

(5) トピック管理

(6) 共有依存関係

(7) 多言語管理（最重要ポイント）等

コンテンツは、異なるテクノロジーのサブアプリケーションと任意に配置でき、メインアプリケーションを開発するだけで済みます（メインアプリケーションは言語も自由に選択でき、現在はreact、vue、vite、angular、next.js、nuxt.jsをサポートしています）アプリケーションが接続された後、メインアプリケーションはアクセス許可を制御して、異なるアカウントに異なるメニューが表示されるようにすることもできます。つまり、アカウントは異なるシステムのページを表示し、同じアドレスを介して異なるサブアプリケーションにアクセスできます。

3. マイクロフロントエンド基盤の構築

反応ベースを例に挙げます

1. プロジェクトを作成する

(1) まず、ローカルノードのバージョンが 14 以上であることを確認します(ノードバージョンの管理にはnvmを使用することをお勧めします。Windows ではnvm-windowsを推奨します)。

(2) ベースと呼ばれる公式 Web サイト上でコマンドを提供することで、メインアプリケーションとなる UMI ベースのプロジェクトをすぐに作成できます。

(3) 依存関係をインストールする

npm i @micro-zoe/micro-app --save

package.json ファイルの依存関係に追加のコード行が追加されます。次のコードが表示されたらおめでとうございます。プロジェクトにはすでにマイクロアプリアクセス機能があります。

"@micro-zoe/micro-app": "^1.0.0-alpha.7"

(4) 入口でマイクロアプリを導入

まず、ルートディレクトリに global.tsx ファイルを作成します。

import microApp from '@micro-zoe/micro-app'

microApp.start()

(5) メインアプリケーションにサブアプリケーションを導入する

a. サブアプリケーションルートを割り当てる

  {
    path: '/yp',
    name: 'yp',
    linkHidden: true,
    linkDisable: true,
    breadcrumbClose: true,
    component: '@/pages/yp-app',
  }

b. サブアプリケーションファイル

Pages ファイルの下に yp-app (サブアプリケーションファイル) を作成します。

// 名前 (必須): アプリケーション名 // url (必須): アプリケーションのアドレス。http://localhost:3000/index.html として自動的に完成します。

import React from 'react';
import config from '@/config';

// /** @jsxRuntime classic */
// /** @jsx jsxCustomEvent */
// import jsxCustomEvent from '@micro-zoe/micro-app/polyfill/jsx-custom-event';

export default (): React.ReactElement => {
  
  // 子应用点击了面包屑的回到首页
  const onDispathChild = (e: any) => {
    const { isBackHome } = e.detail.data;
    if (isBackHome) window.location.href = '/';
  };

  return (
    <>
      <micro-app name="yp" url={config?.yp} onDataChange={onDispathChild} />
    </>
  );
};

説明: onDataChange メソッドは、サブアプリケーションとメインアプリケーション間の情報通信メソッドです。マイクロアプリはウィンドウの下にグローバルオブジェクトをマウントします。マスターと子の間の通信を完了するには、マイクロアプリが提供するメソッドをトリガーするだけです。対話ロジックでもデータ転送ロジックでも、すべて問題ありません。

c. メインアプリケーションはサブアプリケーションを正常に導入します (サブアプリケーションは VUE プロジェクトです)。

これまでのところ、プロジェクトにクロスドメインの問題がなければ、サブアプリケーションはメインアプリケーションに正常に接続されており、この時点では次の図が表示されます。

左側がメインアプリケーション、中央のモジュールがサブアプリケーションで、モジュール全体のメニューとサブアプリケーションのリストが含まれていますが、メニューはメインアプリケーション（ベース）に統合されており、管理が容易であることを考慮して、サブアプリケーションページのメニューといくつかの異なるものを配置する必要があります必要なものを削除すると、サブプロジェクトのいくつかのパブリックスタイルとパブリックレイアウトを均一に調整できます。最後に、メインアプリケーション+サブアプリケーションの最終ページを取得します-アプリケーションページ。ここに到達しました。おめでとうございます。最初のアプリケーションに正常にアクセスしました。サブアプリケーション、2 番目のアプリケーションです。。。。他のアプリケーションでも同じ手順に従います。

アクセスが完了しても、サブアプリケーション内のすべてのモジュールが使用可能になるわけではありません。このとき、エクスポートおよびインポートのインターフェイスがドメイン名から取得されているか、または個別に定義されているかも確認する必要があります。 name が取得されました。現時点ではインポートは正常に使用できません。インポートとエクスポートを別々に再定義する必要があります。たとえば、サブアプリケーションに別の host.js ファイルを作成し、そのドメイン名プレフィックスを参照します。環境に応じて区別されます。

2.ルートジャンプ

メインアプリケーションのメニューから、対応するサブアプリケーションのルートにジャンプします

//config.ts
let config = {
  yp: 'https://xxx.xxx.com:7000/gw',//本地环境子应用的路由前缀
};

const isEnvPro = process.env.NODE_ENV === 'production';

if (isEnvPro) {
  config = {
    yp: 'https://xxx.xxx.com/gw',//预发环境环境子应用的路由前缀
  };
}

export default config;
//以上是config.ts文件的全部-----end


//菜单点击事件里面的内容

history.push('/yp'); //切换到子应用

setTimeout(() => {
    microApp.router.push({
      name: 'yp',//和子应用的name要保持一致，为了匹配到对应子应用的路由
      path: `${config.yp}${item.url}`,
    }); //跳转子应用的路由，其中config是上面的配置文件，根据不同的环境取对应环境的子应用，item是当前点击的菜单路径信息
}, 500);

setTimeoutを使用する理由を説明すると、まずhistory.push('/yp')でサブアプリに切り替え、切り替え後短時間でサブアプリのルートが見つからないようにするため、遅延が発生しても、サブアプリケーションに対応するルートに正確にジャンプできます。

3. クロスドメインの設定

(1) ローカルクロスドメインのみを使用する場合は、それをサブアプリケーションに設定し、webpack-dev-server のヘッダーでクロスドメインサポートを設定できます。

devServer: {
  headers: {
    'Access-Control-Allow-Origin': '*',
  }
},

これには対応するドキュメントがあり、サブアプリケーションの言語に応じて異なるクロスドメイン情報を設定します。

(2) インターフェースがクロスドメインの場合。

次に、フロントエンドのクロスドメインコード (例として Java) を許可するバックエンド設定を見つける必要があります。

  @Override
    public void init(FilterConfig filterConfig) {
        this.origins = Lists.newArrayList("http://localhost:8088",
            "https://xx.51epei.com",
            "https://xx.yunxiu.com",
            "https://dev.51epei.com:8088",
            "https://xx.51epei.com:7000");
    }

これは基本的な構成です。同じドメイン名の下にあるすべてのものに対してクロスドメインを許可するように変更することもできます。非常に安全ではない '*' に設定しないことをお勧めします。

4. エージェントの設定

メインアプリケーションがローカルでサブアプリケーションにアクセスできず、アクセスが常にプレリリースまたはオンラインである場合は、次に示すように、まずエージェントがペアになっているかどうか (サブプロジェクトの 1 つなど) を検討する必要があります。図：

proxy: (() => {
  return {
    //  本地访问预发
    '/avoid': {
      target: 'https://pai.51epei.com',
      changeOrigin: true,
      bypass: (req) => {
        if(req.headers.accept.indexOf('html') !== -1 ) {
          return '/index'
        }
      },
    }
  }
})()

当初、ルートに「/」が含まれている場合、ローカルプロキシは事前に発行されたサーバーにプロキシされていましたが、通常はサブアプリケーションのリンクには別途アクセスされ、ローカルエージェントが事前に発行したインターフェイスには正常にアクセスできましたが、メインアプリケーションに配置できませんでした。最後に、プロキシが変更されました。プロキシはプロジェクト/回避全体のパブリック部分になり、この問題は解決されました。プロジェクトのこれが原因ではないかもしれませんが、できると思いますエージェントと協力して問題を見つけます。

5. データ通信

マイクロアプリは、ベースアプリケーションとサブアプリケーション間のデータ送信を容易にする柔軟なデータ通信メカニズムを提供します。

通常の状況では、ベースアプリケーションとサブアプリケーション間の通信はバインドされており、ベースアプリケーションは指定されたサブアプリケーションにのみデータを送信でき、サブアプリケーションはベースにのみデータを送信できます。この方法により効果的に回避できます。データ汚染。複数のサブアプリケーションが相互に影響を与えるのを防ぎます。

同時に、アプリケーション間のデータ通信を容易にするグローバル通信も提供します。

サブアプリはベースアプリからデータを取得し、ベースアプリはサブアプリにデータを送信するベースアプリはサブアプリからデータを取得し、グローバルデータ通信を行うここでは詳しく説明しません。詳細については、https://zeroing.jd.com/docs.html#/zh-cn/dataを参照してください。

要約する

上記の紹介から、マイクロフロントエンドアーキテクチャを採用する利点は、長期間実行され相関関係のない複数のアプリケーションを 1 つのアプリケーションにマージしたり、多数の小さな個別アプリケーションを 1 つのアプリケーションにマージしたりできることであることがわかります。アプリケーションを完全に統合することでプロジェクトの数を減らすことができ、それらを結合することでプロジェクトのスケーラビリティが向上します。マイクロアプリは WebComponent のアイデアを活用し、カスタマイズされた ShadowDom と組み合わせた CustomElement を使用して、マイクロフロントエンドを WebComponent のようなコンポーネントにカプセル化して、マイクロフロントエンドのコンポーネント化されたレンダリングを実現します。また、カスタム ShadowDom の分離特性により、Webpack 構成を変更する必要がなく、現在市場でマイクロフロントエンドにアクセスするための最も低コストのソリューションであるため、プログラマーにも好まれています。

マイクロフロントエンドはすでに非常に成熟した分野であり、マイクロフロントエンドを使用する目的はコストを削減し、効率を向上させることですが、今日のオープンソース環境では、どのフレームワークを使用するかは問題ではありません。個人的には、現在のプロジェクトがマイクロサービス接続後に維持コストが高くなったら、それがマイクロフロントエンドに適しているかどうかを検討する必要があると考えています。マイクロフロントエンドはすべてのシナリオに適しているわけではありません。問題が発生した場合は、複数の解決策を検討してください。

参考：マイクロアプリ公式サイト：https://zeroing.jd.com/docs.html#/

著者: JD Retail チェン・ヤンチュン

出典：JD Cloud Developer Community 転載の際は出典を明記してください