Node.js 在微医的应用场景及实践高翔

时间 2019-11-30

标签 node.js node 应用场景实践高翔栏目 Node.js 繁體版

原文原文链接

微医前端团队方凳雅集转载

我是来自微医集团消费事业群的前端工程师高翔，这篇文章整理自我在《第一届缤纷前端技术沙龙》的主题分享《Node.js 在医疗行业的应用》，介绍了 Node.js 在微医的发展历程和应用实践经验。
前端

微医是总部位于杭州萧山的一家互联网医疗公司，咱们的前端研发人员从2015年的几我的发展到如今的120多人，前端技术栈体系发生了巨大的变化，下面这张图展现了咱们部门前端团队的技术栈演进过程。webpack

16年以前主要是先后端耦合的开发方式。
git
17年开始引进 Vue，进行先后端分离，并开始尝试作 Vue SSR 的探索。github
18年全面推 Vue SSR，积累了必定的 Node.js 经验，出现了愈来愈多的线上 Node.js 应用。web
今年主要是将以前的解决方案沉淀下来，变成框架、文档、插件、脚手架等，来更好的支持需求的迭代。数据库

能够看到在微医， Node.js 在线上应用起步较晚，可是发展很快，例如消费线业务基本都迁移到了 SSR 技术体系。下面这张图是咱们公司前端应用的分布状况。编程

能够看到，集团整体前端应用中，Node.js 应用大概占比 1/4，而在 Node.js 应用中主要是 SSR 应用，其次是一些全栈体系的内部应用，接着是一些 API 服务，作一些接口的聚合和转发。
json

因此我今天主要从 Vue SSR、内部应用和 API 服务来介绍一下 Node.js 在微医的使用状况。后端

应用场景一：内部工具浏览器

咱们团队在业务之余作了不少内部效率工具，来服务于集团内的其余角色，包括开发、测试、运营、产品等等，这些应用都有一个特色：使用 Node.js 来进行后端服务层的开发。这边我列举了三个咱们的内部应用：

筋斗云 - 需求发布管理系统
魔方 - 可视化活动页面搭建平台
智能运营管家 - 社群运营工具

其中，筋斗云系统用于支撑需求的发布管理，是使用频率最高的内部平台之一。

咱们以需求为单位，将整个需求发布流程中一些须要人工操做和不严谨的点整理出来，作成一个平台，来进行发布流程的把控，提升需求发布的效率和质量，其中的一些功能，好比：经过 GitLab API 来作分支智能合并、发布计划管理、一键发布、前端应用 package.json 变更监听、release 分支落后检测......这些小功能均可觉得开发和测试提升成倍的效率和质量。这个系统里面 Node.js 也作了很是多的工做，好比数据的持久化、API 设计、Dubbo 服务调用、钉钉消息推送、邮件提醒以及定时任务等等。

有了 Node.js 的加持，前端工程师可以发挥本身丰富的想象力，将想法变成产品，创造一些可以提升数倍效率的工具。

应用场景二：Vue 服务端渲染

除了内部应用，咱们在 Vue SSR 方面也作了不少的研究和实践，先后端同构（同一种编程语言，同一套开发模式）的应用拥有单页的用户体验，又天然支持 SEO，让后端同窗从表现层解脱出来，专一服务开发。

在 Vue SSR 中，咱们的 Node.js 主要作了如下工做：

异步数据混合

咱们参考 Nuxt.js 中对 asyncData 的操做，在 asyncData 钩子中获取数据后直接将数据对象返回，而后与组件中的 data 函数的对象进行混合，页面组件能够像操做 data 同样操做 asyncData 返回的数据，这样就能够很好的与 Vuex 解耦（官方推荐的作法是将 asyncData 中获取的数据存到 Vuex 中，组件从 Vuex 中取数渲染）。

通用工具封装

咱们作了一些通用方法的封装，好比：Cookie操做、路由操做等等，抹平了服务端和客户端的差别，同时还输出了一些很是好用的插件。

feb-alive 是一个 Vue 页面级缓存插件，使用 feb-alive 来代替 keep-alive 进行页面缓存，可使咱们的应用达到浏览器级别的路由体验（前进刷新，后退缓存），详细使用能够参考 https://github.com/wefront/feb-alive。

异常降级机制

