网易智慧企业 Node.js 实践(2)| 平滑发布和前端代码

原创
2020/05/20 11:08
阅读数 199

健康检查

 

前文提到我们通过网关把流量转发到Node 应用,那网关是如何确定 Node 应用的可用性呢?

 

如果Node 应用在发布的过程中也把流量转发过来,就会导致请求失败,所以我们的网关会对Node 应用做一个健康检查,要首先确定 Node 应用是健康的,也就是可以对外服务的。具体来说就是网关会每隔30秒调一下 Node 应用的健康检查的 HTTP 接口,如果接口返回的 code 是200,那就表示 Node 应用是可用的,用户的请求在下次检查之前都会转发过来,如果返回其他 code,表示应用不可用,请求就不会转发过来。过30秒再重复这个过程。

 

                                                                    【示意图】

 

这个方案实现起来非常简单,只要再Node 添加个能正常请求的 HTTP 接口即可,比如我们用的接口 `/health/check`它的 controller 内就 `this.ctx.body = 'OK'`就可以了。如果 Node 应用正常启动,可以接受用户请求,那么这个接口返回 code 就会是200,如果这个接口不能正常访问,返回的code不是200,那么也意味着整个应用是不能访问的。

 

那上面这个方案就没有问题了吗?肯定是有的,比如我们在发布时候,首先要让Node 应用下线,如果恰好 Node 应用刚被健康检查通过后就下线了,那么就会导致后面30秒内转发到 Node 应用的流量访问失败,所以我们有了升级方案-平滑发布。

 

平滑发布

 

平滑发布就要跟发布系统进行配合了,就是我们在发布应用的时候发布系统会自动调用Node 应用的下线接口,发布完成之后会调用 Node 应用的上线接口,这样就可以通过一个全局变量控制应用的状态,而这个状态是和应用的真实状态没有关系的。调用下线接口后,应用状态置为下线,然后等待一段时间才真正让应用下线,所以如果这时有流量进来应用依然可以正常服务。

 

                                                                    【示意图】

 

逻辑很简单,但是实现的时候要考虑到Egg.js 的多进程模型,Egg.js  一般根据服务器的 CPU 核数来定启动相应数量的 Worker 进程,这样就可以完美利用多核资源。每个进程里都跑的是同一份源代码,这些进程同时监听一个端口,所以当发布系统调用下线接口时,只有其中一个进程会收到请求,如果只是把收到请求的这个进程的全局变量置为下线的话,其它的进程在收到健康检查的时候依然返回的是在线状态,这样就不对了,所以要使用进程间通信,告诉所有进程下线。

 

基于这些分析我们实现了Egg.js 插件 `pp-ndp` ,另外由于 Egg.js 插件中不允许有路由,所以我们通过中间件的形式实现,主要代码如下:

 

```

const { request } = ctx;

const { path, hostname } = request;

if (path === online) {

    app.messenger.sendToApp(ONLINE, '');

    ctx.body = 'NDP: Nodejs Is Online';

} else if (path === offline) {

    app.messenger.sendToApp(OFFLINE, '');

    ctx.body = 'NDP: Nodejs Is Offline';

} else if (path === check) {

  ctx.body = 'NDP: Nodejs Start Success';

} else if (path === status) {

  if (app[ISONLINE]) {

    ctx.body = 'NDP: Nodejs Is Online';

  } else {

    ctx.status = 500;

  }

} else {

  await next();

}

```

 

当然这个方案的前提是有多台Node 服务机器,并按分组进行发布。如果只有一台机器就没必要这么麻烦了,反正发布一定会导致停服。

 

插件`pp-ndp` 为了满足不同业务需求,online、offline、check、status 这四个 URL 是支持自定义配置的。

 

这个方案不仅解决了我们平滑发布的问题,让发布不再那么恐怖,而且还可以利用这个方案让应用上线后能够更好的服务,比如:可以在应用获取配置之后再把应用置为上线状态,或者可以在应用成功注册或连接某服务之后再把应用置为上线状态。让应用保证最健康的状态对外服务。

 

代码上CDN 和 代码发现

 

看到CDN 可能会奇怪, Node 应用为什么要 CDN,其实是因为我们为了方便使用同构渲染,而把前端代码和 Node 代码放在了一个应用里面,虽然这样解决了服务端渲染代码访问问题,但是客户端代码还是走 CDN 比较合理。关于 webpack 使用 CDN 网上有很多文章可以参考,我主要介绍下如何发现前端代码的,包括代码上 CDN 和模版中插入前端代码 URL。

 

主要是使用`webpack-manifest-plugin` 这个 webpack 插件,它会生成一个文件,比如我们用的 `manifest.json`,里面包括前端代码资源名称和对应路径,类似:

 

```

{

  "vendor.js": "/static/f5e0281b/js/vendor.chunk.js",

  "vendor.js.map": "/static/f5e0281b/js/vendor.chunk.js.map",

  "Page.css": "/static/f2065164/css/Page.chunk.css",

  "Page.js": "/static/f2065164/js/Page.chunk.js",

  "Page.js.map": "/static/f2065164/js/Page.chunk.js.map",

}

```

 

只需要把这个文件内列的文件上传到CDN 即可,不需自己手动去打包目录一个一个找。在上传 CDN 的时候给每个文件保持同样路径。使用我们实现的工具 `pp-cdn` 在发布过程中的代码编译完成之后进行上传。在 Node 模版中引用代码时,使用我们开发的 Egg.js 插件 `pp-just`,使用方式:

 

```html

<script src='{{ctx.just.use("Page.js")}}'></script>

```

 

插件内部也是读取`manifest.json` 文件,输出加上 CDN 域名之后的 URL,比如上面的代码就转变为:

 

```html

<script src='https://qiyukf.nosdn.127.net/huke/static/f2065164/js/Page.chunk.js'></script>

```

 

其实之所以这么做,是为了利用前端代码多版本带来的好处,我们是使用文件hash 作为文件路径的一部分作为多版本控制的,这样每次发布后编译后会把新生成的文件路径写入 `manifest.json`,然后通过上面讲的方式就可以获取到最新版本的代码。

 

当然目前Node 和 前端代码在一起是不合理的,可能会导致不必要的发布,后续应该会完全分离,但是使用`manifest.json`也可以作为我们后续代码分离后的方案之一。

 

总结

 

技术方案的选择一般要结合团队已有的技术方案和业务需求,本文介绍的平滑发布方案在我们业务前期,确实解决了我们的发布问题,让发布变得更安全。

 

但是随着业务发展我们需要灰度环境,来更好的确保应用的健康状态,提前发现应用中的问题。另外我们还需要知道我们的应用的运行状态,所以在下一讲内容中,我们会分享关于灰度发布和应用监控相关的内容。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部