Node.js项目经历

正文

上一篇文章提到了我们项目中使用了Node，有兴趣的可以看下

刘卿：一个前端的自我回顾

背景

随着前端组件化方案的落地，整体的前端效率得到了充分的提高，并且当前是有一层Node在做代理层的状态下，研发的瓶颈逐渐转移到php这一端。表现出来的是：

• 迭代速度慢
• 遇到问题无法快速定位和排查
• 稳定性受到质疑，经常出现查询不动，或者整个服务宕机的情况
• 大量重复的领域在跑
• 数据量大，导入数据时锁表
• 人员的素质不能跟得上业务的迭代速度

具体怎么做的先卖个关子，先说说我们在工具这一侧是怎么做的。

Node.js框架

框架选用的是express，在这个基础上结合当前的业务现状出来的一整套框架，给一张图。当然画图不是我擅长的点，所以凑合看吧。。。

日志：

应用日志是通过log4j来收集的，按照天写成文件，存储在到本地磁盘。一个http请求进入到服务后，会有一个唯一的key会贯穿整个http请求的生命周期，如下图：

最终在写入每一条日志时，都是会带有该标记。目的是如果当前系统有一个异常操作，可以快速锁定整个流程。

config：

config包含3个配置项 环境相关、应用启动、nginx配置。

应用启动配置项会选择当前的环境变量，根据不同的环境变量启动不同的环境变量配置。

nginx配置就是一个单纯的nginx配置文件，不同环境唯一的差异就是静态资源缓存和ssl的配置。

环境配置包含端口（创建项目时自动生成）、第三方服务的配置、数据库相关配置、一些应用相关的配置。

ORM

ORM是一个自研发的东西，主要支持的是mysql、redis。功能包含通过sql的方式增删改查、事物、分库分表支持、批量插入/更新优化、sql安全的处理等功能。

路由

路由通过文件夹自动生产，更好维护和管理。

框架

除了上面说的这些集中在框架中，还有就是对Api和controller进行了封装，规定了业务逻辑的写作区域，防止内存释放有问题，导致的内存泄露。

业务梳理

从当前业务的入口入手，展开来看当前的业务情况，这里找到其中一个项目的一张图

到这里其实很容易看到当前项目的一个业务模型

这样整个服务设计其实非常容易达成了。而且指标计算的服务可以抽象成一些通用的服务，所有的项目都基于这些服务来完成。

还有部分节假日相关的数据，有独立的服务通过crontab来定时抓取，补充数据源。

整体的架构大概就是这个样子，这里有一张之前分享的图，直接拿来用

所有的服务都是通过内网来交换数据，来减少带宽层面的消耗。

数据整合

早期的数据库是多个团队同时设计和维护的，所以其中各个方面差异性非常大，而且不是每一个团队都适合做这样的事情，毕竟术业有专攻。我接手后大概有下面这些问题：

1. 数据膨胀比较快，需要分库分表和索引优化。
2. 配置迁移出去减少维护成本
3. 增加指标相关的配置逻辑
4. 表设计不合理的问题，最后解决，依赖太多

当前项目已经存在一段时间，单表的数据量有到几亿行，当前这个节点下如何快速的入手解决查询慢，写入也慢的问题，这是最关键的，所以我们着手的第一件事就是先拆开，这样能把单库数据量降下来。

请到「今天看啥」查看全文