D2 前端技术论坛流水帐

本博客同步自个人GitHub博客

一直想去阿里看看，此次成行，至少 BAT 三总部签到成就是 get 了。经历了多日的降温降水，初到杭州，就遇上了升温，即便穿短袖在阳光下走走也会微微流汗。一大早出门前往阿里西溪园区，担忧坐公交来不及，就打车过去，在车上就感叹——阿里的位置真是偏啊，离城区太远了，杭州的地铁只有一条线，像我这种在南京工做，天天地铁穿城而过去上班的方案放在杭州确定是行不通了。不过由于远离城区，地广人稀，阿里园区也是足够大，不过好在园区内有不少公用自行车能够随便骑，反而十分方便。

园区的环境也是不错的，有不少植物，一些植物上还挂上了介绍的牌子，就像植物园同样。建筑的装饰风格也比较活泼，墙上有壁画，融合了阿里各产品的元素在里面，相似淘公仔和天猫吉祥物的大玩偶也随处可见，看了能让人会心一笑，这点比起我厂过于商务的生硬风格更让我喜欢一点，也有互联网风格。

好了，免费广告不能打太多，下面进入正题。此次是我第一次参加 D2 这个活动，以前有据说过，不过由于还在上学，没有足够的盘缠，也就没能参加。因此这第一次参加在国内能够算得上是影响力首屈一指的前端论坛，也是挺兴奋的。到了论坛现场，发现到的还算比较早，主会场人还不多，分会场几乎尚未人到。值得一提的是，在签到的人群中，我看到了张鑫旭大神，他的博客我看过很多，大活人仍是第一次见，瘦瘦高高的，皮肤有点黑。

同部门的小伙伴们当天上午才从南京出发，而我是头天晚上就到的急先锋，所以我到的时候大部队还在路上，因此我干脆就单独行动了。第一场的分享在两个会场分别是来自百度 FEX 的前端工程师的《指尖上的数据》和支付宝苏千的《支付宝先后端分离的思考与实践》。苏宁易购在不久以前刚刚有一次 node.js 的实践，算是对先后端分离的一次探索，支付宝在这方面算是走在前面的公司，因此我绝不犹豫的选择了这场分享。圆心的开场讲话一结束，我就冲出门直奔分会场。同时我也发现，不少朋友们的选择也和我同样啊，幸好个人动做快，竟然还抢到了一个前排的座位，要是慢上五秒，就连地板都没得坐了。（一样值得一提的是，玉伯后来就坐在个人前面一排啊，终于得以一睹大神风采~）。

Node.js部分

《支付宝先后端分离的思考与实践》苏千（袁锋）

苏千的广东口音听起来挺喜感，人也是圆圆的挺可爱，不过我可管不上这些，忙着边听边记笔记呢。苏千说到，先后端分离在实现以前，主要由如下两个痛点：

• 设计离技术比较远，产品交互体验不佳

• 先后端职责不清晰，研发体验很差

这两点中，第一点相对的偏向用户一些，从用户层面对交互设计是否合理会体验更加直观。而第二点，就是对咱们开发者说的。的确，传统的前端制做静态页面，再由后端套模板，而后先后端联调，改bug，测试，上线，再回测。。。这样的流程延续了好久，也被诟病了好久，在这种流程下，先后端的工做有了很大的耦合，不利于提升研发的效率，改善研发体验。

Node.js 在先后端分离中扮演的角色应该是一个中间层，在这方面，除了支付宝外，淘宝的中途岛项目有不一样的侧重点。中途岛项目中，Node.js 层在职责上依然属于前端，并无抢后端的饭碗，而是将通常先后端职责划分模糊的地方进行了分割，后端再也不插手前端 UI 层的工做，不在模板上插入各类复杂的逻辑，只负责提供数据，提供服务化的数据接口。Node.js 层要作的就是路由共享，对请求进行分发，固然，路由的工做还能够再加一层 nginx，这点在腾讯的实践中有所体现，这个后文会说。Node.js 层的另外一职责即是模板的共享，根据不一样的业务场景，选择模板渲染是在服务端完成仍是浏览器端完成。例如淘宝的首页渲染是服务端完成，而一些详情页或其余模块就是交由浏览器端渲染了。

