最近尝试了一波在目前的技术体系下接入React SSR优化，当然，在公司内部的黑话是”数据直出”。

构建倒不用操心太多…因为已经有团队现成的脚手架…才怪嘞。现成的脚手架用到我这个项目一堆坑。

进程管理、监控、负载均衡

比如目前在这个事业群内使用TSW去替代PM2作为Node服务管理，但是TSW对业务代码的侵入性极其之高…使用TSW的时候，如果出了bug，你只能想办法用node --inspect的方式，用chrome devtools去做断点调试，甚至是单步调试。
里面一个isWin32的判断Windows变量，竟然是把Mac OS也作为条件之一或进去的。导致本地调试的时候，依然走的是DNS解析，而不是内部的路由解析服务。

（因为TSW已经开源，所以这不是高压线）

HTTP请求相关

除了进程管理工具，脚手架也必须做相应修改。当然，对于API的拉取必须能够做到同构拉取，这点也有相关库去实现，只是api中间件必须得换一套。调用方式再次换一套…

这里要注意的是一定要区分node环境和浏览器对API拉取做不同判断，如果是Node环境，需要先拉取API，通过Reducer打入Redux的Store中，甚至对于诸如榜单的项目，你可以选择将整个数据都事先打入Store，可以让后面应用运作做到内存级的缓存。
如果是浏览器环境，需要判断是否已经有相关数据，如果有，则不再需要拉取后台API。

React组件相关

注意在调用React SSR，也就是ReactDomServer.renderToString(component)时，组件只有constructor及render会调用，所以如果在constructor中用到了DOM相关API，可以挪到componentDidMount。

其他组件该支持同构的支持同构，不支持同构的提PR把它支持同构。

其余在node环境下可能出现的问题，在本地调试的时候一般都能看出来，所以调试倒也不复杂。

测试部署

构建我跳过不说，webpack4对于node构建已经相当友好简单。但是构建出来的js，显然是要放在node环境中运行的。所以你首先要把js放到服务器中。

部署好之后用tsw运行，如果需要能做到动态测试呢，之后需要修改nginx配置，比如

location xxxx.html {
    if ( $args ~ _proxy=1 ) {
        proxy_pass http://127.0.0.1:8087;
    }
}

这样就能将带特殊参数_proxy=1的转发到node服务中。

跑一下浏览器，发现返回的html是完整带数据的，就OK。

压力测试

最后发布到现网机器后，还不能说将dns改到这，必须做一下压力测试。这也是后台们最重视的东西。

必备软件ab，这个不仅可以帮我们模拟并发，还能直接生成结果。

使用方式大概如下：

ab -n 100 -c 10 -l -r 'xxxx.html'

-n 请求量 -c 并发量
-r 防止出错退出程序

之后慢慢调请求量和并发量，一般可以调整到-n 12000 -c 12000

在运行之前，建议先设置ulimit -n 65535，这样能避免出现socket: Too many open files (24)的错误。

一般来说最关注的是QPS，即每秒处理请求数，这个数字可以从生成报告中的Requests per second得到。

一般来说压测的QPS是现网高峰QPS十倍应该就挺稳妥的。

如果不够？加钱上机器啊。

我目前的测试平均值是四核普通单机QPS最好成绩 185，node服务有这样的成绩，一般（微笑，我大node当年靠一手治理高并发横空出道，这点QPS不能满足我的）。

因为实际部署的现网机器不会只有一台，并且并不是什么热门页面，所以理论上也是完全够用的了。

更新： 我压测完就被TSW拉黑IP了，真是精准打击。

• ← Previous Post
• Next Post →