ITPub博客

首页 > 架构设计 > 数据架构 > 苏宁视频云高级技术经理:漫谈前端系统架构的演变历程(下)

苏宁视频云高级技术经理:漫谈前端系统架构的演变历程(下)

原创 数据架构 作者:苏宁视频云 时间:2018-10-25 16:41:53 0 删除 编辑

作者:李晓健。现担任苏宁视频云高级技术经理。软件技术专业,从事java开发,拥有8年开发经验,超过6年的专职前端开发经验,3年以上的团队管理经验;目前负责苏宁视频前端研发和架构工作,参与前端SDK组件的开发,推动苏宁视频云平台的架构改进和用户体验,为用户提供优质的服务。人生信条:始终相信只要有付出,就一定会有回报。

其实我们在新开一个项目的时候,在做框架的选型时也是可以根据页面结构去做一些参考。去选择一些适合我们页面结构的技术去做开发,也会大大降低我们开发的复杂度,比如我们的页面需要做成一个单页的形式,我们就可以去选一些MVC或MVVM的架构来做。

今天我们来说一下苏宁视频云前端的架构的演变历程。

第一阶段的项目架构

苏宁视频云最开始的项目架构,最开始的时候,我们的页面是用PHP、CSS、原生的javascript来做的。页面用PHP是因为我们的web服务是PHP的,里面有一些PHP的代码处理业务逻辑,这里的原生的JAVASCRIPT是没有用到任何的框架和类库的。我们有很多的自定义的组件,这些组件也都是我们自己去编写的。

上线的时候就是通过jenkins将代码进行压缩,然后发布到线上服务器。我们当时的开发流程是前端工程师开发好HTML文件,CSS样式,页面交互效果;再将写好的代码交给PHP工程师,他们拿到了我们的HTML文件,然后再手动转成PHP文件,再加入一些业务的逻辑代码。

最开始的时候我们的项目就是这样,这样看起来好像是处理一个比较初级有阶段,确实,这样看起来没有什么什么架构可言,因为里没有用到任何的类库和架构,整个项目都是用原生的代码去累起来的。

第一阶段的项目架构中存在的问题

前端开发人员开发完成后,需要PHP开发人员将html转成php

在这个过程中我们就发现问题比较多,比如说,我们前端人员将页面开发完成后,再将代码交给PHP的开发人员,他们需要将我们的html代码再做一次转换,并加入一些其他的逻辑。

这里就相当于有两套展示代码,有时页面上有一些小的问题需要修改,就直接在PHP文件上修改了,并没有同步到HTML文件里,这就造成了文件的不同步。以后再将html转换成PHP文件时,就会漏掉那些之前直接在PHP文件修改过的问题,就会使老的问题重复出现。

页面数量较多

我们的页面个数也比较多,像我们前面看过的那个页面结构,每一个左边的导航都是一个新的页面,因为头部还有一级导航,每一个一级导航都有他自己对应的左边导航,所以页面就会比较多。

单个页面请求文件过多

那时候我们的代码也都是纯原生的,所有的组件也都是自己开发,每一个组件既有js文件又有css文件。很多的组件又有依赖关系,如果一个页面用到了几个组件,就需要引入很多的js文件和css文件,一个页面所有文件加越来,不算图片大概就有三四十个。

代码的复杂度过高,对开发人员的能力要求过高

由于我们没有使用第三方的东西,所以代码量就会比较多,代码的复杂度也比较高。而有的很多开发人员从一开始学习就是从类库和框架开始学起的,对原生的js了解的不多,所以开发起来也比较困难,如果有新的成员加入团队,就需要很长的时候才能熟悉我们的架构,并进入开发,这就对开发人员的能力有比较高的要求。

重复的工作比较多,开发的工作量巨大

因为我们的页面多,当时的代码也没有做很好的分类,就是一味的往上堆代码,有新的功能,就全部用新的代码去堆,有很多的功能就是比较类似的,就导致了重复工作比较多,开发的工作量也比较大。

第二阶段的项目架构

中间正好有一次机会,产品说要对我们的产品进行重构和调整,当然产品说的重构是指功能上的,但是由于时间问题,只能一部分一部的去做,还需要上一个部分上线之后才能去做下一个部分。

和产品沟通下来,以页面上的主导航为一个单位进行重构和调整。基于这一点我们就对我们之前的架构进行调整。因为这个分块进行调整的,所以我们不可能把之前的架构推翻全部重来,这样不仅时间是不允许,也没法做到产品要求的按功能模块进行上线。

所以我们就在原有的架构基础上进行调整。

首先我们原生所有的组件肯定还是保留的。然后对页面进行了重新划分,不再是每一个每一个左边导航一个页面,而是分成一个大的功能模块一个页面,左边的导航通过前端路由去做。

这样的话我们只需要改当前需要重构的这个功能模块就行了,其他的功能模块还是保持不变。其实这样下来就相当于把改过的功能模块,由之前的多个页面合成了一个页面。

