这是一个创建于 1228 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果是前后端分离，前端只有静态文件。
部署起来都是直接 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 shakaraka PRO 新的端口是什么意思？不能用固定端口吗？ 我理解的访问路径是：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 不能使用固定端口呀，之前的服务会还存在呢。 因为不是先停机再启动服务，而是直接切流量到新的服务上去，实现平滑部署效果…… |
| 11 shakaraka PRO @sorakylin #9 我也觉得你需要 k8s ，不然你只能一遍遍手动操作，装 k8s 麻烦的话装 k3s 也一样 |
 | 12 isbase 2022-06-06 15:28:54 +08:00 1 @sorakylin 公司有运维的话让他们部署一套 k8s 环境或者直接买云服务商的，然后应用部署升级直接用 k8s 操作就很简单了。这套方案对应用来说做个容器化改造就行，主要成本是搭建 k8s 的基础设施，还有镜像仓库之类的 简单点就 pm2 reload 但是会稍微中断一会儿，选择停机维护或者半夜没流量的时候 |
| 13 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