说完淘宝，仍是说回支付宝。苏千的整个分享过程当中，有 70% 的时间都是在说他们的 Chair 应用。它是支付宝先后端分离中的关键环节，它的主要特色是对逻辑的复用，对阿里内部系统的融合，以及统一的安全策略。不过这个系统跟支付宝的不少核心业务相关，所以没有开源，更多的细节也就无从知晓。从苏千所说的话来看，Chair 能够说就是一个完整的 web app。它有路由，有各类中间件，有 C 和 V 之间的协做，以及对支付宝各个服务接口调用的统一管理。能够说，有了 Chair 的服务，前端同窗的开发能够想象，应该会很爽。

不过我我的对 web 服务的研究还很浅，苏千的分享在各方面也是走马观花，更深的理解也没有了，总结成一点，就是后端必定要服务化，不少的数据接口要进行改造或是管理。联想到苏宁几个月前的门店频道项目，其实前台和 Node.js 部分的实现已经没有什么大问题的，就是由于后端的服务不能统一，致使最后没有彻底成功，有些遗憾。

在最后的 QA 中，苏千针对一些问题的回答也有些有价值的地方：

• 支付宝前端团队的分工，力求成为多面手，各类工做都要作，甚至可以接手一部分的后端工做。

• 对于一些包含了不少原子接口的大接口，并发请求，这方面由前端来完成

• 后端提供的接口，主要为 RPC，少许 RESTful（支付宝）

• UI 测试在实际浏览器中跑

• controller 控制全部的数据逻辑，并提供给 view 层，视图层只负责渲染。

• 支付宝的先后端分离之路也很曲折，最初是由玉伯在两年多之前发起，也经历了一些失败。听到这我却是有些安慰，技术之强如阿里，在这方面也是经历了不少困难，咱们经历的一些失败也算不上什么，要相信将来是美好的。

《nodejs一小步 前端开发一大步》林楠

下午的第一场分享也是跟 Node.js 有关，是由来自腾讯云的 BrianLin（林楠）带来的 Node.js 在腾讯云的实践。从他的整个分享内容来看，腾讯云对于 Node 的应用更偏后一点，不只仅是担任中间层的工做，更多的会接管一些后台的逻辑，好比原来由 php 完成的工做。经过一系列对 php 和 Node.js 性能的比较，最终得出的结论是在腾讯云的业务场景下，Node.js 的综合性能会更高一些。

Node.js 和 php 的性能比较，各类论据我就不罗列了，林楠说的没有什么特别让人意外的地方，上网搜搜也能找获得。比较有价值的应该是在应用过程当中，使用 Node 会遇到的一些问题以及解决办法。首先是 Node 和 nginx 的协做，在实际的应用中，Node 通常都会和 nginx 搭配，由 nginx 发挥特长，进行一些请求的分发，尤为是静态资源的请求分发。腾讯有本身改造过而成的 tnginx，它的主要工做就是动静态资源的分离，静态页面由 tnginx 直接处理，动态页面由 Node 处理。nginx 的职责主要有三点：

• 域名收归，由 nginx 进行路由分发。

• 灰度发布，应该是相似于 A/B test，由 nginx 进行代理。

• 配置化支持 https 的能力。经过 nginx 配置项实现 https 的支持相对用 Node 来实现要方便得多，客户端和 nginx 的链接使用 https 协议，nginx 和后端各服务之间的通讯依然使用 http 协议。

另外林楠还提到了数据存储方面的一些问题，我没太听懂，就很少说了。他还提到一个问题，就是发布时的性能抖动问题，在每次发布事后，性能总会有一段降低的过程，这主要是因为在发布过程当中，服务须要重启，在每次重启时，服务请求队列中会有一部分请求没有处理，在新的服务启动时，这部分未处理的请求会对整个服务的性能形成影响，不过具体是怎么形成影响的呢，我不太清楚。就这个问题，我和身边的来自孢子社区的小伙伴交流了一下，孢子社区使用的是 fib.js，它使用了协程，它是一种多现场单线程，每一个协程自行创建堆栈，共用一个线程。封装后的 v8 不会感知到协程的存在。彻底非阻塞，由纤程驱动，没有 Node 特有的回调模式。JavaScript 线程内会运行多个纤程，在发布方面，每次发布会启动新的纤程，不会影响到原来链接状态中的各类请求，新的请求所有切到新的纤程上，旧的纤程上的链接只要不断开，仍是请求旧的服务，一旦全部链接断开，则自动回收旧纤程，达到无缝切换。更多关于 fib.js 的介绍，能够看它的做者孢子响马的分享pdf。这种发布方式在技术上非常新颖，不过可能还只适合孢子这样类型的团队，对于苏宁的实践，暂时只能提供必定的参考价值吧。

