下面是兩種方案的簡要描述。

傳統部署

方式

通過配置 nginx 端口到目錄的轉發。

具體可查看上一篇文章

特點

需要對外開放子應用對應的端口，將編譯好的應用文件放到對應的配置目錄。

docker 部署

方式

首先構建主應用與子應用的 docker 鏡像，通過 docker run 或者 docker-compose 的方式啟動容器。

通過配置 nginx 轉發規則，匹配訪問路徑子應用容器端口。

假設服務器 ip 是 192.168.2.192，主應用容器端口是 8889，子應用容器端口是 7100、7101。

其中應用容器在構建鏡像時是實現了 web 服務的，容器跑起來之后在服務器上是可以通過 127.0.0.1:7100 來訪問應用的。

因為前端子應用需要注冊到主應用上，需要填寫子應用的入口地址。

// index.js

registerMicroApps(
  [
    {
      name: 'app1',
      entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:7100' : '//localhost:7100',
      container: '#subapp-viewport',
      loader,
      activeRule: '/app1',
    },
    {
      name: 'app2',
      entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:7101' : '//localhost:7101',
      container: '#subapp-viewport',
      loader,
      activeRule: '/app2',
    }
  ]
}

此時服務器需要開放的端口是主應用的 8889，子應用的 7100、7101。

為了減少對外開放的端口數，我們要對 8889 端口進行 nginx 路徑匹配轉發。

修改子應用注冊信息：

// index.js

registerMicroApps(
  [
    {
      name: 'app1',
      entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:8889/app1' : '//localhost:7100',
      container: '#subapp-viewport',
      loader,
      activeRule: '/app1',
    },
    {
      name: 'app2',
      entry: process.env.NODE_ENV === 'production' ? '//192.168.2.192:8889/app2' : '//localhost:7101',
      container: '#subapp-viewport',
      loader,
      activeRule: '/app2',
    }
  ]
}

當前子應用在主應用配置的入口地址 entry 是 192.168.2.192:8889/app1，實際經過 nginx 代理訪問的是 127.0.0.1:7100，即實際訪問的是運行在服務器的子應用。

配置 nginx 代理規則：

# nginx.conf

http {
    server {
      listen    8889;
      server_name 192.168.2.192;
      
      location /app1 {
        proxy_pass  127.0.0.1:7100

        try_files $uri $uri/ /index.html;
      }
    }
    
    server {
      listen    8889;
      server_name 192.168.2.192;
      
      location /app2 {
        proxy_pass  127.0.0.1:7101

        try_files $uri $uri/ /index.html;
      }
    }
}

主應用訪問子應用流程圖：

process.png

如果子應用部署在其他服務器，還需在其他服務器配置 nginx 的跨域問題

特點

訪問權限規則由 nginx 的轉發配置決定，可開放較少端口，對外開放的端口只有主應用服務的端口。