上面是两种计划的简要形容。
传统部署
形式
通过配置 nginx 端口到目录的转发。
具体可查看上一篇文章
特点
须要对外开放子利用对应的端口，将编译好的利用文件放到对应的配置目录。
docker 部署
形式
首先构建主利用与子利用的 docker 镜像，通过 docker run 或者 docker-compose 的形式启动容器。
通过配置 nginx 转发规定，匹配拜访门路子利用容器端口。
假如服务器 ip 是 192.168.2.192，主利用容器端口是 8889，子利用容器端口是 7100、7101。
其中利用容器在构建镜像时是实现了 web 服务的，容器跑起来之后在服务器上是能够通过 127.0.0.1:7100 来拜访利用的。
因为前端子利用须要注册到主利用上，须要填写子利用的入口地址。
// index.jsregisterMicroApps( [ { 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.jsregisterMicroApps( [ { 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.confhttp { 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; } }}主利用拜访子利用流程图：
如果子利用部署在其余服务器，还需在其余服务器配置 nginx 的跨域问题特点
拜访权限规定由 nginx 的转发配置决定，可凋谢较少端口，对外开放的端口只有主应用服务的端口。