前端工程化架构部分

《面向多端的蘑菇街前端技术架构》贝勒（李振强）

我跳过了中间周杰的《第三方开发前端实践》这部分。缘由是他的分享我感受实在是不知所云啊，也不知道是否是个人水平太差，彻底听不进去，倒以为他是在推广本身公司的各项产品。没有参考价值，那么略过不表。

原本，看贝勒分享的标题，感受他会讲一些多终端适配甚至是 hybrid 开发方面的东西，实际上不是，主要内容也就是蘑菇街一路之前的前端技术架构的演变。却是和后面京东的分享很类似，正好我此行的目的就是为了听先后端分离和前端架构方面的东西，正合我意，所以我也就把这个分享划分到前端工程化的主题之下了。

蘑菇街做为一个当初的创业公司，在初期技术方案也的确是十分原始的，整个前端部分一句话总结就是 jQuery + base.js。jQuery 是 JS 库，base.js 是对业务开发中经常使用方法的封装，这样的技术选型根本谈不上什么架构的思想。随着蘑菇街业务的不断扩大，复杂性的增长，过去简单的套用 jQuery 的方案已经不合适了，所以他们开始探索本身的前端工程化架构方式。

目前，蘑菇街采用的前端技术架构为：webdemo做为本地开发环境的名称（这个名字起的很奇怪啊），其中包含两个方面，一个叫 walkman，是前端自动化工具，另外一个叫 magpie，做为前端的底层，至关因而将以前的 base.js 进行了升级。

webdemo 这个东西，主要是用来解决一个代码的管理问题。过去蘑菇街的代码是托管在 svn 上，svn 有什么弊端已经不用多说了，庞大的代码量给代码管理带来了很大的困难。还记得在人人网实习的时候，代码库包括静态文件都是用 svn 管理，checkout 一次好像有 5G 的数据量，一旦本地维护出点问题，代码冲突什么的，svn 用的不熟练的人就会苦不堪言，我就是受害者之一。webdemo 这个东西实际上就是一套解决方案，针对代码管理的问题，对后端服务的调用，采用了 nginx + php 的方式，代码托管平台也迁移到了git上，而且提出一种子模块（submodule）的概念，将pc端、h五、pad 和 im 的代码分别管理，我想应该是用 git 切了不一样的分支。在开发环境上，使用 require.js 进行模块化开发，预编译 css 采用 less，对 less 的处理用了 php 的 lessc 模块在服务器端进行编译，同时使用 sourcemap 对源文件进行引用，便于开发调试。

前端底层名为 magpie，它的一大做用是统一了各终端的开发方式，提供了一些全局变量，具体是什么我忘了，就记得名字是 MoGu，我想应该是提供了一些全局的配置信息，好比多种端适配要用的一些东西，或者是一些公用的方法吧。开发模式上，采用了一种类 backbone 的方式，将页面单页应用化，以便于模块化开发，减小各模块的耦合度，提升开发效率，这种方式在中型公司中彷佛比较常见。base.js 这个库有什么变化我记不清了，不过因为它是针对蘑菇街的业务高度定制化的，因此参考价值应该不大。

值得一提的是蘑菇街的前端自动化系统 walkman，包括后面京东的 jdf，和咱们的 fas 都有高度的类似性，有很大的参考价值。在流程构建方面，walkman 采用了 grunt，在发布阶段，用 r.js 进行打包，开发阶段的模块化异步加载没有必要带到生产上去，所以，自动解析依赖，打包 js 也是不错的方式。孢子的小伙伴给我看了他本身实现的一套打包脚本，不过因为是基于孢子的开发框架，不能直接移植，并且实现上好像还有些不完善。对于 css 的打包，采用 lessc 来完成。我以为这部分功能其实彻底能够集成，不过这还牵扯到一个统一团队开发方式的问题，京东用的 scss 也是同样的。项目脚手架采用 yeoman 来生成，配置方式固然根据蘑菇街的业务形态进行了定制，这点在fas中也有体现，虽然还比较初步。

