天猫双11前端分享系列(二)：天猫双11页面服务容灾方案大揭秘
天猫双11前端分享系列（三）：浅谈 React Native与双11
天猫双11前端分享系列（六）：大规模 Node.js 应用（续）
天猫前端基础技术体系MAP简介
1 年前
文章前面先打个广告：我们还在招聘哦，欢迎各种简历，butian.wth[at]http://taobao.com
前端基础技术体系是一个非常宽泛的概念，涉及到非常多的点，前端这个行业本身易入门难精通的一部分原因也是每一次的技术深入都需要技术广度上有提升，这些广度以前覆盖了HTTP、其他后端语言、操作系统、印刷设计等，现在由于移动设备的兴起，广度要求的点做了更多的扩充，移动设备多样化、国际化、Native技术等等。列举这些不是想说明前端有多复杂，而是技术体系本身就不是一个独立的存在，需要结合更多其他领域才能有更好的发展，其实其他技术的发展也是类似。下面就是流水账了。
历史
在我2011年刚加入口碑前端团队的时候，三七一直在强调，我们现在的前端团队是国内最棒的。得益于当时YUI成熟的体系，我们在业务中落地了在当时非常“潮”的技术。比如本地的模块构建和发布工具att、CDN的combo服务，YUI的模块版本化管理机制（KISSY模块规范的原型），基于Base/Attribute/Plugin/Widget的模块生命周期管理等等。而使用YUI3开发web应用这篇文章里对web模块开发的思考在现在依然不会过时。
YUI和jQuery的最大区别就是体系和库的区别，对于庞大的淘系业务，只有体系化的技术方案才能保证研发效率和工作流的稳定，保证线上质量和用户体验。YUI体系在传统库的基础上，涵盖了YQL（浏览器端类sql实现）、YETI（浏览器端自动测试）、YUI-Target-Environments等等。
当时前端基础体系强调的核心是兼容性和性能，我们需要大量的复杂庞大的库来保证一套代码能够多浏览器运行，而低效的浏览器执行能力和缓慢的网速也让前端展现部分称为用户访问速度的瓶颈。于是有了：
CDN解决图片在线优化、同域名连接数、Combo及多地域资源加载问题
前端发布工具雏形，自动sprite、base64、文件合并
css/js分开管理到css和js之间开始存在明确的依赖关系
ajax解决刷新页面重新请求所有资源缓慢的问题（虽然有缓存）
MAP 1.0
2012年，天猫启动了MAP项目(Tmall Front-end Architechture & Publish Mechanism)。
当时团队面临了一些大部分前端团队都困扰的难题，这部分阶段称为MAP 1.0。
团队有一定规模，但是开发规范、工具、流程不一致，团队之间缺少沟通。
原始的发布机制和开发工具，覆盖式发布。
多套模块库TML、MUI，KISSY版本繁杂，代码共用少。
前端工作流不明确不一致，效率低，前端在业务中非常被动。
MAP 2.0 - 扁平化、细粒度
基于上述MAP1.0时代的问题，MAP2.0做了针对性的调整：
CDN静态文件路径语义化和非覆盖版本化管理，解决了前后端发布的顺序问题
Base(KISSY 1.3 + MUI 2.0) + App(业务代码) 扁平化双层结构
前后端一致的静态文件引用方式feloader.use，覆盖java端应用
git+本地开发工具，统一的工作流，代码可管理且高效
MAP 3.0 - 扁平化、细粒度、跨平台
因为智能终端设备的普及，原来的前端目标环境从多浏览器变成了多终端，整个I/O交互的变化对前端体系提出了多端构建的要求。
多终端带来的1套数据多套view，对前后端分离的要求更加严格
native和web界限模糊，前端模块需要覆盖Native App
无线环境对页面性能和体验要求更高
跨终端的MAP 3.0计划启动，为了保证一致的模块体系和模块快速开发和落地，跨终端组件的技术方案基础还是KISSY 1.4（KISSY 1.3升级1.4），大批组件开始支持移动端，各类频道活动也开始全面覆盖移动端。
同时，基于Node渲染服务在经历2014双11的考验后，开始全面走向业务，前端的模块渲染不满足于当前简单的异步渲染，毕竟同步输出渲染结果始终是最快的方式，于是我们对前端模块的规范进行了扩充：前端模块应该是包含js+css+模板+schema
关于Node服务的介绍可以参考文章：天猫双11前端分享系列（四）：大规模 Node.js 应用
其中，模板可以在发布的时候编译成模板文件和一个模板脚本，分别支持在服务端渲染和浏览器端异步渲染。渲染所依赖的数据格式根据schema文件来约束。
还有一些其他的变更包括：
本地发开工具gulp化，业务有更强的定制能力，实现弱中心和灵活的开发环境
从if到schema，端到端数据接口规范形成，模块通过数据实现业务化
还有，ReactNativ在2015双11落地，实现了同个模块多端构建的能力。前端模块的规范变成：js+css+模板+native模板+schema。独立native模板的主要原因还是目前没有好的解决方案来实现普通web模板到native模板的编译，或者换个顺序也不行，所以还是独立维护一份Native的版本。
模块的规范基本成形，现在我们的模块开发目录大概是这样的：
- build- src--- index-pc.js--- index.js--- index-native.js--- index-pc.less--- index.less--- schema.json--- seed.json
关于ReactNative的详细可以参考：天猫双11前端分享系列（三）：浅谈 React Native与双11
同时Native组件在web中调用也是正在尝试的方向，将web中一些非常复杂容易有性能问题的模块直接替换成Native，可以实现页面切换时部分组件不刷新等功能，提升用户体验。
MAP 4.0（现在）
MAP 3.0对于2015年来说是相对比较完善的方案了，但是暴露了大量的问题。
比如文章2015天猫双11前端分享系列（一）：活动页面的性能优化里的描述，统一基于KISSY 1.4的模块在无线端已经成为性能瓶颈，引用文章里的一句话：脚本体积过大，目前基础脚本文件大小在100k上，占了我们规范标准的一半以上体积。
当时而言，最简单的实现方案就是无线的模块独立一套基础库，比如使用zepto或者kissy mini，而pc的模块继续沿用KISSY。但是，一方面KISSY本身相对社区解决方案已经不够新鲜，pc/无线不一致的技术体系对开发效率来说也是一个负担，更会造成大量的技术方案重复实现。
拥抱社区
React还是原生
团队的第一反应是React，一方面是社区的成熟，另一方面ReactNative实践下来确实能满足业务需求，如果基于React构建模块，然后编译结合ReactNative，解决模块在Native下运行的方案，看起来非常美好。也算是真正实现了一次开发，多端运行的能力。
但是问题依然也比较明显：
React本身无法解决所有问题，渲染之外依然需要大量其他工具lib支持，这些lib无法做到多端运行，或者说即使可以，也是一个非常私有的实现，后续更新也是问题。
React本身的脚本还是太大，对于简单的无线页面依然是一个负担
React本身有服务端解决方案，可以实现同步加载，但是同步浏览器、客户端的State本身复杂度上较高，无法工程化解决的话，长期来说也是一个坑。
审视React的过程中，最大的收获其实是Babel。通过gulp-babel + babel-polyfill的方案，我们可以在本地开发最新ES标准的代码，并在IE8及以上都能顺利运行（虽然有一些坑）。刚好2015双11之后，天猫已经彻底抛弃IE6/7，于是babel的引入就成为最先敲定的方案。
同时，基于commonjs规范进行本地开发也是一个共识，基于有编译过程，本地开发完全可以和Node一致采用commonjs规范，至于最后编译成amd、cmd或者是其他浏览器模块运行规范可以由构建工具决定。
接下来，引入Babel之后，前端是不是可以完全基于规范开发，不要再引入各种框架/库什么的？
然而，基本不可能，没有公共库就没有复用，就会有大量重复代码，而社区有大量的lib库，显然比内部写的公共库更加完善。参与社区模块的建设显然比闷声造轮子更有意义。而React本身也可以作为模块库中的一个模块存在，复杂业务可以使用React，简单业务也可以基于原生开发。
于是最后，我们确定：
babel+commonjs作为基于标准开发解决方案
颗粒化引入社区lib，react也是lib之一
简单业务基于原生+zepto，足够简单灵活但是不重复
复杂业务基于react解耦，加上其他通用lib来补全功能
npm还是cdn combo
问题并没有结束，引入社区lib是不是意味着要引入类似webpack的打包机制？KISSY 6已经拥抱npm，这也是社区模块的最佳实践。下面是一些对比。
npm的优势：
npm
模块内聚性高，对外API统一
执行期无seed，降低运行期复杂度
cdn combo
模块被调用方式不可控
seed体积庞大，也是性能上的负担
cdn combo的优势：
npm
无法按需加载，页面公共部分无法动态更新
组件间存在重复代码
cdn combo
支持按需加载、多端加载
颗粒化拼装，少重复代码，可跨页面缓存
combo还是打包本质的区别是 动态打包 还是 静态打包；combo其实也是一种打包，只是是一种url显性表达合并配置的打包方案。
从模块颗粒化及页面性能考虑，cdn combo还是主要的方案，毕竟对于天猫的活动、频道页面来说，保证首屏体验是性能优化非常重要的一部分，只有基于combo才能动态按需地实现首屏同步加载，非首屏动态异步加载。npm方式也能做但是对于页面级需要有一个构建过程，而cdn combo只需要模块构建，页面只是一个模块的组合而不需要构建。
基于CDN combo，未来可以做更多的优化：
最大化公用缓存，尤其是在mobile可以控制容器的场景如zcache（可缓存的容量是有限制的如果没限制打包更简单）
未来基于数据分析动态化精细化跨页面资源加载（例如希望针对部分地区首先加载a,b 对另一部分地区首先加载 abc，打包就必须针对每种case打出不同内容）
同时，基于npm打包的优势也需要考虑引入到体系中。 比如一个组件内不需要暴露外面的util.js 一定是和组件其他文件被外界使用，此时被combo反而带来的合并及读取的开销，此时更适合打包对外统一暴露一个文件出口。所以有复用价值的combo才合适
综合下来其实是combo和打包配合的方案，combo用来完成有复用价值部分的管理，打包用来完成无复用价值的内聚。
而seed体积精简可以通过服务端的动态seed合并及去掉已同步加载模块的seed来实现，保证页面上seed的内容一定是会使用到的。
由于开发期引入了babel，调试时就不能简单绑定host到本地了，需要引入source map，但是sourcemap对combo后的url无法解析，所以需要在机制上实现调试时解combo，客户端和服务端都支持一下就可以了，具体实现可以见后面加载机制里的设计。
多端加载能力
如上面描述，确认了前端工作流的大部分细节：
模块使用CDN combo实现按需加载
ES + commonjs的开发规范
基于原生规范的颗粒化组件，简单lib如zepto解决简单业务，react组件解决复杂业务数据解耦问题
接下来就是多端加载的解决了。
第一步就是需要一个Loader，这里需要把Native组件一起考虑进来，于是我们提供了这样的Loader加载策略，feloader是目前加载器的名字，wormhole是服务端模板渲染服务。
无论是开发Native还是Web，都采用一样的方式生成配置文件，基于配置文件，模块之间的调用关系就可以明确，然后服务端可以根据依赖表输出combo uri及直接对Native模块进行组合。
浏览器端目前由于无法直接运行commonjs规范的脚本，解决方案也非常简单，在构建工具打包的时候，包上一层define(modName, deps, function(require, exports, module))即可。
Node渲染服务也需要实现基于模块配置的依赖分析，生成combo uri，如果是native模块，则直接分析完依赖后，将模块内容拼接成一个大的脚本返回。
MAP 4.0体系下的前端开发
疑问
1）从KISSY迁移到目前的开发模式，改动很大，以后还会不会有这样的大范围升级？
答案是，升级肯定会有，保持依赖模块和使用技术的新鲜才能提升业务效率，毕竟用户环境、外部社区也是在不断升级。但是不会有大范围的升级：一方面我们采用基于浏览器标准规范的方式开发，这一部分属于相对比较稳定，变化不会对研发造成负面影响，另一方面模块本身颗粒化，升级一样也是颗粒化，快速迭代的方式，而不是所有模块一起选一个特定时间集中式改造，减少对业务的影响，让升级融入到业务开发中。
2）基础体系变化怎么大，如何解决兼容问题？
兼容问题确实比较大，首先Node容器和本地开发工具都需要向前兼容，这个是必须的。
而对于前端开发的模块，我们提供了一个kissy-polyfill方案让AMD模块在KISSY页面上运行，这样可以让大家快速开始基于新的方式开发模块，然后这个模块可以在老页面上运行。
具体实现也很简单
define -> KISSY.add
require -> KISSY.use
require.config -> KISSY.config
其他就是一些加载器细节的patch，比如已经加载模块的配置可以重写什么的。
3）目前MUI体系引入了zepto作为基础DOM/event的解决方案，如何支持IE8/9？是不是依然需要无线PC两套基础库？
目前我们是这么解决的：
开发时统一使用zepto
feloader中有这么一段处理：ie8/9下将zepto alias到jquery，这里会有一些细微的差别，但是目前看这个模式是可行且确实对开发者来说基本无感知
结尾
很多人其实觉得前端基础技术体系已经很难有突破，但是虽然MAP升级了那么多版本，ES规范也在不停升级，但是很多背后的思想还是一致，只是在原来的基础上不断优化细节，然后提高扩展性。这也是为什么前端一直在强调基础的重要性，CSS2，ES3依然是基础的重要组成部分，工具框架只是外壳，理解为什么这么设计远重要于知道如何使用。
最后，欢迎加入天猫前端：），nodejs/web/native方向都需要，简历到butian.wth[at]http://taobao.com，期待你的加入
PC与无线齐飞，Web共Native一色——天猫首页全解密
1 年前
某天突然看到了这个问题淘宝和天猫首页都用到了哪些技巧或者技术？ - 岳逢楽的回答，作为天猫首页的负责人薛定谔，我也只好解剖一把天猫首页，让大家看看它的骨肉血皮到底是怎个模样。人格担保虽然有该回答下有撸文狂魔小胡子哥珠玉在前，但本文绝对有不一样的地方哟~
比如……如何快速响应需求，解放生产力。
比如……移动端首页和WeeX首页的落地经验。
比如……广告，天猫前端团队正在诚意招资深前端开发工程师（社招），简历请发到yueyuan.cx@alibaba-inc.com
从14年实习开始参与PC首页的开发，到15年正式入职同时负责无线端的首页，至今已经两年的时间。期间历经了6次改版、php到Node端的迁移、ReactNative的尝试、无线端性能优化、进入ES6时代、WeeX的尝试等等，不一而足，感触颇多，与大家分享。
也是一篇难得的长文，先放提纲。
一、天猫首页的定位
二、天猫首页的技术架构变迁史
1. 从PHP到Node的蜕变
2. 从静到动，从PC到移动端的飞跃
3. 光影融合，Web与客户端的交汇
三、疾如风——天猫首页的性能优化
四、侵略如火——大胆的Native化尝试
1. ReactNative的初登场
2. WeeX的回归
五、不动如山——天猫首页的稳定性保障
六、小结
一、天猫首页的定位
在了解天猫首页的技术架构之前，先让我们问自己一个问题：首页到底是什么？是用户关于这个网站的第一印象吗？还是所有业务的起始点？
简而言之，天猫首页有着以下三个特点：
面向最广大消费者的标杆与门面。
流量的入口与中转站。
轻耦合，新技术的试验田。
作为天猫的门面，往往决定了消费者对于天猫的第一印象，所以天猫首页一直在性能优化上有着孜孜不倦的追求，优化加载性能、交互体验、减少流量消耗、Native等多种方式给于消费者更好的体验。
作为流量的中转站，首页赋予了运营非常多灵活机动的能力，例如节日氛围的营造、机动区块的变化能力，并且全面铺开个性化，能够基于人群、地区推荐更加适合用户的商品，导流效率遥遥领先于其他页面。
作为新技术试验田，天猫首页一直处于开放的态度，敢打敢冲，率先尝鲜新技术并落地：2014年9月份率先从PHP迁移到Node、天猫内第一个尝试ReactNative、第一个进入ES6时代、第一个落地WeeX的重要业务。在这一过程中，天猫首页往往会克服非常多先行者的困难，并反哺新技术的优化与成熟。
二、天猫首页的技术架构变迁史
天猫首页的技术架构变迁，主要是基于两个部分：内部搭建系统&模板渲染系统的变更、业务重点的变更。
1. 从PHP到Node的蜕变
在PHP时代，主要存在以下问题：
老旧的服务端实时渲染架构。渲染性能差、服务集群庞大使得文件同步生效慢。
旧搭建系统规范使得效率低。需要手动在php文件中挖出供运营填写数据的位置，该数据位难以定义其他校验规范。
php文件和css/js文件不属于同一套部署系统，需要手动控制顺序，先发布新版本css/js文件到cdn，再发布php文件更新引用css/js文件的版本，容易出现发布手误。
在Node时代，上述问题都得到了解决，在首页完成迁移Node的尝试后，我们拥有了新的内部搭建系统斑马和模板渲染系统Wormhole：
在使用『Cache集群缓存渲染好的HTML』这一架构后，性能、抗压能力、可扩展性都有了极大的提升(关于这一点详细可以看@Barret李靖的回答)。
接入schema规范系统，建立数据位置的代码与前端代码解耦。
隔离职能。HTML模板代码专注于渲染，不再处理其他事情。
部署系统统一。不再出现需要关注文件发布顺序、手动升级版本的情况。
关于Node应用的更多信息，可以：关注前天猫Node负责人@死马的回答Node.js 在双十一中有哪些应用，表现如何？ - 死马的回答以及现天猫Node负责人@ngot的回答如何看待天猫彻底抛弃PHP？ - ngot 的回答
2. 从静到动，从PC到移动的转身
从2014年开始，天猫开始集体转型，迎接移动端时代的来临，直到2015年双十一，移动端成交占比已达到68%。
无线时代有甜也有苦：
不需要纠结坑爹的IE兼容性，但是老版本的安卓兼容起来更加痛苦
因为安卓的碎片化，响应式也是需要考虑的重要问题
高清化的处理方案
部分方案需要优化如iconfont，因为可能会发送多个请求，影响性能
糟糕的网络环境、机器性能、系统特性对于性能有着更加极致的需求
因为移动端和PC端用户的使用习惯差距较大，同时考虑后续维护的方便性，移动端的天猫首页的UI设计上并未使用传统概念上的响应式(PC和移动端一套代码)，而是与天猫客户端保持一致。
这一前提使得移动端Web首页可以和客户端共用接口，共享同一份数据来源，避免运营填写多份数据，节省运营成本，又因为移动端大量个性化推荐的需求，千人千面的展现方式，所以移动端Web首页采用了异步渲染的方案——页面进入只载入框架，再调用接口获取数据和模板，在浏览器端进行渲染。这样做也有诸多好处：客户端中访问可以使用离线包、更少的流量消耗、更细粒度的ABTest、对接其他数据源更方便等等。
同时还实现了一套可以快速满足区块调整需求的动态化布局方案，完美地支持了多次需求变更而无需前端代码发布，详细可见发表在天猫前端团队博客的这篇文章，让需求来得再猛烈些——快速响应需求的天猫H5首页新架构 · Issue #35 · tmallfe/tmallfe.github.io · GitHub
3. 光影融合，Web和客户端的交汇
相比起客户端业务迭代的成本、体积和发版劣势，Web的低成本、迭代快、跨平台的特性，使得绝大多数客户端的业务都会选择嵌入Web的方式。而客户端的黏性，使得这个Web页面相当大一部分的流量都来源于客户端。
那么一个新的问题来了：『客户端中的Web页面如何利用客户端的能力？是不是可以将Web和客户端进行融合，获取更好的体验？』
最初尝试了几个方案：
Hybrid API。
跳转部分高频页面根据Url规则拦截到Native页（如商品详情页）。
复用客户端建立的网络链路
离线包等等
都取得了一定的效果，但是还需要一套更加完整彻底的方案。所以在2015年7月React Native如火如荼的时候，天猫首页立刻开启了尝试的项目，相关内容后文详述。
三、疾如风——天猫首页性能优化
性能一直是首页所需要关注的要点，希望能给用户更好的体验。
首先明确一点，有很多优化不是单纯的前端团队能够完成的，有CDN团队和服务端团队的支持，让前端同学感觉像生活在极乐天国。《高性能网站建设指南》这本书里提到的方法都比较基础了，在此略过。
除此之外，我们还做了以下对于性能有着显著影响的事情：
css/js文件combo。我们的CDN和前端Loader支持实时url的combo，可以实现按需加载。如果CDN没这个条件，也可以使用webpack等前端工具进行合并打包。
懒加载。优先渲染首屏内容，其余模块资源延后或者用户有交互的时候加载。
Webp图片格式。对比这两张图，可以发现Webp格式的图小得多，WebP格式的图：https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg_.webp；jpg格式的图：https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg。感谢（图片存储系统的同学）。
裁剪合适尺寸的图片。如果某一张图片运营投放的尺寸过大，可以根据实际的尺寸，加上后缀截取，如『https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg_100x100.jpg』。
拍扁所有请求。每个模块渲染所需要的请求不能是两个请求串行。
数据请求支持自由合并。（感谢服务端同学）
前端首屏只请求后端一个请求，由后端做对接其他系统的并行请求。
利用动态化布局保证模块之间的高复用。
图片域名收敛。因为CDN支持SPDY协议，所以收敛域名可以有效节省DNS解析时间。
天猫前端组件规范整体升级，移动端去KISSY，变得更加轻量，减少流量消耗。
离线包。如果页面是纯异步渲染，可以考虑在客户端中设置离线包。只有当用户处于wifi且网络空闲时，客户端才会去下载离线包，二次访问效果拔群。
再让我用一张图说明页面渲染各个阶段可以做的优化。
除了加载性能外，还需要考虑交互性能，例如页面滚动时的帧率。
除了用requestAnimationFrame来将模块渲染切片，避免UI线程阻塞。如果页面的hover和mouseenter效果过多，还可以在用户滚动时，设置全局的pointer-event:none，避免在滚动的时候触发大量hover效果，实测效果拔群。
四、侵略如火——大胆的Native化尝试
相比起Web而言，APP有着更好的体验；但相比APP，Web的开发效率和发版优势毋庸置疑，如何融合两者，一直是前端的重要探索方向之一。
1. ReactNative的初登场
2015年7月，天猫首页立刻进行了ReactNative的尝试。
但在尝试过程中遇到了非常多的问题，满满的坑和血泪：
一方面是ReactNative彼时并不完善，调试体验非常糟糕，莫名其妙红屏不知原因，还有升级0.8.0后会顺手升级iojs为3.x,和2.x的iojs并不兼容。
另一方面是当时考虑并不完备。工程化落地一个技术需要考虑的因素非常多：多版本降级&兼容方案、开发调试工具、环境一致性、埋点、测试、监控、后续维护成本等等，需要考虑一系列的方案。
因为没有拿到数据和结果，并且没有足够的人力维护多一个版本的页面时，RN版的首页选择了停止维护。但是ReactNative在天猫和双十一还有大范围的应用，详细可以看《天猫双11前端分享系列（三）：浅谈 React Native与双11》天猫双11前端分享系列（三）：浅谈 React Native与双11 · Issue #27 · tmallfe/tmallfe.github.io · GitHub
2. WeeX的回归
正如灰太狼被打飞时常说的一句话——『我还会回来的』，在手淘团队推出了一套新的Native化方案WeeX以后，天猫首页又死性不改蠢蠢欲动地进行了尝试。
这一次考虑较为全面，上述RN落地时没考虑的方案都有一定的考虑和解决，例如：
自动构建Web版本以降低维护成本
多Weex版本的降级方案
Cache集群部署Detector自动识别请求是否支持WeeX并返回对应内容。
实际体验优于Web，从业务数据上来看也取得了较好的结果。
感兴趣的同学可以使用iOS手机淘宝客户端5.7.0以上版本扫码下述图片体验。
https://img.alicdn.com/tps/TB1GAYMKXXXXXcTaXXXXXXXXXXX-260-260.png
Weex页面非常精简，gzip后首页JSBundle的大小大概是13K，是Web的十五分之一。
WeeX即将开源，敬请期待。
五、不动如山——天猫首页的稳定性与保障
大概是心有灵犀吧，天猫首页和淘宝首页也采用了非常类似的容灾和监控机制，有小胡子哥的详述，我在此就一笔带过。
1.在容灾方面：
如果接口请求失败，会依次加载本地缓存、访问CDN的备份文件等。
对于运营填写的数据内容质量，投放系统配置了详细的校验，如最大字数等等。
2. 在监控方面：
有全量监控的埋点方案。能够全网统计到各个模块的运行状况和接口调用的健康情况。
有客户端层面的监控方案。能够拿到更多Web运行时无法自己拿到的信息，如当前页面某一链接404。
有业务监控的方案。能够保障页面的业务内容一定是符合预期的。因为首页的数据来源相当多，一个页面对应几十个运营，对于数据内容的质量是一定要保障的。
六、小结
接下来天猫首页还会做的事情大概有：
赋能运营。接入个性化合图系统，免去了运营找设计师做图的成本等等；
国际化。为了方便弱网地区用户的访问，对于性能有更高的要求，对于设计、素材也有更高的要求。
提笔匆忙，感觉虎头蛇尾，还请见谅。
如果有不明白的地方欢迎指出，欢迎和我一起来完善这篇文章哈哈。
最后，天猫前端团队正在诚意招资深前端开发工程师，简历请发到yueyuan.cx@alibaba-inc.com