然后我们在前端直接用HTML文件来展示页面,直接将html文件发布到服务器,不再将hrml文件转成php文件。

因为我们之前的PHP文件并不是只是用来展示页面的,他还有一些逻辑在里面,所以这里我们也不能直接把PHP给去掉。然后我们就让PHP直接转到接口层,PHP只提供接口给我们前端,这样的话他之前的逻辑还是可以使用和保留,也不需要太大的改动。

PHP这一层还可以帮我们做一层前端没法做或者处理不了的问题。因为我们的系统数据有多个后台系统提供的,PHP可以帮我们前端做数据整合,由他去调用其他的后台系统,然后统一提供数据给我们前端,这样我们前端就只需要对接PHP一层接口就行了,PHP就从前端的展示层退到了前端和后端的一个中间层。

基于我们页面上还有很多相同的部分或者是需要动态生成的部,然后我们又引入了前端模板,我们选用的是arttemplate。上线流程和原来的保持不变。当我们把所有的功能都重构完成以后,这样就形成了我们的第二阶段的架构。

第二阶段中解决掉的问题

不需要再将HTML文件手动转成PHP文件

首先最明显的就是不需要再将HTML文件转成PHP文件,而且我们前端的展示文件代码只有一份,不会再出现因为文件不同步造成的重复问题不断出现的问题。这个也使PHP开发人员从前端中解放出来,他们可发专程的去做数据处理,不用再关心HTML、CSS、JAVASCRIPT这些东西了。

通过前端路由将多个页面合并成一个页面

然后我通过前端的路由奖多个页面合成了一个页面,减少了页面的个数。这样也使我们的代码文件量减少了不少,页面的体验也得到一定程度的提升,之前每点一个链接,哪怕是一个子功能都需要重新刷新一下页面,而现在只有功能主功能时才会刷新页面,切换子功能时会动态切换页面内容,不需要重新加载整个页面。

使用模板大大减少了重复代码,降低了代码的逻辑

因为我们使用了前端模板,这时很多页面相同的地方我们就可以使用同一个模板文件,这就大大降低了重复代码的存在,也降低了代码的逻辑。

第二阶段的项目架构中存在的问题

单个页面请求文件过多

虽然这个阶段的架构比前一个阶段好了很多,但是还是有少不的问题。因为我们的组件还是使用的是自己开发的组件,那些文件文件依然没有减少,页面的请求文件数还是有很多。

单个js文件中的代码较多

 因为我们把之前多个页面合成了一个页面,但是总功能没有减少,而且这些功能代码全部都写到了一个文件中,所以我们的业务逻辑代码的js里的代码量会增加。

代码的复杂度过高,对开发人员的能力要求过高

一个文件里的代码量增加了,他的复杂度也会增加。代码的复杂度上去了,自然对开发人员的能力要求要更高。在这样的架构下,我们也开发了很长一段时间。

第三阶段的项目架构

正好又有一个不错机会可以让我们做重构,那就是我们的网站要改版。

大家都知道,改版可是一个大的改动,这个也没法一部分一部分的去上线,因为改完成之后,页面的风格可能就变了,也可以让网站以一个混搭的风格去上线。

所以需要改完整体上线。还有一点就是,对于前端开说,网站做整体改版,之前的很多代码可能都需要重新来写。

所所以团队经过商量,看看是不是可以直接放弃之前的架构,在不依赖之前架构的前提下做出来一个新的架构。这虽然会可能会增加工作量,但对于后期的开发会有很多的便利,而且网站全面改版后,测试也会全面覆盖。所以我们就放心的去做了。

首先需要确定的是我们的页面结构,决定依然延续二期的页面结构,以主功能为一个页面,左边的导航使用前端路由来做。然后去和产品确定了一下浏览器的兼容性,产品说,我们的客户都是签约客户,用户群体可控,兼容主流浏览器就行,但是IE需要兼容到IE9。

浏览器的兼容性也确定了,我们决定这次引用框架来做,不再去重复造轮子。接下来就是做技术选型了。

当前比较流行的框架是REACT、VUE、ANGULR。我们也决定在这三个中去选一个,最后经过对比,以及我们项目的特点和团队成员对这几个框架的了解程度,我们选择了REACT。既然我们依然需要使用前端路由,我们就选择了REACT系的 react-router。

我们还决定选择一个UI的框架,这些就可以有很多现成的组件可以用了,也会大大降低我们的开发难度和开发速度。然后我们选择了antDesign,因为他有丰富的组件和可定制性,使用非常灵活。因为react里有JSX语法,这种语法是无法直接在浏览器里运行的,需要将JSX语法转成js语法。

使用webpack和他的一些插件配置一套本地的工程化流程,可以对代码起先编译,合并,打包、代码的风格的校验等等。

