2019 平淡的一年 | 掘金年度征文

911 阅读6分钟

嗨 又到了年终总结的时候了

其实一个月前就想写这篇文章了但是回顾这一年其实并没有做出什么成绩来,都是一些循规蹈矩的事情,有些因为又不能对外公开分享,所以最后 挑选了以下这几个内容 稍作分享

同时算是2019年这一年的见证。

实时渲染

最近两年服务端渲染都被大家研究的非常的多了大家都知道,ssr其实在服务端性能是比较差的,逻辑复杂一点的页面 或者dom多一点的页面qps基本上都停留在几十。ssr是属于cpu密集型因为在服务端也使用了虚拟dom,需要大量的遍历计算所以一下子cpu就飙升上去了。之前我们的解决方案是加入缓存,组件缓存,页面缓存,接口缓存,能缓存的基本都用上了缓存。但是也因为缓存带来了很多的问题。因为缓存数据的时效性是比较差的会导致页面更新迟缓。可能用户简介改了要等一两个小时才能生效,还有一些千人千页的页面 根本就做不了缓存。其实 各个大厂也给出了自家各种不同的解决方案。

总结下来 虽然细节不同,但是思路无非两种。

1、字符串模板渲染的性能要远远优于虚拟dom,所以该种思路就是将原本的虚拟dom渲染通过一系列的转换,在服务端转变成字符串渲染,就能够让性能有倍数的提升,做的比较好的 第一个 是2019Tweb上 由段隆贤分享的极致ssr

有兴趣的同学可以寻找一下他的ppt 内容非常的不错,在编译时进行一系列的优化 但是好像他们aga 并没有开源出来 第二个是 阿里巴巴的北斗,基于react实现,我实在2017年D2上看到他们分享的 现在应该已经改进了吧(github.com/alibaba/bei…) 他的思路是 通过react代码渲染出不带数据 只带占位符的模板 然后 通过再次字符串渲染 将数据渲染上去 两个其实都是通过某种手段将VNODE渲染改为字符串模板渲染

2.第二种思路是通过服务端渲染出一个带有部分数据的vue template 然后在前端进行挂载剩余数据 比如说爱奇艺

我截图了他页面中的一小段 他是服务端渲染出了一个模板,这个模板 本身就是html 标签 所以在首屏渲染的时候 就可以解析出东西来了,然后在执行js的时候 在通过vue的一系列操作把数据绑定上去 根据数据渲染出对应所需的节点。 (以上的方案都是我根据他们分享的ppt 或者自己研究他们 得出的结论,会存在与他们的方案有出入)

我们使用的是第一种方案中的第二种类似的方案 在服务端 vue ssr 只渲染出一个带有${item.name} 这种占位符的字符串模板 然后用es6 字符串模板 将实时的数据渲染上去。 当然其中还涉及到各种if判断 数据判断等细节 需要大家仔细斟酌的。

GRPC-WEB

grpc我就不多做介绍了,通过Proto文件定义客户端和服务器端数据类型和服务接口。 但是grpc的端到端应用程序体系 还缺了一块 web端到服务端的。 grpc-web(github.com/grpc/grpc-w…)就是 补上这最后一块缺口的关键

我调研了一下grpc-web 其实优势还是比较明显的。可以减少数据传输体积,传输延迟也低, 原本需要在服务端提供一个restful的api给前端使用,现在可以直接提供grpc服务给web端和app端,降低了开发成本,具有可靠的api一致性,前端请求无感知,传输安全等优势。

我这里简单说一下使用方法。

第一步,肯定要后端提供一个pb文件。

第二步,通过protoc 工具 将pb文件编译成js grpc-web版本

第三步,就是发起请求了

如图所示:

通过grpc 你只需要关请求参数与相应参数,并不需要关心请求的地址、用axios还是jquery.ajax发送请求等问题,他都帮你封装好了。减少了编写接口文档或者前后端对需求的过程,大大提升了开发效率.其实关于解决前后端接口约定问题,还可以关注一下天猪的分享.

同时 因为使用的是二进制流传输,根据我的数据收集,延时能减少40%左右,消耗的带宽流量减少25% 效果看似还不错。

但是 经过我项目的打样,发现grpc-web在是存在着一定的困难需要去解决.

1.protoc 编译后的js 文件会因为比较大,大概几十K到几百K左右 再加上protobuf的npm 包大小,大概250k左右。对于需要注重用户首屏响应时间的页面来说就不太合适了,因为依赖的文件太大了。有点得不偿失。但是非常适合页面渲染后的一些异步接口。

2.需要在前端js 与后端grpc接口中间架一层envoy proxy 服务

3.因为引入的pb编译后的文件过大,并且响应数据是二进制流的,所以在首次获取数据的时候,代码运行的时间增加了。

不过总体来说,grpc-web确实是一个未来的发展趋势。

2020年计划

最后是对2020年的一个简单的规划。

首先 是一个简单的架构构想。

想成立一个node网关,这样子就能把所有的页面渲染器做成微服务。一个页面一个微服务。

到时候 新上页面可以通过配置中心配置路由与对应的服务映射就可以了,增加了服务的稳定性与可扩展性。

当某个页面压力升高时,也只需要动态扩容对应渲染器服务即可。

同时在需要处理一些公共逻辑,比如权限验证等的时候,也只需要在网关层增加即可。

当然,这些的前提条件是网关层足够稳定,并且有可靠的降级方案。

未来几年,serverless 是发展的一大趋势,改成此架构也能够很好的与后面的serverless接轨。

然后,2020年 vue3 讲道理应该要发布了,可能会根据vue3的更新,看是不是要调整一下现有的前端工具与开发模式。

对于自己的话,2019年其实比较苦恼,因为做的一些项目,都发展的中规中矩。自己需要有一点突破。不管是自己的技术上,还是组内的项目上,都希望能够做的更有体系一点。 2020 年 希望能够突破自己的项目瓶颈与技术瓶颈,做出更好的东西吧。

最后。。。 我好想出去旅游啊。。。不管是哪,出去就行

掘金年度征文 | 2019 与我的技术之路 征文活动正在进行中......