对于通常的 SSR 应用来讲，在服务端发生异常时都会返回一个 500 的页面，其实对于某一些场景，好比：接口调用异常、asyncData 中写了浏览器的代码，对于这种状况的异常咱们能够返回一个 SPA 应用，在用户的浏览器上进行渲染，达到高可用。在介绍降级机制以前，先来看降低级的效果。

一开始是正常的服务端渲染，接着在 URL 中带上一个 degrade 参数后，服务端会返回一个 SPA 应用。而后我模拟了 asyncData 中接口异常的状况，能够发现服务端也返回了一个 SPA 应用，而不是一个 500 的异常页面。

接着介绍一下 SSR 降级机制的实现原理。首先若是要实现这样一套降级机制，咱们得在构建客户端代码的时候生成一个 SPA 应用：

了解 Vue SSR 的同窗都知道，服务端渲染会输入一个 window.__INITIAL_STATE__ 变量，里面存放着服务端的 Vuex 数据快照：

在客户端入口文件（entry-client.js）中，咱们需求经过 window.__INITIAL_STATE__ 变量来判断本次渲染是正常渲染仍是降级渲染，若是是降级渲染，还须要手动的调用 asyncData 方法进行首屏的数据预取。

至此，降级的入口文件就完成了，接下来就是在 SSR 的流程中，咱们在什么阶段将这个 SPA 文件返回给浏览器。

这边有一个流程图，当请求进来时，判断 URL 中是否有 Degrade 参数或者配置文件中有没有开启全局降级，若是有则进行降级，若是没有再看服务端渲染流程中有没有发生异常，发生异常也会进行降级。另外还要区分开发环境和正式环境对 SPA 应用的获取规则：开发环境下从内存中取，正式环境从磁盘中取，由于开发环境下用了 webpack-dev-middleware，是构建到内存中的。

到这里，整个降级机制的实现原理就介绍完了，有了这个机制，咱们能够很是方便的让应用随时降级成单页，来观察接口的调用（开发、测试利器）。并且，若是服务端渲染出现异常，用户也不会看到一个冷冰冰的 500 页面了。另外，对于一些大流量的场景，也能够经过配置文件开启全局降级，让 SSR 应用直接变成一个 SPA 应用，减小服务器的负担。

服务端缓存

对于一些与用户无关的接口和页面，就是说不论是谁访问返回的结果都是相同的，对于这些接口咱们可使用 LRU-Cache （最近最少使用）作服务端缓存，更好的下降内容到达时间。

接入全链路追踪

咱们将 SSR 应用接入到内部的全链路追踪系统中，在现代的微服务架构中，应用的调用链路是很是复杂的，而 Vue SSR 应用又是在调用链的最顶端，因此将 Node.js 接入这套全链路系统是很是有必要的。

内部框架沉淀

咱们将这套 SSR 解决方案封装成一个内部框架、来更好的支持需求的迭代。出于框架可维护性、可升级性的考虑，咱们将 Webpack 和 Server 部分都内置了进去，但同时也暴露了方法让用户作一些自定义的操做（webpack-chain、middleware等）。

应用场景三：API 服务

BFF 的概念在国内是阿里最早提出来的，主要是前端工程师维护的在端应用和底层服务中间的一层，用来针对不一样的用户设备输出不一样的接口，作一些数据的聚合、裁剪、适配等。在微医咱们主要作了一些底层服务的调用，进行接口的聚合和转发，即 Node.js API 服务层。

上面这张图展现了 Node.js 在整个微服务架构中的位置，最上层的是一些端应用，当一个请求发起时首先会通过 Java 的网关，网关做为微服务的惟一入口，进行请求的分发和通用逻辑的处理，网关下面是一些 API 服务，用来提供 HTTP 接口，最底层是更加原子化、细粒度的 Dubbo 服务。Eureka 是网关和 API 层的注册中心，Zookeeper 是 Dubbo 层的注册中心。Node.js 在 API 层主要作了如下工做。

Dubbo 服务调用

咱们使用了社区提供的 dubbo2.js 进行 Dubbo 服务的调用，而且作了一些封装来优化发开体验。

固然，官方还推荐 jar-to-ts 的方案，将 dubbo 服务的 JAR 包转成 TS 定义，来进行更方便的调用。

接入 Eureka 注册中心

若是想接入统一的 API 网关，首先得将咱们的应用接入到 Eureka 注册中心中，使用社区提供的 eureka-js-client 这个库能够很是快速的进行 Eureka 的接入。

装饰器路由封装