既然我们有了一套工地的工程化的东西,而react又是基于模块来开发,而ES6+也是原生支持模块的,而且他还有很多新特性可以使用,源码也是直接使用ES6+来进行开发的,虽然目前浏览器对ES6+支持的还不是很完善,通过webpack的插件将ES6+转成ES5的代码。

我们本地打包之后的代码再交由jenkins去上线,因为jenkins是我们公司的上线流程,我们是无法改变的,所以这一步依然保留,不过这一次交由jenkins的代码已经不再是我们源码,而是我们经过合并处理的代码。所以文件数据会很少。

第三阶段的好处

可以直接使用antDesign的组件

因为antDesign它有非常丰富的组件,我们可以直接拿来用,而且他的文档和也非常完善。

通过modifyVars定制主题

我们的代码都是基于模块公去开发的,所以代码的耦合度也比较低,一个组件组件就是一个文件,代码的逻辑也比较简单。代码的复用性也比较好。因为组件是可以做到插拔试的,需要这个组件,直接放进去就好,不需要时直接拿掉就好,不会影响到其他功能。

antDesign的所有组件都是有他自己的主题样式的,但是他提供了定制主题,我们可以通过他他提供给我们的modifyVars的参数,将组件的样式替换成我们想要的样式。

通过webpack的多入口配置,大大减少一个页面的引入的代码量

wepack是以js作为入口文件的,我们通过配置他的多入口,就可以同时打包出多个页面的文件。

一个页面只需要引入一个公用的css和一个自己的样式文件,一个公用js和自己页面的逻辑js。

最终我们生成出来的文件也比较少,我们在打包时把多个页面都使用到的js和css 打包共用的js文件和css文件,然后再将每个页面独自使用的文件打包出来,这样我们一个页面需要引入的文件也比较少,也就只有公用文件和自己页面的文件。所以一个页面需要引入的文件数也就只有4个左右。因为我们都是以组件的方式来引入文件的,所以说基本上这个页面引入的文件都是我们使用过的,然后才打包到一起,所以文件也不会太大。

组件可以在多处共用

我们的组件也是多处共用的。

第三阶段我们解决掉的问题

通过babel的babel-plugin-import插件对antDesign组件进行按需加载

我们可以通过webpack的插件来按需加载需要我组件,也就是说,当前页面只需要加载当前页面的代码,而不说为了用一个组件把整个框架文件全加载进来,这样就可以减少文件的体积,可以使用页面更快的加载出来。

 通过webpack将公用的代码抽离成一个公用的文件

通过webpack把可以把一些公用的文件抽离出来,然后第每一个页面再去引用这个公用的文件,大家都知道,浏览器自己是有缓存的,当一个文件加载了一次后,在他的有效期内,再有请求,他就直接从缓存中取,不会再去文件服务器上去取。所以说这个对我们公用文件是比较好的。

页面模块都是按组件进行开发,每个文件里只有当前组件的逻辑

我们自己的功能代码也是按组件去开发的,第个文件里只有当前组件的逻辑,所以逻辑也比较简单。我们把公用的组件放到一起,一个页面的相关组件放在一起,这样代码也比较清晰简单。代码的复杂度也会降低很多。

我们开发流程里加入了代码的风格验证,保证一个团队的代码风格是一致的。

我们的工作流程也加入了代码风格验证插件,这样可以保证我们一个团队不同的成员写出来的代码风格是一致的。

这就是目前我们现在这个阶段的架构。

未来的发展及展望

js渗透到各个领域

前面我们已经说到js已经可以做到WEB端,服务端以及客户端,将来我话我觉得他会渗透到更多的领域。

由于硬件设备的加强及网速的提升,H5也会有更好的发展

由于我硬件设备和网速的提升,纯属的H5应用应该会有更好的发展,因为现在前端的东西基本都需要通过网络来传输,如果功能丰富的话,文件的体积就会比较大,网络不好就会加载失败呀,或者文件加载比较慢,给人的体验很不好。

现在比较热的物联网也会WEB化

前端可能通过网络网络协议去和硬件编程想结合,促进物联网的发展,比如说我们觉的共享单车,他可以通过web端发出一个指令,就将车子解锁,就是比较典型的物联网应用。

由于浏览器性能的提升和更多接口的开放,web VR也会有很好的发展

由于浏览器的性能的提升和更多接口的开放,像WEB VR也会有比较好有发展。web人工智能等都会有很好的体现。

苏宁旗下子品牌苏宁视频云已累计服务客户超过2000个;苏宁视频云凭借PPTV 十年媒体技术和服务经验,融合流媒体技术、P2P、CDN 分发、海量存储、安全策略等构建的专注视频领域的一站式SaaS 服务平台。苏宁视频云集视频云直播、云点播、云上传、云转码、云存储、云统计等功能于一体,多平台全方位支持客户各种视频场景的业务需求。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31559352/viewspace-2217544/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-24

  • 博文量
    23
  • 访问量
    21307