玩物得志前端网关实践

公司在快速发展，为了更好的服务业务，前端团队在性能体验、工程化建设等方面也有了更高的追求。

NodeJs提供的服务端能力，不仅拓展了前端的能力边界，也为性能体验优化和工程化提供了更丰富的方案。

上图是网关执行时内部的大致流转过程，请求经过多层中间件处理，

可以看到一个中间件的处理逻辑可以在请求和响应阶段发挥作用，这得益于Koa中间件的洋葱形机制 如下图：

下方演示了Koa中间件的写法，只需几行代码，实现一个记录访问信息和请求耗时的中间件：

const accessLog = async (ctx, next) => {const start = Date.now();await next();const rt = Date.now() - start;logger.info(`${ctx.method} ${ctx.host} ${ctx.url} - ${rt}ms`);};module.exports = accessLog;

请求经过中间件处理后到达服务层，服务层处理完成后返回结果，再经过中间件处理后响应。

如上图所示，Node是单进程 + 异步I/O + 事件循环模型，这种模型比较适合处理高并发和密集I/O的场景，不过也有一些缺陷，比如不能充分使用cpu，出现异常时整个应用崩溃等。针对这些情况，需要做一些优化：

多进程：Node本身提供了多进程方案，使用Cluster模块，只需要少量修改就能实现实现多进程，示例：

const cluster = require('cluster');const http = require('http');const numCPUs = require('os').cpus().length;

// 主进程逻辑
if (cluster.isMaster) { // 创建工作进程
 for (let i = 0; i < numCPUs; i++) {   cluster.fork();} cluster.on('exit', (worker, code, signal) => {   // 工作进程退出后的逻辑
});} else { http.createServer((req, res) => {   res.writeHead(200);   res.end('hello world!');}).listen(8000);}

有一个问题：示例里多个子进程都监听了8000端口，程序却不会报错，是因为listen方法内部判断了进程是主进程还是子进程，最终只有主进程监听了端口。最后通过进程间通信和任务调度算法来实现多进程的工作模式。

如果使用PM2来启动Node服务，无需修改任何代码也能实现多进程。示例：

$ pm2 start app.js -i max

（max表示CPU数，如果服务器的资源可以都用来跑对应的Node服务，那么让进程数=CPU核心数算是最佳实践）

数据缓存：对外部获取的数据进行缓存，减少不必要的请求能明显提升性能。Redis是一个高性能的缓存服务，将数据缓存到Redis，不仅可以减少同进程的请求次数，也可以在多个进程间共享数据。

进程守护：默认情况下，node是没有进程守护功能的。为了防止应用崩溃导致整个服务宕机，需要增加进程守护机制。

常用的两种方案：

  1. 常驻进程作为守护进程

  2. crontab + shell 定时检测

进程守护的基本逻辑，都是运行程序检测应用是否正常运行，检测出异常后进行日志记录，发送警报，重启应用等等操作。

如果使用PM2来管理Node服务，无需额外操作，因为PM2自带了守护进程。

错误日志：记录运行中产生的错误日志并分析原因，能帮助我们进一步优化应用的稳定性。

区别于常见的API网关，接管来自用户的文档请求也是前端网关的应用场景。

当前前端一些项目已经改造成了微前端的形式，多个项目可以独立开发和部署，同时跨项目访问是在一个SPA应用内的路由切换。但是也带来了一定的性能损失，比如项目初始化时需要多2次串行的请求。

这种情况下，在请求经过网关时，通过微前端服务获取内容，并预注入到文档内，在初始化过程中就不需要额外发起请求，节省了2次网络请求的时间。

如下图所示：

通过模板服务、数据预取服务、微前端服务，注入接口数据、骨架、脚本等内容，使输出的html动态化，可以有效提升首屏的访问体验。

这种方式看上去与 SSR 有一些相似。相比而言，服务端预注入数据，渲染由客户端完成的方式具有更强的通用性和更低的接入成本。

主要体现在：

  1. 业务代码无侵入 无需大规模修改代码做适配，也不会影响原有的开发习惯。

  2. 无框架兼容问题 无论开发框架是Vue、React, 或是自研的H5 SPA应用均可使用同一套后端逻辑。 

在App内缓存H5项目的文件，目前常见的方式有：

  1. App打包时包含h5项目文件  离线文件更新受发版限制，不够灵活。

  2. 文件通过接口获取 接口通常由后端同学提供，难以和前端工程体系打通，导致文件需要定期手动更新。

将前端发布系统与网关打通后，通过离线缓存服务实时生成最新的离线文件列表并返回给客户端，实现客户端缓存文件的实时更新。

如下图所示：

当前，玩物得志h5商城的流量已全部由前端网关处理。随着业务的不断发展，后续会新增更多的Node服务和网关功能。

目前网关的功能还比较简单，内集的一些服务也未做拆分，未引入RPC，我们也将持续完善网关，建设更完整健全的Node服务化体系。

本文主要分享了基于node的网关设计思路和一些实践经验。

因篇幅有限，对文中出现的一些概念未做进一步解释（如异步I/O，事件循环），对于一些值得探讨的细节（如Cluster原理、多进程任务调度、父子进程通信等等）也未做深入，有兴趣的同学请自行查阅相关资料🙈

牛年邀牛人

一起战斗、一起成长

技术、产品、UED、运营、职能等海量岗位

玩物得志期待你的加入