京东BP说：浅谈大数据平台的WEB前端之路

时间  2014-07-15

 

如果泛谈WEB前端的概念，那只是偌大技术体系中的一个角色，而且听起来并没有多少娇艳和华贵的措辞可以形容她，也远比不上集群、云计算、BI等说辞来的潇洒和犀利。

如果观摩WEB前端的历程，随着互联网硬性条件的升华和客户群对界面体验需求的提升，WEB技术的视野扩宽了，WEB前端也与时俱进，从相对平庸一跃成为万众瞩目的焦点。这期间跨越了许多时代：从最初的静态页面到CGI；之后PHP露出了锋芒，和MYSQL的搭配无疑巩固了市场中的地位；紧接着J2EE时代来临了，也诞生了百花齐放的WEB层框架，如Servlet、Structs、SpringMVC；最终迎来了最火爆、最有划时代意义的AJAX，成为WEB2.0的基石性技术。可以说，越来越多的ITers会选择WEB前端，因为这是一片充满未知却能够无限开垦的领域，更是实现数据可视化的关键。

我们需要重视什么？

身处于这片广阔的领域里，我们可以讲过程、讲对象、讲模块化，也可以钻研DOCTYPE、CSS Hack、Media Query；更可以探索GIS、Mobile App、Server-side Scripting、DWR。但是一面墙不仅需要水泥和砖头来搭建，或是随意地利用墙纸和照片来布置，我们更需要它坚不可摧并且让人赏心悦目。于是，在炫彩夺目效果的背后，优秀的框架和设计才是大数据可视化发展之根本。所以，我们必须讨论POP、OOP或者CMD、AMD；必须探讨MV、MVC、MVP还是MVVM。

当前有许多非常优秀的框架供我们选择，如Jquery、Ext、Backbone、Bootstrap、Angular、Sea。作为京东的BDPer（BDP：BigData Platform 大数据平台），该如何权衡技术选型的轻重、应用场景的繁简以及引擎性能的优劣，如何结合京东的数据资源和商业逻辑，抽取出适合自身平台发展的架构，是需要我们迫切思索和不断探索的事情。不仅如此，还要遵循渐进增强和适度降级的策略以及商业规则的约束。

我们从实践中得到了什么？

我们曾经构建过一个实时报表平台，场景并不复杂，其目的就是利用报表多元化地展示原始或者加工后的数据。于是，我们按部就班的定义了类库，负责基本的API操作；又定义了组件库，包括表、图、树等，主要负责各类报表的渲染；最后我们搭建了自己惯用的MVC框架，只是数据与视图并没有完全解耦。乍一看，技术选型是符合的，性能也基本合格。但是，实践的时候遇到了问题：技术选型虽然很轻巧，但是不适合将来的扩展，应用场景的覆盖率必然不高；更糟糕的是，在高频率的实时场景下，性能的漏洞导致了框架很脆弱，偶尔发生数据跳帧的现象。仔细分析了一下，若不考虑在Server-side交互层面上耗时的流失，主要原因出现在数据和视图的耦合性上。高频率的渲染并不可怕，可怕的是渲染的不仅仅是数据，还拖泥带水的绘制了页面元素、样式元素，这样即使经过了逻辑优化，也还是增加了页面性能的负荷。如何缓解这样的矛盾？庆幸的是我们在不断探索，发现了基于MVW(MVVM、MVC、MVP)的Angular，如果用它的MVVM去解释实时，还是有很多巧妙之处的。数据和视图很大程度的解耦、Two-Way Data Binding让模型和视图互相影响都是其新颖的地方，而且该模式遵循了非侵入式编程原则，即使出现Server-side的延时异常或者某脚本的逻辑错误，也不会太影响WEB页面的初始化，保证了一定程度的用户体验。我们可以利用模板建立视图，只需再设置相应的模型监听，一旦数据有了变化，页面自然会响应并更新。

我们该如何思索、如何挑战未知？

至此，核心矛盾消失了吗？答案是否定的。其实刚刚也提到过，性能的瓶颈还有很大部分是出现在Server-side的交互上，我们通常采取B端建立请求，S端响应并返回实时数据的轮询模式。解析一下整个过程，我们从B端发送请求至S端，经过3次握手才能由S端构建数据回B端，而且每次都带着header信息。当这种机制处在周期3秒的实时场景下，虽然不说致命，但也确实拖沓了一番。问题来了，倘若周期降低至1秒甚至更低呢？显然S端也有很多优化的方案，如增加资源数量，或是缓存数据等，都可以减少数据在处理阶段的耗时，然而在WEB前端的主题下，我们必须力保该层面的风险降到最低。于是，京东的BDPers嗅觉很敏锐，发现可以通过header信息的压缩减少整个响应过程的消耗，实践也证实起到了很好的效果。那么还会有突破吗？不得不感谢BDPers坚持不懈的探索精神，HTML5的兴起让WebSocket应运而生，半遮着面纱出现在我们眼前。从理论上讲，披着长连接的外衣必然会减少因握手造成的耗时，并且由S端主动传送数据，相当于建立了快速的专用通道，何况还很大程度缩小了header。如此正常推断，交互环节的性能理所当然能够得以改善。然而，这一切又似曾相识，我们自然联想到了反向AJAX，Comet不就是长连接的典型吗？实践证明，在服务器资源有限，并且高并发用户长期占线的场景下，如此大量的连接势必占据巨大带宽和资源，会给服务器带来不可估量的负荷，导致不良效应。那既然这样，何必再深入研究前者呢？其实，比较两者还是很有差别的，比如后者采用长轮询单向通信方式，会在Bayeux协议的解析转换过程中消耗体力；而前者只需要建立一次HTTP握手，采用B/S全双工通信方式，header信息也是极其精简，诸如此类。那么WebSocket这样的设计是否能真正满足我们的实时数据应用呢？服务器资源的疑问？并发用户的疑问？浏览器兼容性的疑问？目前还带着很多未知，需要我们不断实践并发掘其中的平衡点。或许，我们正在寻求的答案在偌大的圈子里已经揭晓并且付诸实践，但我们自身探索的过程是愉悦的，充满挑战的。

我们BDPers看得到，京东的数据资源无论是从横向还是纵向讲，都很深、很细，描述着京东独具一格并且不断拓展的业务。我们坚信，有如此强大的数据支撑，凭着一颗对可视化技术渴望和探索的心，我们将会不断超越无限可能！