陈子舜,腾讯Web前端研发专家。先后负责QQ空间、开放平台、SNS应用产品的Web前端研发工作和团队管理;业界笔名Puterjam,著名博客平台PJBlog作者; 长期专注于海量服务业务的Web前端架构设计、运营优化、创新解决方案研究,同时也是多终端移动互联网技术研究和实践的先驱者。


讲座PPT下载 及 现场视频在线

 

    HTML5早在2004年就开始被WHATWG提出。历经8年时间的发展,HTML5技术已经不再是纸上谈兵。目前W3C 的HTML Group中已有76个公司参与新的标准制定、贡献力量。未来前端开发的责任和前景非常重要,HTML5技术可以给我们的产品体验带来更多的机会,那么我们如何升级现有的胖子业务?
    8月21日晚,腾讯Web前端研发专家陈子舜,在腾讯大讲堂为大家带来了腾讯海量业务前端底层架构的详细解析,以及用户体验和我们该如何进行新技术的蜕变。
    在中国特殊情况下,要使用这些新技术并非一帆风顺、仍有很多困扰:
    1. IE族(6 7 8 9)整体支持不济,其中IE6用户占了绝大多数;
    2. HTML5技术发展非常迅速,我们该从何开始?
    3. 这些技术是否只能用在手机上?
    4. 如果用到我们项目中, 该如何开展?
    ......




    这些问题或许成为我们的障碍,但绝对不会影响到我们对HTML5技术的热情!
    对于一个真正的前端架构师,这些障碍只是浮云。
    首先,HTML5是解决众多旧Web时代前端问题的革新解决方案集合。
    其次,实战HTML5不能以‘仅在项目中用到’为目标,而是应该以更加前瞻的眼光去看这些技术背后、其诞生和繁衍到底经历了什么。
    最后,要看不同的HTML5技术能解决我们工作中的什么问题,更要看这些问题还有没有其他解决方案。
    带着疑问回到项目中去思考,游走于HTML5各种技术背后的原因。
    非同源资源的共享
    在分享开始,子舜带大家一起回顾,2004年web界诞生的一个非常伟大的请求解决方案 -- AJAX




    这个方案的出现,让我们体验到了前后端数据交换不刷新页面带来的快感,给产品带来了更好的体验。但是新技术的普及并不那么顺利,这里也让我们遇到了很多问题, 其中在AJAX的实现中最麻烦的事情就是跨域问题(跨域问题的主要产生场景是由于很多大型Web站点,采用动静分离的资源部署方式,往往前端HTML页面和需要交互的Web接入端动态资源使用不同的域名,便于运营)。
    由于当时环境比较差、用户的硬件设备也比较糟糕,所以我们最早的proxy跨域解决方案并不成熟。
    “请求数过多,页面渲染慢,proxy页面维护成本过高”
    在以前QQ空间复杂的网络环境下,每个iframe的创建和渲染的成本都在0.5s左右,这是一笔非常昂贵的开销。




    随后,我们意识到XMLHttpRequest的局限,升级成为现在常用的JSONP的方式。
    JSONP看起来是一个不错的方案,解决了Proxy带来的各种问题。在腾讯的前端应用中, JSONP请求组件也经历了多代演化([keyName]_callback隔离方式,htmlFile组件隔离方式,documentFragment隔离方式,iframe+js:隔离方式),但这些方式是否完美呢?
    本着不完美主义的技术追求者,我们也对JSONP提出了很多苛刻的挑战。JSONP越来越不能满足我们对海量业务的要求,我们希望更多去控制、去了解请求的过程。而JSONP无法满足,每次请求都在页面上花费很多script标签(尤其在多请求并发的情况下),服务端不可用、网络异常、数据损坏导致JSON格式破坏的几种情况,无法非常方便得区分监控,给用户提供高可用的服务只能靠开发人员的经验来做勉强的保证。



 

    一个web业务,在异步请求过程中无法更好的关注和控制请求本身的状态,其实在很多方面,体验和解决方案都会变得非常不可控;柔性可用原则也无法达到最大化贯彻,技术的瓶颈和长时间的习惯,导致大家可能越来越少去关注这些问题。虽然对于这些问题都有不同的解决方案,但我们觉得这些解决方案并非完美。
    HTML5为了解决现有技术方案背后的一系列原因和问题,提出了XmlHttpRequset 2.0 。新的标准给我们带来了更多的优化机会。



    1. 数据移植性:
    a. JSON在应用中使用已经非常广泛,但是我们还是因为旧有JSONP方式的关系,需要把用以触发JSONP调用的_callback( )外套剔除,剩下的纯JSON结构,可以更灵活的用在更多场景,不局限于浏览器JS引擎。
    2. 数据可控性:
    a. XHR一直都可以在请求的时候定制化很多个性的HTTP request头信息,不需要增加自己希望的额外信息到query string。例如:现有的静态资源服务器端按需合并,因为没有使用XHR(目前是JSONP),只能把希望在Web服务器上按需合并的文件的文件列表在URL query string上用某种我们自创的协议列出来,看上去比较迷惑。
    b. XHR2.0标准,给到数据控制行为可以在数据发起前,加载中、加载后进行多种时间点的判断,甚至可以给到用户准确的加载时间,更好的控制和监控数据状态帮助我们更精确的实现系统柔性可用。甚至可以控制数据是否需要中断请求,以及告诉后端什么时候发起200或304响应。
    3. 多样化的数据提交方式:
    a. XHR未来是一个趋势,可以统一web业务上所有的请求方式,使web业务对网络的方案一致化;
    b. POST有专门的对象统一处理;
    c. 文件和二进制流也可以直接发送;
    技术预言随后伴随着实践,我们希望 “业务后面可以回归到使用XHR进行请求的方式”。
    所以我们在朋友网上做了一些技术尝试,这次尝试主要还是先从跨域的方案开始实践。早在3月份,腾讯海量httpserver QZHTTP已经支持了XHR 2.0的CORS方案。同时从发布后的数据分析来看,节约掉的iframe开销可以获得 0.5~0.6 秒的提升。