咱们的应用是基于 Egg.js 和 Typescript 的，可是咱们发现 Egg.js 的映射式路由对开发体验有点不友好，因此咱们作了装饰器路由的封装。

经过装饰器，咱们不只能够作一些路由的定义，还能够作一些前置逻辑的处理，好比请求头判空、权限校验、接口文档生成等等。

内部框架封装

Aug.js 是一个基于 Egg.js 基础框架，使用 TypeScript 开发的 Node.js 应用框架，集成了 Log、APM、Gtrace 以及 Eureka 等基础中间件，致力于打造通用的企业级 Node 应用解决方案。

Node.js 生态建设

其实咱们在团队内 Node.js 的生态建设上面，还作了一些其余东西，下面我主要对全链路追踪和性能监控平台作一下介绍。

全链路追踪

为何须要全链路追踪系统

在现代化的微服务系统中，客户端的一次请求操做，可能须要通过系统中多个模块，如何肯定客户端的一次操做背后调用了哪些应用，通过了哪些节点，前后顺序是怎样的？当出现 BUG 时，如何快速的定位问题出如今哪一环？还有每一个应用的性能如何，耗时有多长，咱们如何快速定位应用的瓶颈所在？

全链路追踪系统的原理

当一条请求进来的时候，会生成一个惟一的 TraceId，来标记一条链路，每当进行后续的调用时，都会将 TraceId 传下去，来串连起来整个链路。

Span 是一个上报单元，是一个原子化的操做，一个程序块的调用，或者一次RPC/数据库访问均可以认为是一个 Span，每一个 Span 都遵循一个固定的数据结构。

经过 TraceId 咱们能够把每一次请求通过的系统收集起来：

每一层把 TraceId 传递下去（Http Header、Dubbo Attchment）。
每一层把 TraceId 上报上去。

经过 SpanId 和 ParentId 咱们能够构建树的父子关系：

每一层把 SpanId 传递下去。
每一层在构建 Span 时，若是在请求头中有 SpanId 带过来，则标记 ParentId 为父级的 SpanId。

const spanId = generateUUID16()
const spanCtx = { spanId }
const parentSpanId = req.headers['span-id']
const parentTraceId = = req.headers['trace-id']
if (parentSpanId && parentTraceId) {  
    spanCtx.traceId = parentTraceId  
    spanCtx.parentId = parentSpanId  
    spanCtx.reference = reference.CHILD_OF
} else {  
    const traceId = generateUUID32()  
    spanCtx.traceId = traceId  
    spanCtx.parentId = traceId.substr(-16)
}复制代码

复制代码

经过 startTime 能够肯定同级的前后顺序，startTime 标记生成这条 Span 的时间，同级节点 startTime 排序后的顺序就是节点展现的顺序。

Node.js 和 Java 层面都是经过 Kafka 生产者将数据上报到消息队列里面。客户端须要作特殊的处理，由于客户端的应用协议比较单一，通常是 HTTP，因此不支持消息队列上报，须要加一层代理层。ES 负责消费数据，进行链路的分析，最后由 Web 平台进行链路的展现。

其实除了最基本的链路分析，这套系统还能够作：慢调用分析、冷热应用、相互依赖、日志平台整合、监控中心整合等等。

上面这张图是 Node.js 应用接入到这套链路追踪系统后的链路图，能够很是清晰的看到在服务端调用了哪些接口，甚至配合 Browser 端的 SDK 能够将 SSR 应用的链路连接起来，进行用户页面访问路径、内容到达时间、页面性能的分析。

性能监控平台

咱们对比了经常使用的 APM 产品，从代码侵入、实现方式、成熟度、数据安全性以及性能等各个方面进行对比。

咱们想要的是一个能够在公司内部部署、侵入低、基础监控完备的 APM 产品，最终咱们选择了 Elastic APM 方案。

这套性能监控方案能够知足咱们目前的需求，若是须要更深刻监控及分析，还能够进行二次开发。

总结

今天给你们介绍了 Node.js 在微医的应用探索及沉淀的状况，能够看到：

Node.js 是一个效率利器，有了 Node.js 的帮助，前端工程师能够好的将想法变成产品。

不论是 SSR 应用的容错降级、全链路追踪仍是性能监控，能够看到，对于线上应用来讲稳定性保障设施是必不可少的。

最后，重要的话要说三遍：不要重复造轮子！不要重复造轮子！不要重复造轮子！