好未来数据中台 Node.js BFF实践(一):基础篇

好未来数据中台 Node.js BFF实践系列文章列表:

  • 基础篇
  • 实战篇(TODO)
  • 进阶篇(TODO)

好未来数据中台的Node.js中间层从7月份开始讨论可行性,截止到9月已经支持了4个平台,其中3个平台生产环境稳定,另1个在测试阶段近期上线。

我4月份刚加入数据中台,原本的想法是半年内不做大刀阔斧的改变,优先完善团队现有的基建设施,比如组件库、charts库、工具、规范等。Node.js中间层的立项完全是一个意外。

某次中台周例会上讨论到前后端协作效率问题,我一时嘴贱提到Node.js中间层的想法,将应用平台的一些与DB无关的逻辑放到Node层让前端伙伴们负责,让后端伙伴集中精力做底层服务建设。

本来就随口一提,结果老板当真了,当场拍板:搞!我当时的表情大概是...

没办法,自己画的饼,哭着也要吃完。

咦?怎么有点往日重现的感觉?曾经在腾讯云,刚给客户吹完牛逼就想抽自己大嘴巴~

Node.js 的定位

数据中台 Node.js 中间层的定位类似一层 API Gateway,承载接口代理、聚合以及与DB 无关的部分业务逻辑

在现阶段数据中台的服务体系中有两类服务:常规 Java 后端和 T-Service 。后者是数据中台将 OneService 方法论落地的统一数据服务,即服务于各个前台事业部,也为数据中台内部的各个应用平台提供数据服务。

使用 T-Service 的协作流程简单描述就是数仓伙伴建表后将数据源接入 T-Service,然后 Java 后端伙伴配置取数 SQL,最后前端从统一的 query 接口查数展示

T-Service 不直接对接前端,旧架构体系下需要在前端与 T-Service 之间搭建一层 Java 服务,说白了就是一堆 Controller,从 T-Service 取数后做一些很简单的二次加工给到前端。Node.js 中间层的目标之一就是将这些复用性很差的 Controller 拿过来,好处有两点

  1. 旧架构体系下完成一个数据查询功能需要牵涉数仓、后端和前端三方,新架构下只需要前端和数仓;

    前提是前端伙伴需要掌握 SQL,前期由后端同事辅助,过渡后需要前端伙伴自己写 SQL。

  2. 基于第一条, Java 后端伙伴的生产力被解放,集中精力做底层建设或通用性更强的接口。

除了以上两条以外还有另一个隐藏优势,前端的能力边界扩宽后技术视野也会更宽阔,能够从纵向角度上全面思考业务

具体到职责分配上,Node.js 作为直接与客户端交互的服务层,登录认证是最基本的功能之一,Java 后端服务只需要关注 Node.js 传递的用户 ID 即可。

数据中台有一个统一的用户管理中心提供登录/登出服务,客户端登录后会接收管理中心下发的 JWT,后续业务接口的请求会验证 JWT 的有效性。接入 Node.js 中间层以后,JWT 的验证逻辑就上浮到了 Node 层

由于 Node 层只需要验证(解密) JWT,不需要 JWT 加密算子,所以非对称加密是相对较优的方案,比如 RS256。用户中心提供一个获取公钥的 API,Node.js 拿到公钥后进行解密即可。

技术选型

技术选型方面并没有纠结太久,其实用什么框架都行,虽然每个框架都有各自的优缺点,但由于 Node.js 中间层的逻辑不会很重,复杂度不高,框架层面的问题几乎不会成为瓶颈。所以一句话总结技术选型的核心出发点就是:用着舒服就行了。

最终用的 NestJS v7,当然也并不是完全没有量化的因素。首先跟 express 和 koa 相比,NestJS 的模块抽象层次更高,将中间件进一步抽象为 guards 、 filter 、 interceptor 等等,能够满足大多数场景,几乎不需要感知中间件这个概念。虽然有一定的理解门槛,但熟悉之后写代码能够将各模块的功能划分更加清晰容易维护。其次,NestJS 与 Express 完全兼容,生态足够丰富。最后,完美支持 TypeScript,搭配 DI 、IoC 等机制,代码的结构和模块体系非常清晰。

