基於qiankun微前端的部署方案

微前端項目在本地開發完成后，接下來就需要考慮如何部署上線。主應用和微應用都應該是獨立開發和部署的，屬於不同的倉庫。

一、 部署在同一服務器

如果服務器數量有限，或不能跨域等原因需要把主應用和微應用部署在一起。

通常的做法是主應用部署在一級目錄，微應用部署在二/三級目錄。

1.1 微應用改造

由於微應用部署在非根目錄，微應用打包之前需要配置webpack構建時的publicPath為目錄名稱，以便於主應用注冊微應用后能正常訪問。

    output: {
        filename: isBuild ? '[name].[contenthash].js' : '[name].js',//編譯時要加hash防止緩存
        path: path.join(__dirname, 'dist'),//產物輸出目錄
        publicPath: "/mkc/",
        chunkFilename: isBuild ? '[name].[contenthash].chunk.js' : '[name].chunk.js',
        library: `${pkgJson}-[name]`,
        libraryTarget: 'umd',
        jsonpFunction: `webpackJsonp_${pkgJson}`,
        globalObject: 'window'
    },

1.2 主應用改造

主應用在注冊微應用時，需要注意：

• activeRule不能和微應用的真實訪問路徑一樣；
• 微應用的真實訪問路徑就是entry，entry可以是相對路徑；
• 微應用entry路徑最后面的 / 不可省略；

/**
 * 微應用為hash，注冊微應用
 * @param {*} hash 
 * @returns 
 */
const getActiveRule = (hash) => (location) => location.hash.startsWith(hash);
const defApps = [
  {
    name: 'imarket',
    entry: `/life/`,
    container: '#subapp-container',
    activeRule: getActiveRule('#/imarket'),
  },
  {
    name: 'MKCenter',
    entry: `/mkc/`,
    container: '#subapp-container',
    activeRule: getActiveRule('#/MKCenter'),
  },
]

二、部署在不同服務器

第二種方案主微應用部署在不同的服務器，使用Nginx代理進行訪問。一般這么做是因為不允許主應用跨域訪問微應用。

具體思路是將主應用服務器上一個特殊路徑的請求全部轉發到微應用的服務器上，即通過代理實現“微應用部署在主應用服務器上”的效果。

例如，主應用在 A 服務器，微應用在 B 服務器，使用路徑 /app1 來區分微應用，即 A 服務器上所有 /app1 開頭的請求都轉發到 B 服務器上。

此時主應用的 Nginx 代理配置為：

/app1/ {
  proxy_pass http://www.b.com/app1/;
  proxy_set_header Host $host:$server_port;
}

主應用注冊微應用時，entry 可以為相對路徑，activeRule 不可以和 entry 一樣（否則主應用頁面刷新就變成微應用）：

registerMicroApps([
  {
    name: 'app1',
    entry: '/app1/', // http://localhost:8080/app1/
    container: '#container',
    activeRule: '/child-app1',
  },
],

三、方案選擇

具體選擇那種部署方案，依據項目組實際情況而定，這里我選取了第一種部署方案即：主、微應用部署在同一服務器上。

進行部署時，下面四個要素需要注意：

• 真實路徑：服務器上，微應用的真實訪問路徑；
• publicPath：微應用打包時，webpack構建時output出口配置；
• activeRule：注冊微應用時，微應用響應路由的規則；
• entry：微應用入口路徑；

部署到線上后的目錄結構如下：

系列相關文章：

基於qiankun從零搭建微前端項目

基於qiankun微前端項目的通信方案

基於qiankun微前端的部署方案