基于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：微應用入口路徑；