之所以选了 v7 而没有用最新的 v8 版本,原因之一是 NestJS 的 v8 版本依赖 RxJS v7。RxJS v7 废弃了很多 v6 版本的操作符,用惯了 v6 一时之间切换过来很不习惯。

不过 NestJS 也并不是没有缺点。举个例子,Node.js 通常使用 async hooks 进行异步资源跟踪,比如日志。NestJS 的依赖注入机制提供了一种 Request 作用域的 Provider,表面上看完全可以解决请求上下文的资源共享,但实际上并不好用,因为 NestJS 对 Request 作用域的 Provider 有一条额外的限制:依赖 Request 作用域 Provider 的 Provider 也必须是 Request 作用域的(很拗口吧)。由于日志模块是通用模块,被很多模块依赖,所以在这条限制下,从 app scope 到 module scope,几乎每个 Provider 都会被牵涉。所以最后还是用了常规方案:cls-hooked。

也有可能是我学艺不精,还没掌握 NestJS 的精髓,欢迎指正。

服务治理

Node.js 服务部署在公司的未来云 k8s,上层没有接网关,所以 https 的支持是在由 ingress 这一层提供,目前的方案比较原始,没有自动化工具,需要手动修改 ingress 配置。除此之外,在服务治理方面需要重点关注两个方面:守护进程日志管理

守护进程

在 k8s 普及之前,Node.js 的进程守护需要借助一些第三方工具,比较知名的比如 forever 和 pm2。使用这些工具会占用一些额外的机器资源(cpu、内存),借助 k8s 探针完全可以取代它们。

未来云提供了两种存活检查的探针:Http 和 TCP。

Http 探针本质上是向某个接口发起 Get 请求,响应成功状态码代表服务健康,否则判定为坏死重启 pod。对于 Node.js 来说就相当于一次请求,所以需要 Node.js 提供一个专用的接口比如/health,需要额外工作,并且这个接口不应该记录日志。

TCP 探针本质上是尝试与容器建立 socket 连接,成功代表服务存活,否则判定为坏死重启 pod,对 Node.js 服务本身没有依赖和影响。

Http 探针由于发起的是一个真实请求,所以通用性更强,但是需要额外的工作。

如果 Node.js 上层有额外的一层反向代理比如Nginx,那么一定不要使用 TCP 探针。因为 Nginx 本身就能够建立 TCP 连接,所以如果用 TCP 探针的话检测结果永远是健康的。

数据中台的 Node.js 服务每个 pod 都是单核,没有起多进程,也就没有使用反向代理的必要性,所以最终使用 TCP 探针做存活检测。

日志管理

与 Java 服务的日志一样,Node.js 服务的日志也是 ELK 一把梭。需要注意两点:

  • 与 Java 后端的日志串联
    Node.js 与 Java 后端约定一个日志串联的规范,Node.js 向 Java 发起的请求头中携带一个额外字段 x-trace-id,值为 Node.js 生成的 requestId。

  • 过期日志文件及时清理
    Node.js 的日志文件以天为单位分割文件,每天都会创建几个单独的文件(errors/warnsing/infos/expcetions),如果不及时清理的话会把磁盘打爆进而造成服务重启,所以需要添加一个定时任务清理过期文件。

总结

现阶段的 Node.js 中间层刚起步,还比较轻量,以后还会遇到更多挑战。本文简单记录了一些搭建过程中的经验,有正面的可能也有反面的,欢迎指导。

下一篇会写一下目前接入的几个项目中 Node.js 中间层扮演的角色和具体做的事情,敬请期待。

posted @ 2021-09-29 16:35  JunpengZ  阅读(495)  评论(0编辑  收藏  举报