哔哩哔哩（B站）的前端之路

由于接入了两层缓存，首页上线的时候，我们把服务从2个docker实例 扩容到了6个（docker扩容真方便），得益于缓存的优势，服务并没有什么压力

当然 首页不可能像说的那样，这么随便就上线了，需要有降级方案，那么降级方案得益于vue的强大了.

Vue 会在浏览器端检验（data-server-render=true），是否服务端渲染了，如果服务端没有渲染，那么客户端会再执行一次逻辑进行渲染。这样子我们只要再打包的时候，将原本客户端渲染的那个index.html 保留就可以拉，当然别忘了，再客户端执行的时候也要运行一下asyncData里面的方法，不然会缺少数据哦。So easy~

接下来 一级分区 二级分区也分别都接入了，中间也遇到了一些问题，不过最后都顺利的解决了，后面有机会我再写一篇文章来说一下其中遇到的问题。

再次重构

我们的项目在有序的进行着从原本静态页 客户端渲染，往服务端渲染迁移的同时，我们也在公司内部进行这推广，有几个兄弟部门也遇到了我们之前的seo 的问题，或者是希望首屏更快等，所以很愿意使用我们已经造好的轮子。可是我们的项目暂时并不具有推广性，如果兄弟部门要使用，只有把我们的库拷贝过去，然后把业务逻辑删减掉，再加上自己的逻辑，成本很高，而且我们这边一旦更新了什么，他们都需要手动去同步，就很麻烦。

我们花了一点时间，首先，core核心库抽离出来，并且和日志中心的连接方法、配置中心的连接方法等一些公用方法一起，做成一个npm包发布到公司内部的npm 源上面，然后将client 从库里面独立出来，变成前端库，加上一个简单的server.js，可以独立于server 进行开发，而不用在开发的时候过分依赖node server.并且得益于配置中心，我们可以将项目分的很散，但是最终又通过配置中心，集中到同一个服务上，又回到了前后端分离上面，但是不止于前后端分离，前端独立开发的同事，还带上了服务端渲染，一举两得。设计架构如图：

拆分

顺带，我们开发了两个脚手架，可以很方便的创建项目，并且加好webpack的配置和package.json的配置

这样子拆分之后，项目就变得很清真，前端开发前端vue项目，服务端有npm包可供大家使用，升级和维护都很方便，node服务也不需要一直去重启，通过配置即可更新逻辑，热更新。

做完之后，很多兄弟部门也都开始了接入。

压力测试

因为每个公司的情况都不一样，使用组件缓存，页面缓存等等方式，都可以达到优化的目的，使其可以达到能承载项目流量的标准，我这边说的情况是没有任何缓存的情况下的压测结果。

我们做过几次不同层面的压测，毕竟性能需要达到要求才行，记得当时出版打样上线的时候，VUE使用的版本是2.3.x 性能不是很好，因为VUE是基于虚拟DOM（VNODE）来实现的，是CPU密集型的项目，所以在压测的时候，CPU很快就达到了100%，TPS很低，所以我们对页面加了缓存，像首页这种P0级页面都加两层缓存，后来VUE更新到了2.4.x 性能变好了许多，但是CPU始终是一个瓶颈。如果项目复杂，组建嵌套很多的话，1C4G的服务器，CPU打满也就40到50的TPS就封顶了，再上去，用户等待时间就会呈指数式上升。

我看过很多文章，拿vuessr和字符串模板进行比较的文档，但是他们的比较demo都很简单，vue里面都没有组件嵌套，性能相比可能确实差不多，但是页面复杂度上升，组件嵌套越多，那么vuessr的性能就没法再跟字符串模板进行比较了。

举个例子，我们首页一二级分区每天打到node上面的量跟文章的量差不多，但是文章就用了首页三分之一的机器，机器的cpu和内存使用量差不多，因为文章项目用的是字符串模板。

总结

在整个的过程中，需要前端同学，后端同学的通力配合才行，后端api的同学需要将原本直接结合模板出数据的方法全部改成api接口，这是前后端分离的基础。至于基础建设，可以慢慢发展来完善，就像一开始我们构建的时候，构建出来的配置文件的版本号都是需要手动去配置到配置中心的，这很耗时，而且容易出错，慢慢的，配置中心开放出了api接口，我们接入就很方便了，顺利的实现了配置同步的自动化，只要上线的时候点一下发布就好了。

在用node做中间层的过程中，也有遇到内存泄漏，性能瓶颈等问题，后面有机会，再写篇文章介绍吧。在这一年中，B站发展的很快，前端也有意识的去在意前端性能，让页面更好，更快。

脚步从未停下，我们还在路上！

哔哩哔哩 (゜-゜)つロ 干杯~