老哥们我整不会了，能否教教我？ SSR 前端 + API 后端应该怎样简易优雅的平滑部署

[sorakylin]

如果是前后端分离，前端只有静态文件。

部署起来都是直接 Nginx 往前面套就完事了。新版本上线的时候也就切一切 Nginx 的 upstream

前端还能直接丢对象储存、顺手打包到 api server 的静态文件里、直接把服务器文件覆盖等等，总之都挺方便。

但是如果是到 SSR 的前端，我就有点迷茫了。
因为要给前端单独部署一个 node 服务。并且这个 node 服务还要请求后端接口，那 node 那边也得维护 api server 的地址才行。

node -> api server 这一层，是要每次打包 node | 启动 node 服务的时候手动操作么，额就感觉怪麻烦的。

---

我想了想，上一次线，得：

• 将新的 api server 启动到新的端口
• 将新的 node server 启动到新的端口
• 启动 node server 时手动设置一下 node server 请求 SSR 数据的地址
• 切 nginx 的 upstream
• 停掉老的 api server / node server

有经验的同志们一般是咋部署的？怎么搞最快捷

还有一个额外的问题，客户端 HTTP 请求 API 的链路（注意，不是 SSR ，是 JSON API ）一般是哪个？

1 、客户端 -> Nginx (proxy) -> node (proxy) -> api server
2 、客户端 -> Nginx (proxy) -> api server

[zinete]

pm2

[superfatboy]

不太懂后端， 单纯部署的话可以试试 pm2

[shakaraka]

新的端口是什么意思？不能用固定端口吗？

我理解的访问路径是：client -> nginx -> ssr

请求 API 的链路是正常的 2 。

ssr 只是预渲染首屏而已，剩下的和普通 spa 无异

[Latin]

有考虑容器化吗 docker-compose 一条命令不就解决了吗

[inhons]

打个比方，你有一个列表，如果是请求接口获取数据，想要 SSR 就肯定得在服务端发生请求，却决于这个框架依赖 Node ，所以你需要 Node 服务。如同 PHP 模板的循环一样，也需要 PHP 环境。

还有一个额外的问题，客户端 HTTP 请求 API 的链路（注意，不是 SSR ，是 JSON API ）一般是哪个？
是 2 、客户端 -> Nginx (proxy) -> api server

[Hieast]

我看我们前端
生产环境下客户端 -> Nginx (proxy) -> api server
开发环境下静态文件是客户端 -> Node ，接口是客户端 -> Nginx (proxy) -> api server

[duan602728596]

1. api server 的地址可以单独放在同一个文件里，这样前后端都可以 import 这一个文件
2. 端口可以使用环境变量，包括前端的打包和 node server
3. 部署服务的话，我之前的公司用的 k8s ，所以上线真的没有这么麻烦
4. C 端：请求 API 用的 1 方案，这样主要是为了跨域（因为为了兼容 IE 用的 jsonp ），以及按需返回数据
内部系统的话直接配置 proxy 解决跨域问题

[dudubaba]

可以在 ssr 服务里直接用绝对路径 /api 代理 api server 地址，这样后续就不需要在 ssr 服务里维护 api server 地址了。

[sorakylin]

@wunonglin 不能使用固定端口呀，之前的服务会还存在呢。 因为不是先停机再启动服务，而是直接切流量到新的服务上去，实现平滑部署效果……

[isbase]

@sorakylin 你需要 k8s

[shakaraka]

@sorakylin #9 我也觉得你需要 k8s ，不然你只能一遍遍手动操作，装 k8s 麻烦的话装 k3s 也一样

[isbase]

@sorakylin 公司有运维的话让他们部署一套 k8s 环境或者直接买云服务商的，然后应用部署升级直接用 k8s 操作就很简单了。这套方案对应用来说做个容器化改造就行，主要成本是搭建 k8s 的基础设施，还有镜像仓库之类的

简单点就 pm2 reload 但是会稍微中断一会儿，选择停机维护或者半夜没流量的时候

[sorakylin]

@Hieast #6 老哥你这生产环境没提到 SSR 啊，SSR 的话 [node server -> api server] 这个链路是得有的吧…… 😂 如果只是基本的前后端分离我还是会整的

[sorakylin]

@isbase 没有没有，不是公司的。 是我自个部署。 就一个 SSR node 服务 + 一个 Kotlin 后端服务， 总共加起来就这俩服务。

[isbase]

@sorakylin 你的 SSR Node 和 API Server 是两个应用，SSR Node 应用只要通过固定的 访问地址 去调用 API Server 就行。正常情况这个访问地址通过环境变量配置一次就行了，之后不管你 API Server 怎么重启部署。SSR Node 都不用改动。

至于应用的不间断部署以及服务之前相互调用这种用 k8s 就能很好解决你的问题。你可以了解下 k8s 的 Pod 和 Service 这两个概念

你提到的重启后端口会变这种事情，一般是不应该让 SSR Node 感知到的。k8s 的 Service 就可以解决这个问题

[isbase]

我想了想，上一次线，得：

将新的 api server 启动到新的端口
将新的 node server 启动到新的端口
启动 node server 时手动设置一下 node server 请求 SSR 数据的地址
切 nginx 的 upstream
停掉老的 api server / node server
有经验的同志们一般是咋部署的？怎么搞最快捷


---


你的复杂度主要是改端口导致的，要想简单就两个应用全部固定端口，重新部署的时候直接 pm2 reload

[SixGod66]

1 、SSR 只涉及到前端页面的首次渲染，前端页面的请求是正常转发到 node 。api 请求没有改到
2 、重新上线部署的话，应该会涉及到服务中断，即使每次发布手动改端口号。比较好的方式是用 k8s 这一套方案

[Hieast]

@sorakylin 没细看你上面的上线流程，就随便说了下你问的额外的问题。上线流程没啥好说的，docker build/push 完之后 helm upgrade 完事，配置变动流量切换都是 k8s 自动做的