在数据模拟方面，蘑菇街用的是 lotus，在介绍 lotus 的时候，贝勒还提到了一个叫 mean.io 的东西，据我在 github 上的搜索结果，他指的多是 mean.js 这个东西，先后端开发先定好开发所需接口和数据格式，达成一致之后前端便脱离后端，彻底使用 lotus 进行数据模拟在本地开发，lotus 还能够根据数据接口直接生成文档，便于后期维护和二次开发使用。

对于我比较关心的 hybrid 的内容，贝勒只提到了一个 jsbride，说是一个 hybrid 的开发环境，不过看来蘑菇街的 hybrid 之路也才刚刚开始，尚未什么能够分享的东西，贝勒也没有再多说。

《京东前端工业化实践之路》刘威

这个算是 D2 的全部分享中我最关注的分享之一了，另外一个是淘宝的前端工程与自动化体系，无奈两个分享同时开始，分身乏术，考虑到京东的现状相对于淘宝应该跟苏宁更类似，我便选择了这场分享。

来自京东的是一位前端架构师，以前曾就任于百度和新浪。他就京东目前的前端工业化进行了一些分享。总结起来，我以为京东的前端现状实际上跟苏宁仍是很类似的。

京东的前端工具集名为 jdf，在 npm 上提供了模块的下载，github上的仓库能够点击这里，这个工具提供了多种命令行指令，可以完成一系列前端开发过程当中可能须要的各类构建工做。京东的开发对模块进行了划分，每一个模块能够独立维护，模块有符合规范的目录结构，引用方式相似于{%widget name=""}，模块的配置文件符合 common 规范。js 的模块化方面采用了一样兼容 commonjs 规范的 seajs 进行模块的加载管理。预编译 CSS 选择了 SCSS，每一个文件的命名方式以模块名开头，避免冲突。后端模板用了 velocity 语法，作到了先后端公用。jdf 提供了模块的新建，安装，发布和预览等一系列指令，便于单个模块的调试。内部有模块云平台对模块进行管理，使用 FTP 控制权限，有权限的人能够进行模块的发布，任何人均可如下载模块，模块的版本识别依赖 json 配置项中的 version。

模块方面大体是以上这些。在静态资源输出方面，经过发布至 cdn 而后在资源路径前加 cdn 前缀的方式进行非覆盖式发布，以版本号进行区分。js 资源方面的输出我有点记不清，他好像提到了一个 cmd 模块自动提取文件 id 和 dependencies 的机制。在字符编码方面，由工具进行统一化。性能优化方面，jdf 工具集成了 js, css 和 png 的压缩，js/css 和 css/sprite 的合并，以及 combo 请求的功能。其中对 sprite 的压缩怎么实现我还想象不出来，好在 jdf 代码开源，能够研究一下。

联调的实现主要是静态资源上传至联调服务器，html 上传至另外一个联调/预览服务器，没什么特别的。上线过程也比较常规，编译系统去静态资源 svn 上取代码进行编译（他所说的编译应该是至 SCSS 预处理，js 压缩合并这方面的意思），而后发布至cdn。

辅助功能简单罗列一下：

• 本地 serve

• 错误提示

• 自动刷新

• 自动监听

• 代码质量检查：jslint, csslint, htmllint

• 根据配置文件，统一编译，输出

一点想法

总结起来就是以上这些。回顾整个 D2 我所听到的分享内容，结合我对苏宁网购业务的一些了解，我以为目前最有价值去发展的就是 fas 这套系统，fas 若是有竞品的话，就是京东的 jdf，若是咱们有足够的时间和人力投入的话，超越京东不是不可能的事情。对于先后端分离的实践，我还须要多学习，多了解一些相关的知识，怎么去实现这个东西，苏宁有在这方面有实际经验的开发者，要向他们学习一下。

D2 上听到了也只是其余公司相关技术的冰山一角，只有有了雄厚的技术积累才能够从容的进行技术分享，对于咱们来讲，先作好第一步吧。