其实部署并非顺利,跨域方案在IE8/IE9下其实还是存在明显的技术缺陷。微软认为跨域的请求是不应该带cookie信息的,微软的IE10才能真正支持到XHR 2.0的cookie授权信息。所以现阶段在PC上要使用跨域的CORS还是不能做到非常彻底的部署。团队成员开始回归最初的思考:与其更加较劲这些细节,为何不开始部署不跨域的服务?




    进行同域的部署,有非常多可选方案,并且很多方案都非常成熟。通过各种代理,动态加速的方案,可以减少前端在请求方面的做的过多的兼容性问题,从而从底层解放开发在不同请求方式的选型。把时间更加专注在业务功能上。
    另一方面,前端开发在实际工作中除了一直在追求方案的极致优化,架构的模块化等语言成面的极致,同时也是海量业务的护航者。
    所以前端的监控和性能的测量也是我们一直关注的方向,子舜提出:“测量是优化的第一步”。为了提供更好的服务,我们需要对各个环节的网络情况、硬件情况进行了解。所以HTML5也是为了解决这个问题,提供了更加详细的监控手段。




    HTML5的Timing,提供了更多细致的监控能力。从本地缓存读取,到DNS解释时间;从TCP连接建立花费,到浏览器首页渲染的时间。都可以非常精准地提供更多业务的监控方式。
    同时,未来的时间点监控也将会更高精度超越毫秒的时间戳。目前,这一系列的数据已经在公司很多业务都开始进行测量,给后端运营同学提供更多有意义的数值参考,更加及时,精准得发现我们的业务在不同地区,不同运营商中更加精细的业务数据。

 



活动下半场内容

 

 

活动答疑总结