老哥们我整不会了，能否教教我？ SSR 前端 + API 后端应该怎样简易优雅的平滑部署
sorakylin · 2022-06-06 14:02:53 +08:00 · 2403 次点击这是一个创建于 899 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果是前后端分离，前端只有静态文件。
部署起来都是直接 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
 |
1
zinete 2022-06-06 14:05:17 +08:00
pm2
|
 |
2
superfatboy 2022-06-06 14:08:20 +08:00
不太懂后端， 单纯部署的话可以试试 pm2
|
 |
3
wunonglin 2022-06-06 14:15:06 +08:00
新的端口是什么意思？不能用固定端口吗？
我理解的访问路径是：client -> nginx -> ssr 请求 API 的链路是正常的 2 。 ssr 只是预渲染首屏而已，剩下的和普通 spa 无异 |
 |
4
Latin 2022-06-06 14:18:07 +08:00
有考虑容器化吗 docker-compose 一条命令不就解决了吗
|
 |
5
inhons 2022-06-06 14:21:27 +08:00
打个比方，你有一个列表，如果是请求接口获取数据，想要 SSR 就肯定得在服务端发生请求，却决于这个框架依赖 Node ，所以你需要 Node 服务。如同 PHP 模板的循环一样，也需要 PHP 环境。
还有一个额外的问题，客户端 HTTP 请求 API 的链路（注意，不是 SSR ，是 JSON API ）一般是哪个？ 是 2 、客户端 -> Nginx (proxy) -> api server |
 |
6
Hieast 2022-06-06 14:36:36 +08:00
我看我们前端
生产环境下客户端 -> Nginx (proxy) -> api server 开发环境下静态文件是客户端 -> Node ，接口是客户端 -> Nginx (proxy) -> api server |
 |
7
duan602728596 2022-06-06 14:52:41 +08:00  1
1. api server 的地址可以单独放在同一个文件里，这样前后端都可以 import 这一个文件
2. 端口可以使用环境变量，包括前端的打包和 node server 3. 部署服务的话，我之前的公司用的 k8s ，所以上线真的没有这么麻烦 4. C 端：请求 API 用的 1 方案，这样主要是为了跨域（因为为了兼容 IE 用的 jsonp ），以及按需返回数据 内部系统的话直接配置 proxy 解决跨域问题 |
 |
8
dudubaba 2022-06-06 15:02:57 +08:00
可以在 ssr 服务里直接用绝对路径 /api 代理 api server 地址，这样后续就不需要在 ssr 服务里维护 api server 地址了。
|
 |
9
sorakylin OP @wunonglin 不能使用固定端口呀，之前的服务会还存在呢。 因为不是先停机再启动服务，而是直接切流量到新的服务上去，实现平滑部署效果……
|
 |
12
isbase 2022-06-06 15:28:54 +08:00 1
@sorakylin 公司有运维的话让他们部署一套 k8s 环境或者直接买云服务商的，然后应用部署升级直接用 k8s 操作就很简单了。这套方案对应用来说做个容器化改造就行，主要成本是搭建 k8s 的基础设施，还有镜像仓库之类的
简单点就 pm2 reload 但是会稍微中断一会儿，选择停机维护或者半夜没流量的时候 |
|
13
sorakylin OP @Hieast #6 老哥你这生产环境没提到 SSR 啊，SSR 的话 [node server -> api server] 这个链路是得有的吧…… 😂 如果只是基本的前后端分离我还是会整的
|
|
14
sorakylin OP @isbase 没有没有，不是公司的。 是我自个部署。 就一个 SSR node 服务 + 一个 Kotlin 后端服务， 总共加起来就这俩服务。
|
|
15
isbase 2022-06-06 15:47:17 +08:00
@sorakylin 你的 SSR Node 和 API Server 是两个应用，SSR Node 应用只要通过固定的 访问地址 去调用 API Server 就行。正常情况这个访问地址通过环境变量配置一次就行了，之后不管你 API Server 怎么重启部署。SSR Node 都不用改动。
至于应用的不间断部署以及服务之前相互调用这种用 k8s 就能很好解决你的问题。你可以了解下 k8s 的 Pod 和 Service 这两个概念 你提到的重启后端口会变这种事情，一般是不应该让 SSR Node 感知到的。k8s 的 Service 就可以解决这个问题 |
|
16
isbase 2022-06-06 15:50:41 +08:00
我想了想，上一次线，得：
将新的 api server 启动到新的端口 将新的 node server 启动到新的端口 启动 node server 时手动设置一下 node server 请求 SSR 数据的地址 切 nginx 的 upstream 停掉老的 api server / node server 有经验的同志们一般是咋部署的？怎么搞最快捷 --- 你的复杂度主要是改端口导致的，要想简单就两个应用全部固定端口，重新部署的时候直接 pm2 reload |
 |
17
SixGod66 2022-06-06 16:59:51 +08:00
1 、SSR 只涉及到前端页面的首次渲染，前端页面的请求是正常转发到 node 。api 请求没有改到
2 、重新上线部署的话，应该会涉及到服务中断，即使每次发布手动改端口号。比较好的方式是用 k8s 这一套方案 |
Select Language