序言：NodeJS真的是玩具吗？真有人敢用这个玩具来写后端做事，它能支撑成一个千万级别的用户量级吗？怎么就带着我的团队稀里糊涂把这事而且做成。这篇文章将分享这次项目的并发实践履历。
一、项目背景老板说：公司要搞计策NPS，须要一套问卷系统。要能配置问卷和回收答案就行，后端木有资源，给个机会前端搞全栈哈，先大略搞哈，早期没啥量，不用慌哈，看好你们哟。
写个问卷系统，将它分成两个部分就行。
问卷配置管理端：不便是一个内部系统，公司内部人用，有啥量的，问题不大。（不在本文内容谈论范围）问卷做事：要给用户访问的呀，要做高并发呀。早期不是没啥量嘛，先用NodeJS写，等并发起来后，如果搞不定再让后端接锅呗，再说业务能不能起来都很难说，（反正人和代码有一个能跑就行）
难得有一个机会可以搞全栈而且还要一定的用户体量，虽然很慌，但是，还是很有干劲的呀
二、系统架构
有一个搞全栈的机会，虽然很慌，但是，还是很有干劲的呀，消化老板的大饼，是时候要开干了。
设计一个架构图，再找有履历的后端大佬们过一下。
上图黄色部分是配置问卷的管理的模块，右边绿色部分问卷对外的做事模块，在全体架构全局来看，须要支持并发的实在只有两个模块：
GET 问卷页面渲染模块POST 答案上报模块三、应对之策按照问卷回收履历来说，大概，10个问卷页面浏览 > 才会有1答案上报 处理并发要命的是页面读接口，其次是答案上报的写接口。并发处理开干了。
3.1 页面渲染并发处理
渲染运营配置的问卷页面，并发量是全体toC流量最大的，最具有寻衅难度的。 接下来通过拆解全体接口的过程，然后利用多级缓存策略和改进的CSR来办理并发难题。
3.1.1 渲染流程
渲染前，须要获取到数据库运营配置问卷的题目干系的信息
pageData，每个问卷配置的内容不一样，运营啥时候修正问卷也不知道，须要在数据库拉去配置对应问卷ID的配置给到前端来渲染页面；（页面级别的数据，变更不可控）render是一个JS渲染库，所有问卷都是一样，只要不发布版就不会更新，放到CDN来扛并发即可。（运用级别的数据，变更可控）
3.1.2 页面数据缓存策略pageData是页面数据，虽然要实时来取，但是可以做适当的缓存策略。拉去pageData读接口采取了多级缓存，流程如下：
首次通过远程调用取读取内部管理的问卷配置数据；渲染页面完成，写入内存缓存和Redis缓存；下次渲染，先按照内存 > redies缓存读取，没有再重复首次访问逻辑。通过设置多级缓存，减少mysql的并发压力和页面加速
3.1.3 渲染模式
为了向并发妥协，没有利用做事器端渲染。
我们选择了CSR。
但是，为了页面性能更好，我们改进CSR模式，把本来要读pageData接口和html框架页面放到做事器端合并起来。
/ html拼接手法 @param pageData，问卷题目配置数据 @param resouceInfo，前端资源版本掌握，由做事端掌握做长缓存更新利用/function render(pageData，resouceInfo){ const html = `<!DOCTYPE html> <html lang="en"> <head> <title>${pageData.title || '问卷'}</title> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"> <meta http-equiv="X-UA-COMPATIBLE" content="IE=Edge,chrome=1"> <meta name="nightmode" content="disable"> <link rel="shortcut icon" type="image/x-icon" href="//wenjuan-static-cn.heytapimage.com/wj-prod/faviconIcon.ico" id="favicon"> <!--问卷页面样式文件--> <link href="${resouceInfo['main-css']}" rel="stylesheet"> <!--babel垫片--> <script content="babel-polyfill" nomodule src="${resouceInfo['babel-polyfill']}"></script> <!--vue百口桶--> <script content="vue-all" src="${resouceInfo['vue-all']}"></script> </head> <body ${bodyStyle}> <div id="app"></div> <script content="page-data"> // pageData 直出到页面并挂在在window，方便vue利用 window.asyncData = ${JSON.stringify(pageData)}; </script> <!--问卷页面入口js--> <script content="main-js" src="${resouceInfo['main-js']}"></script> </body> </html>` return html}
改进的CSR模式，在不增加做事器负载的情形下，减少了数据读取过程，将getPageData接口和html合二为一。页面在浏览器渲染，不用在要求后端接口获取pageData，首屏渲染速率更快！
！
！
3.2 上报接口并发处理
问卷答案上报接口，虽然量只有上面渲染接口的1/10，但是它是个写接口，从外网流量写入是内部系统做事的（惶恐.jpg）。
借助kafka解耦后，并发要求带来可以向后借韶光，这就办理写入的瓶颈和系统负载。
通过调节kafka消费的速率，让内部管理的也可以应对ToC的问卷答案上报流量的写入操作。办理系统负载，原来三个串行任务的耗时重打算任务放在并发处理中，改到只留数据补齐和校验任务，另位两个放到消费数据再实行，达到向后借韶光目的。四、达到效果总算开拓完成了， 老板说：给你们找到了一个业务来用，他们后天要投X千万用户，要走PUSH渠道，你们接一下。
啊！
啊！
啊！
这？不是说早期没啥量吗？咋一上来就x千万用户呢？还是走PUSH渠道。
末了线上效果如下：
注：支配了4台8G16核的容器主机。
五、总结
这次项目用到redis、kafka、mysql完成由云平台供应，便是买买买就行，随着各种数据库和中间件上云交付，前端写后端已经完备可行。而且像小程序云这种成熟的FASS云举动步伐遍及，把后端代码也可以写到前端里去写也越来越多，前端人，已经不再是切图仔了。
关注我，带你看点不一样的
