It was the best of times, it was the worst of times.
如果真要用一句话形容2019年工作的话，上述的双城记节选我觉得是极好。大概2018年尾的时候，公司的前端团队开始用Node.js做些后端业务等相关的工作并积累经验，与现有的Java基础架构做融合，微服务Eureka、分布式协调服务ZooKeeper、分布式配置管理平台Discon、应用监控Cat、消息列队RocketMQ、分布式署存储服务SeaweedFS、数据库MySQL等等，大量的知识扑面而来。幸好之前有.NET C# + Javascript做Web开发经历，加上一些Node.js开发经验，比如爱眠物等等，上手掌握并不难。基本上每天都有很多东西可以学，上半年忙着产出业务，也忙着封装一些基于Egg.js适合公司项目的基础代码。不过问题也是频发，上面提到的很多东西并非是Node.js生态圈大量使用的，引用一些冷门的第三个类库暴露出了EventLoop被卡住、Memory Leak的情况，下半年忙着优化和排查。
EventLoop问题
我们的Node.js程序发布到测试或者生产，经常服务端出现大量TCP Close Wait的情况，从TCP的信息反馈把重点都放在了网络层面，因为大量Close Wait导致服务无法响应新的请求，以为是上下游网络的超时时间问题，但是无论如何通过Node.js的Javascript层面做实验都未能出现，后来又查系统级别的配置问题等等，都是没查出一个所以然。
我之前写的各种Node.js服务都跑的好好的，为什么现在这家公司会出现卡死的问题呢？难道把锅甩给系统环境？
困惑和压力倍增，毕竟项目已经上生产了，金融服务出一点问题都是头大的事情。后来用alinode做监控，可惜我们的节点都在国外，而免费版本对国外节点并不友好，总是会断了监控数据。无奈只能麻烦运维同事帮忙去Docker上生成发生问题时候的火焰图，发现是Cat导致的，底层的C++代码阻碍了EventLoop的正常运行，把整个Node.js进程给卡死了。
或许你会问，为什么不早点搭建有效的监控系统去排查这些问题呢？或许就不会那么被动了！
主要有3点：
- Node.js在我们上海技术团队内部算是兴起，我们希望能承接更多的业务等去做，就如同创业一样，团队自己的技术栈在公司内部使用的多了，自然有更多资源招兵买马为以后大前端、BFF层搭建做准备。可以理解为创业公司不断的做业务拉投资，我相信在很多大点的公司，很多小团队都会有这种创业的感觉
- 每个公司所使用的某个技术栈都有自己的定位，我们也在不同领域做尝试，有倾向业务的、有做基础设施搭建的等，也在寻找Node.js适合当前公司的定位
- 经验还是缺乏点，当时运维已经有了相关对Docker的系统监控，加上
Cat业务监控感觉能抵挡一段时间，但是万万没想到就是缺少CPU的火焰图和内存堆栈图信息导致排查问题困难重重
Memory Leak问题
前后经历了2次较大的内存泄露问题
陌生类库： 其实也是知道要谨慎选择类库的使用，但有时候又该怎么说呢…
Vue SSR： 这个问题是书写Vue相关代码时候没注意导致的，其作者在Github上也留言指出了相关的解决方法
目前组内对前端或者Node.js的监控体系在逐步搭建和迭代的过程中，一个监控Hub，通过TCP通信将所有的Node.js进程与其进行长连接，实时双向传输数据，按照命令生成火焰图或者内存堆栈信息。
优化了静态资源打包和分发流程
打包这个东西自然还是基于Webpack的封装，谁让人家NB呢。整体流程之前比较复杂，做了一次重CI的优化，也适合目前的小型团队使用，从中抽取了一套插件式的程序加载流程，整体思想还是抄的Egg.js，谁让人家好用好扩展呢！
为什么不完全基于Egg.js的插件开发方式？
团队对底层架构级的东西不能完全基于Egg.js，会有更多多元化的框架引入（看具体场景，尽量少，但万一呢），通过适配层就能让底层代码依附到不同框架上。所以我既不能依附Webpack写太多插件，也不能依附其它的Node.js应用框架，毕竟Node.js五花八门、百家争鸣，我们想办法把他们粘合在一起就好，所以需要一套自己的加载器。
从2019迈向2020
2019年对我而言确实又坏又好，坏的是工作上的问题一个个来，万幸的是都一个个解决和迭代中了，确实经历多了，学到的东西和成长也就多了。期望2020能把一直想做的BFF层可以慢慢做起来，另外监控等小项目能有机会开源。
Comments