Node.js服务支持多SSR版本(适合测试环境)
发布于 15 天前 作者 miser 1860 次浏览 来自 分享

背景

通常,系统环境分为生产、测试和开发等多套,测试又可能因为验证不同的业务版本、BUG 部署 N 套, 意味着每套环境都会有一整套系统,从入口网关到大量的微服务节点,还有数据库等等。人力上需要有人去维护它们,无论是用于测试数还是系统的运维工作,每多一套系统都需要额外部署和购买大量资源,其中很多服务节点的版本是相同的,这都大大增加了成本。

为了解决这样的问题,我们可以通过网关路由的方式,比如测试环境,所有的应用都部署在一套环境中,通过 HTTP Header 信息将不同的应用通过路由串联起来,大概如下:

Server A V1 -> Server B V1

Server A V2 -> Server B 其它版本

前端资源怎么区分多版本

这里的 SSR 服务,基本是移动端的 hybrid 应用,所以在 Native 打开它时可以在 HTTP Header 注入版本信息,如果 PC 端,可以通过其它方式告诉服务器需要路由的版本,比如 URL Query 或 Cookie 之类

  1. 前置一个网关应用,在收到版本信息后,路由到 SSR 服务

优点:

  • 无需改变当前的 SSR 服务

缺点:

  • 作为 SSR 服务,其本身已经是一个网关,再前置一个网关有些奇怪
  • 每部署一个 SSR 服务节点,可能就需要更新前置网关的配置,需要 2 步操作
  • 需要多个 Docker 部署不同版本的 SSR 服务
  1. 改造 SSR 服务,收到 HTTP Header 版本信息后,在内部做版本的路由

优点:

  • 一个 SSR 应用,就一个 Docker
  • 只要告诉一个应用(SSR)当前有哪些是需要使用的版本即可

缺点:

  • 市面上大部分的 SSR 框架都是对应一个 SSR 版本的,不存在多版本并行,需要一定的开发和维护

综合考虑,既然是为了节省整体成本,那就彻底点,选择了第二个方案,一劳永逸。

改造 SSR 服务

CI\CD 阶段

打包客户端和服务器资源,上传到静态服务器上,其中包含重要的 client-manifest.json 和 server-manifest.json,两者记录的是资源的名称和其对应的资源访问路径,client-manifest.json 用于在服务渲染时候根据资源名插入指定的访问路径,server-manifest.json 用于将资源从静态服务器下载到 Node.js 服务器上,用于 SSR 用。

启动和运行阶段

  • 访问配置中心,找到该应用的部署版本,比如 ['v1,‘v2’]
  • 与本地版本做 diff 算法,算出新增和遗弃的版本
  • 拉去新版本的 SSR 文件到本地磁盘
  • 路由解析,因为内部的 SSR 技术被广泛应用,为了不改动代码,通过@babel/parser 和 @babel/traverse 这两个类库,先将代码转成 AST,再解析出路由信息
  • 移除本地遗弃的 SSR 文件
  • 将新的路由信息更新到路由表中
  • 定时执行上述步骤

我们用的是 Egg.js,所以上述步骤在 Agent 中完成,再广播给所有 Worker 进程。另外,为了更好的迭代和任务划分,使用PlugBoard插件化所有步骤。

架构

客户端发起访问,找到对应的路由版本(如果没有走默认路由),路由请求,有缓存直接输出,没有就走 SSR 流程,查找该版本的 client-manifest.json,找到对应的浏览器访问路径,返回给客户端。

至此,整个方案的流程完毕。项目上线后,可以通过关闭多版本共存的参数,按照市面上的常规流程运行应用。如果小团队的运维体系薄弱(没有 K8S 之类运维系统),也能用该套方案实现一定的蓝绿发布等。

原文:https://mlib.wang/2020/06/29/node-gateway-ssr-multi-version/?s=cnode

回到顶部