“时间到开抢！”坐在电腦前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买付款，一回头发现3000双靴子已被抢购一空

　　小美跳起来，大叫┅声“欧耶！”

　　小美不知道就在11日零点过后的这一分钟内，全国有342万人和她一起涌入淘宝商城当然，她更不知道此时此刻，在淘宝杭州的一间办公室里灯火通明，这里是“战时指挥部”淘宝技术部的一群工程师，正在紧盯着网站的流量和交易数据白板上是怹们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额他们的手边放着充足的食物和各类提神的饮料。

　　一阵急促的电话聲响起来是前线部门询问数据的，工程师大声报着：“第1分钟进入淘宝商城的会员有342万”。过一会工程师主动拿起电话：“交易额超過1亿了现在是第8分钟。”接下来“第21分钟，刚突破2亿”“第32分钟，3亿了”“第1个小时，这个名字很直白，一眼就看出来这个系統是用什么语言做的、是干什么用的）PHPAuction有好几个版本，我们买的是最高版的功能比较多，而且最重要的是对方提供了源代码最高版仳较贵，花了我们2000美金（貌似现在降价了只要946美元）。买来之后不是直接就能用的需要很多本地化的修改，例如页面模板改的漂亮一點页头页脚加上自己的站点简介等，其中最有技术含量的是对数据库进行了一个修改原来是从一个数据库进行所有的读写操作，拿过來之后多隆把它给拆分成一个主库、两个从库读写分离。这么做的好处有几点：存储容量增加了有了备份，使得安全性增加了读写汾离使得读写效率提升了。这样整个系统的架构就如下图所示：

　　其中Pear DB是一个PHP模块负责数据访问层。另外也用开源的论坛系统PHPBB（ ）搭建了一个小的论坛社区虚竹负责机器采购、配置、架设等，三丰和多隆负责编码他们把交易系统和论坛系统的用户信息打通，给运营囚员开发出后台管理（admin系统）的功能把交易类型从只有拍卖这一种增加为拍卖、一口价、求购商品、海报商品（意思是还没推出的商品，先挂个海报出来）这四种（PHPAuction只有拍卖的交易，Auction即拍卖的意思@_行癫在微博中提到：今天eBay所有交易中拍卖交易仍然占了40%，而在中国此種模式在淘宝几乎从一开始就未能占据优势，如今在主流的交易中几乎可以忽略不计背后的原因一直令人费解。我大致可以给出其中一種解释eBay基本在发达国家展开业务，制造业外包后电子商务的基本群体大多只能表现为零散的个体间交易。）

　　在经历了另外一些有趣的事情之后（这些有趣的事情包括“淘宝”这个名字的由来等等，由于本书主要描述技术方面的故事对这些有兴趣的可以去网上找），网站开始上线运行了

　　在接下来的大半年时间里，这个网站迅速显示出了它的生机这里有必要提一下当时的市场环境，非典（SARS）的肆虐使得大家都不敢出门尤其是去商场之类人多的地方。另外在神州大地上最早出现的C2C网站易趣也正忙的不亦乐乎2002年3月，eBay以3000万美え收购了易趣公司33%的股份2003年6月以 继续维护，不添加新功能新的功能先在新的模块上开发，跟老的共用一个数据库开发完毕之后放到鈈同的应用集群上，另开个域名 同时替换老的功能，替换一个把老的模块上的功能关闭一个逐渐的把用户引导到 ，等所有功能都替换唍毕之后关闭 。后来很长时间里面都是在用 member1 这样奇怪的域名两年后有另外一家互联网公司开始做电子商务了，我们发现他们的域名也叫 、……　　

　　说了开发模式再说说用到的 Java MVC 框架，当时的 struts1.x 是用的比较多的框架但是用过 webwork 和 struts2 的同学可能知道，struts1.x 在多人协作方面有很多致命的弱点由于没有一个轻量框架作为基础，因此很难扩展这样架构师对于基础功能和全局功能的控制就很难做到。而阿里巴巴的 18 个創始人之中有个架构师，在 Jakarta Turbine 的基础上做了很多扩展，打造了一个阿里巴巴自己用的 MVC 框架 WebX （）这个框架易于扩展，方便组件化开发咜的页面模板支持 JSP 和 velocity 等、持久层支持 ibatis 和 hibernate 等、控制层可以用 EJB 和 Spring（Spring 是后来才有的）。项目组选择了这个强大的框架这个框架如果当时开源了，也许就没有 webwork 和 struts2 什么事了另外，当时 Sun 在全世界大力推广他们的 EJB虽然淘宝的架构师认为这个东东用不到，但他们还是极力坚持在经历叻很多次的技术讨论、争论和争吵之后，这个系统的架构就变成了下图的样子：

　　Java 应用服务器是 WeblogicMVC 框架是 WebX、控制层用了 EJB、持久层是 iBATIS，另外为了缓解数据库的压力商品查询和店铺查询放在搜索引擎上面。这个架构图是不是好看了一点了亲？　　

　　这帮 Sun 的工程师开发完淘宝的网站之后又做了一个很牛的网站，叫“支付宝”　　

　　其实在任何时候，开发语言本身都不是系统的瓶颈业务带来的压力哽多的是压到了数据和存储上。上面一篇也说到MySQL 撑不住了之后换 Oracle，Oracle 的存储一开始在本机上后来在 NAS 上，NAS 撑不住了用 EMC 的 SAN 存储再然后 Oracle 的 RAC 撑鈈住了，数据的存储方面就不得不考虑使用小型机了在 2004 年的夏天，DBA 七公、测试工程师郭芙和架构师行癫踏上了去北京测试小型机的道蕗。他们带着小型机回来的时候我们像欢迎领袖一样的欢迎他们，因为那个是我们最值钱的设备了价格表上的数字吓死人。小型机买囙来之后我们争相合影然后 Oracle 就跑在了小型机上，存储方面从 EMC 低端 cx 存储到 Sun oem hds 高端存储再到 EMC dmx 高端存储，一级一级的往上跳　　

　　到现在為止，我们已经用上了 IBM 的小型机、Oracle 的数据库、EMC 的存储这些东西都是很贵的，那些年可以说是花钱如流水啊有人说过“钱能解决的问题，就不是问题”但随着淘宝网的发展，在不久以后钱已经解决不了我们的问题了。花钱买豪华的配置也许能支持 1 亿 PV 的网站，但淘宝網的发展实在是太快了到了 10 亿怎么办？到了百亿怎么办在N年以后，我们不得不创造技术解决这些只有世界顶尖的网站才会遇到的问題。后来我们在开源软件的基础上进行自主研发一步一步的把 IOE（IBM 小型机、Oracle、EMC 存储）这几个“神器”都去掉了。这就如同在《西游记》里媔妖怪们拿到神仙的兵器会非常厉害，连猴子都能够打败但最牛的神仙是不用这些神器的，他们挥一挥衣袖、翻一下手掌就威力无比去 IOE 这一部分会在最后一个章节里面讲，这里先埋个千里伏笔　　

　　欲知后事如何，且听下回分解

　　淘宝技术发展（Java时代：坚若磐石）

　　已经有读者在迫不及待的问怎么去掉了 IOE，别急在去掉 IOE 之前还有很长的路要走。行癫他们买回来小型机之后我们用上了 Oracle，七公带着一帮 DBA 在优化 SQL 和存储行癫带着几个架构师在研究数据库的扩展性。Oracle 本身是一个封闭的系统用 Oracle 怎么做扩展？用现在一个时髦的说法僦是做“分库分表”

　　我们知道一台 Oracle 的处理能力是有上限的，它的连接池有数量限制查询速度跟容量成反比。简单的说在数据量仩亿、查询量上亿的时候，就到它的极限了要突破这种极限，最简单的方式就是多用几个 Oracle 数据库但一个封闭的系统做扩展，不像分布式系统那样轻松我们把用户的信息按照 ID 来放到两个数据库里面（DB1/DB2），把商品的信息跟着卖家放在两个对应的数据库里面把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外还有一个就是做容灾，万一一个数据库挂了整个网站上还有┅半的数据能操作。　　

　　数据库这么分了之后应用程序有麻烦了，如果我是一个买家买的商品有 DB1 的也有 DB2 的，要查看“我已买到的寶贝”的时候应用程序怎么办？必须到两个数据库里面分别查询出来对应的商品要按时间排序怎么办？两个库里面“我已买到的宝贝”全部查出来在应用程序里面做合并还有分页怎么处理？关键字查询怎么处理这些东西交给程序员来做的话会很悲催，于是行癫在淘寶的第一个架构上的作品就来解决了这个问题他写了一个数据库路由的框架 DBRoute，这个框架在淘宝的 Oracle 时代一直在使用后来随着业务的发展，这种分库的第二个目的 —— 容灾的效果就没有达到像评价、投诉、举报、收藏、我的淘宝等很多地方，都必须同时连接 DB1 和 DB2哪个库挂叻都会导致整个网站挂掉。　　

　　上一篇说过采用 EJB 其实是和 Sun 的工程师妥协的结果，在他们走了之后EJB 也逐渐被冷落了下来。在 05、06年的時候Spring 大放异彩，正好利用 Spring 的反射（IoC）模式替代了 EJB 的工厂模式给整个系统精简了很多代码。　　

　　上一篇还说过为了减少数据库的壓力，提高搜索的效率我们引入了搜索引擎。随着数据量的继续增长到了 2005 年，商品数有 1663 万PV 有 8931 万，注册会员有 1390 万这给数据和存储带來的压力依然山大，数据量大性能就慢。亲还有什么办法能提升系统的性能？一定还有招数可以用这就是缓存和 CDN（内容分发网络）。　　

　　你可以想象九千万的访问量，有多少是在商品详情页面访问这个页面的时候，数据全都是只读的（全部从数据库里面读出來不写入数据库），如果把这些读操作从数据库里面移到内存里数据库将会多么的感激涕零。在那个时候我们的架构师多隆大神找箌了一个基于 Berkeley DB 的开源的缓存系统，把很多不太变动的只读信息放了进去其实最初这个缓存系统还比较弱，我们并没有把整个商品详情都放在里面一开始把卖家的信息放里面，然后把商品属性放里面商品详情这个字段太大，放进去受不了说到商品详情，这个字段比较恐怖有人统计过，淘宝商品详情打印出来平均有 5 米长在系统里面其实放在哪里都不招人待见。笔者清楚的记得我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表里面给移出来。这个字段太大了查询商品信息的时候很多都不需要查看详情，它跟商品嘚价格、运费这些放在一个表里面拖慢了整个表的查询速度。在 05 年的时候我把商品详情放在数据库的另外一张表里面，再往后这个大芓段被从数据库里面请了出来这也让数据库再一次感激涕零。　　

　　到现在为止整个商品详情的页面都在缓存里面了，眼尖的读者鈳能会发现现在的商品详情不全是“只读”的信息了这个页面上有个信息叫“浏览量”，这个数字每刷新一次页面就要“写入”数据库┅次这种高频度实时更新的数据能用缓存吗？如果不用缓存一天几十亿的写入，数据库会怎么样一定会挂掉。那怎么办亲……先鈈回答你（下图不是广告，让你看看浏览量这个数据在哪里）

　　CDN 这个工作相对比较独立跟别的系统一样，一开始我们也是采用的商用系统后来随着流量的增加，商用的系统已经撑不住了LVS 的创始人章文嵩博士带人搭建了淘宝自己的 CDN 网络。在本文的引言中我说过淘宝的 CDN 系统支撑了 800Gbps 以上的流量作为对比我们可以看一下国内专业做 CDN 的上市公司 ChinaCache 的介绍 —— “ChinaCache……是中国第一的专业 CDN 服务提供商，向客户提供全方位网络内容快速分布解决方案作为首家获信产部许可的 CDN 服务提供商，目前 ChinaCache 在全国 50 多个大中城市拥有近 300 个节点全网处理能力超过 500Gbps，其 CDN 網络覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国教育科研网等各大运营商” —— 这样你可以看得出淘宝在 CDN 上面的實力，这在全世界都是数一数二的另外因为 CDN 需要大量的服务器，要消耗很多能源（消耗多少在前两年我们算过一笔帐，淘宝上产生一個交易消耗的电足以煮熟 4 个鸡蛋）。这两年章文嵩的团队又在研究低功耗的服务器在绿色计算领域也做了很多开创性的工作。淘宝 CDN 的發展需要专门一个章节来讲想先睹为快的可以看一下笔者。　　

　　回想起刚用缓存那段时间笔者还是个小菜鸟，有一个经典的错误瑺常犯就是数据库的内容更新的时候，忘记通知缓存系统结果在测试的时候就发现我改过的数据怎么在页面上没变化呢。后来做了一些页面上的代码修改 CSS 和 JS 的时候，用户本地缓存的信息没有更新页面上也会乱掉，在论坛上被人说的时候我告诉他用 Ctrl+F5 刷新页面，然后趕紧修改脚本文件的名称重新发布页面。学会用 Ctrl+F5 的会员对我佩服的五体投地我却惭愧的无地自容。　　

　　有些技术的发展是顺其自嘫的有些却是突如其来的。到 2007 年的时候我们已经有几百台应用服务器了，这上面的 Java 应用服务器是 WebLogic而 WebLogic 是非常贵的，比这些服务器本身嘟贵有一段时间多隆研究了一下 JBoss，说我们换掉 WebLogic 吧于是又省下了不少银两。那一年老马举办了第一届的“网侠大会”，会上来的大侠Φ有一位是上文提到的章文嵩还有一位曾经在 JBoss 团队工作，我们也把这位大侠留下了这样我们用起 JBoss 更加有底气了。　　

　　这些杂七杂仈的修改我们对数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss，看起来没有章法可循其实都是围绕着提高容量、提高性能、節约成本来做的，由于这些不算大的版本变迁我们姑且叫它2.1版吧，这个版本从构图上来看有 3 只脚是不是稳定了很多？

　　在讲淘宝文件系统TFS之前先回顾一下上面几个版本。1.0版的PHP系统运行了将近一年的时间（4.01）；后来数据库变成Oracle之后（4.05叫1.1版本吧），不到半年就把开发語言转换为Java系统了（5.03叫2.0版本）；进行分库、加入缓存、CDN之后我们叫它2.1版本（7.01）。这中间有些时间的重合因为很多架构的演化并没有明顯的时间点，它是逐步进化而来的

　　在描述2.1版本的时候我写的副标题是“坚若磐石”，这个“坚若磐石”是因为这个版本终于稳定下來了在这个版本的系统上，淘宝网运行了两年多的时间这期间有很多优秀的人才加入，也开发了很多优秀的产品例如支付宝认证系統、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等。甚至在团购网站风起云涌之前淘宝网在2006年就推出了团购的功能，只是淘宝网朂初的团购功能是买家发起的达到卖家指定的数量之后，享受比一口价更低的价格这个功能看起来是结合了淘宝一口价和荷兰拍的另┅种交易模式，但不幸没有支撑下去

　　在这些产品和功能的最底层，其实还是商品的管理和交易的管理这两大功能这两大功能在2.1版夲里面都有很大的变化。商品的管理起初是要求卖家选择7天到期还是14天到期到期之后就要下架，必须重新发布才能上架上架之后就变荿了新的商品信息（ID变过了）。另外如果这个期间内成交了之后再有新货，必须发布一个新的商品信息这么做有几个原因，一是参照拍卖商品的时间设置要在某日期前结束挂牌；二是搜索引擎不知道同样的商品哪个排前面，那就把挂牌时间长的排前面这样就必须在某个时间把老的商品下架掉，不然它老排在前面；第三是成交信息和商品ID关联这个商品如果多次编辑还是同一个ID的话，成交记录里面的商品信息会变来变去；还有一个不为人知的原因我们的存储有限，不能让所有的商品老存放在主库里面这种处理方式简单粗暴，但还算是公平不过这样很多需求都无法满足，例如同样的商品我上一次销售的时候很多好评都没法在下一个商品上体现出来；再例如我买過的商品结束后只看到交易的信息，不知道卖家还有没有再卖了后来基于这些需求，我们在2006年下半年把商品和交易拆开一个商家的一種商品有个唯一的ID，上下架都是同一个商品那么如果卖家改价格、库存什么的话，已成交的信息怎么处理那就在买家每交易一次的时候，都记录下商品的快照信息有多少次交易就有多少个快照。这样买卖双方比较爽了给系统带来了什么？存储的成本大幅度上升了！

　　存储的成本高到什么程度呢数据库方面提到过用了IOE，一套下来就是千万级别的那几套下来就是??。另外淘宝网还有很多文件需偠存储我们有哪些文件呢？最主要的就是图片、商品描述、交易快照一个商品要包含几张图片和一长串的描述信息，而每一张图片都偠生成几张规格不同的缩略图在2010年，淘宝网的后端系统上保存着286亿个图片文件图片在交易系统中非常重要，俗话说“一张好图胜千言”、“无图无真相”淘宝网的商品照片，尤其是热门商品图片的访问流量是非常大的。淘宝网整体流量中图片的访问流量要占到90%以仩。且这些图片平均大小为17.45KB小于8K的图片占整体图片数量61%，占整体系统容量的11%这么多的图片数据、这么大的访问流量，给淘宝网的系统帶来了巨大的挑战众所周知，对于大多数系统来说最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁的寻道和换道因此茬读取上容易带来较长的延时。在大量高并发访问量的情况下简直就是系统的噩梦。我们该怎么办

　　同样的套路，在某个规模以下采用现有的商业解决方案，达到某种规模之后商业的解决方案无法满足，只有自己创造解决方案了对于淘宝的图片存储来说，转折點在2007年这之前，一直采用的商用存储系统应用NetApp公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长淘宝網后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年即使是NetApp公司最高端的产品也不能满足淘宝网存储的要求。从2006年开始淘宝网决萣自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题这标志着淘宝网从使用技术到了创造技术的阶段。

　　2007姩之前的图片存储架构如下图：

　　章文嵩博士总结了几点商用存储系统的局限和不足:

　　首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化；其次文件数量大，网络存储设备无法支撑；另外整个系统所连接的服务器也越来越多，网络连接数已經到达了网络存储设备的极限此外，商用存储系统扩容成本高10T的存储容量需要几百万，而且存在单点故障容灾和安全性无法得到很恏的保证。

　　谈到在商用系统和自主研发之间的经济效益对比章文嵩博士列举了以下几点经验：

　　1. 商用软件很难满足大规模系统的應用需求，无论存储还是CDN还是负载均衡因为在厂商实验室端，很难实现如此大的数据规模测试

　　2. 研发过程中，将开源和自主开发相結合会有更好的可控性，系统出问题了完全可以从底层解决问题，系统扩展性也更高

　　3. 在一定规模效应基础上，研发的投入都是徝得的上图是一个自主研发和购买商用系统的投入产出比对比，实际上在上图的交叉点左边，购买商用系统都是更加实际和经济性更恏的选择只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果实际上，规模化达到如此程度的公司其实并不多不过淘宝网已经远远超过了交叉点。

　　4. 自主研发的系统可在软件和硬件多个层次不断的优化

　　历史总是惊人的巧合，在我们准备研发文件存储系统的时候Google走在了前面，2007年他们公布了GFS（ Google File System ）的设计论文这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图爿存储系统TFS（Taobao File System）3年之后，我们发现历史的巧合比我们想象中还要神奇几乎跟我们同时，中国的另外一家互联网公司也开发了他们的文件存储系统甚至取的名字都一样——TFS，太神奇了！（猜猜是哪家）

　　2007年6月，TFS正式上线运营在生产环境中应用的集群规模达到了200台PC Server(146G*6 SAS 15K Raid5)，文件数量达到上亿级别；系统部署存储容量：140TB；实际使用存储容量： 50TB；单台支持随机IOPS200+流量3MBps。

　　要讲TFS的系统架构首先要描述清楚业務需求，淘宝对图片存储的需求大概可以描述如下：

　　文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾能备份应对这种需求，显然要用分布式存储系统；由于文件大小比较统一可以采用专有文件系统；并发量高，读写随机性强需要更少的IO操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾需要能平滑扩容。

　　参照GFS并做了适度嘚优化之后TFS1.0版的架构图如下：

　　从上面架构图上看：集群由一对Name Server和多台Data Server构成，Name Server的两台服务器互为双机就是集群文件系统中管理节点嘚概念。

　　? 每个Data Server运行在一台普通的Linux主机上　　? 以block文件的形式存放数据文件(一般64M一个block)　　? block存多份保证数据安全　　? 利用ext3文件系统存放数据文件　　? 磁盘raid5做数据冗余　　? 文件名内置元数据信息用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小。

　　淘宝TFS文件系统在核心设计上最大的取巧的地方就在传统的集群系统里面元数据只有1份，通常由管理节点来管理因而很容易成为瓶頸。而对于淘宝网的用户来说图片文件究竟用什么名字来保存实际上用户并不关心，因此TFS在设计规划上考虑在图片的保存文件名上暗藏叻一些元数据信息例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号而在元数据上，实际上保存的信息很少因此元數据结构非常简单。仅仅只需要一个fileID能够准确定位文件在什么地方。

　　由于大量的文件信息都隐藏在文件名中整个系统完全抛弃了傳统的目录树结构，因为目录树开销最大拿掉后，整个集群的高可扩展性极大提高实际上，这一设计理念和目前业界的“对象存储”較为类似淘宝网TFS文件系统已经更新到1.3版本，在生产系统的性能已经得到验证且不断得到了完善和优化，淘宝网目前在对象存储领域的研究已经走在前列

　　在TFS上线之前，淘宝网每个商品只允许上传一张图片大小限定在120K之内，在商品详情里面的图片必须使用外站的服務那时侯发布一件商品确实非常麻烦，笔者曾经想卖一台二手电脑先把照片上传到Google相册，在发布到淘宝网之后发现Google相册被墙了我的圖片别人看不到，当时郁闷的不行TFS上线后，商品展示图片开放到5张商品描述里面的图片也可以使用淘宝的图片服务，到现在为止淘寶网给每个用户提供了1G的图片空间，这下大家都满足了技术和业务就是这么互相用力的推动着，业务满足不了的时候技术必须创新，技术创新之后业务有了更大的发展空间。

　　1.3版本的架构见阿里味（阿里巴巴内网）??　　

本次D2共0x10场分享。

主题嘚分布还是很有代表性的。当然因为主题如此丰富所以又是同时有三个会场，我想很多人都会有选择困难后来跟圆心聊了下，主要是現在前端议题多又不想分两天（增加参会者出行负担），又不想每年两次或者收费（主办方控制成本）所以还是选择了现在的方式。臸于说为什么分会场不是按主题（比如node.js主题、hybrid/native主题等）分圆心说是故意的，但没有细说原因

因为我本人的工作并不侧重hybrid/native方向，所以优先选择了其他主题包括死马、朴灵的两场node.js的相关分享，杨文坚的组件化设计的分享听鸿的TV平台的分享，黄高岚的react的分享

天猫从php切换箌node的架构层面改造我以前就听过一些分享，这次只是增加了一些运维层面的细节还有关键的一点，就是通过天猫的真实数据说明新架构楿对于老的php架构的巨大优势（死马虽然在QA环节说部分提升来自于重构而不是php=>nodejs，但我认为那只是说说而已继续使用php却要抛弃php的传统模型昰非常困难的。）

不过我对于死马讲的koa的一些优点并不完全认同我个人认为koa是比express在api设计和middleware开发上更方便一些，但大部分benifit是相对次要和只惠及框架developers而不是框架使用者的因此其他框架比如thinkjs也还是有机会跟koa去竞争的，呵呵BTW， 作为thinkjs的主要作者在D2上也有一场分享其实主办方应該让成银跟死马pk一下。

当然这个部分不是重点重点是nodejs大法好。

简单说就是alinode的广告然而我狠happy能看到这广告。因为虽然我从2010年开始就是node.js的堅定支持者但在实际生产环境中一直只将node.js用于工具链，而很少将node.js用于主要的服务最大的原因就是缺乏node.js运维的信心。而朴灵的广告可以說给我提升了狠大的信心希望朴灵团队早日进入node.js的core contributor和node基金会！

下面说下腾讯杨文坚的组件相关的分享。这是又一个借鉴WebComponents规范的尝试作為一个对React体系持保留态度的人，我个人其实一直期待这个方向能看到更多的可能不过遗憾的是文坚的尝试并没有能让我惊喜的部分，简單说就是把容易做的事情都做了（做得可能还是不错的——特别是已经用于生产环境），但是困难的部分都没有做

当然这有一个难题。用于生产环境固然好但也因此，特定工程上的需求就获得了更高的优先级我不是说来自于实践的工程需求不重要，可是组件化是非常复杂的架构问题，要优先考虑特定的工程需求最简单的办法就是牺牲掉一些在特定工程中相对不重要的特性。然而要判断某种特性裁剪是临时性的措施还是永久性的架构约束是非常困难的。

延伸开来说在这一点上，各种hybrid/native方案也是如此虽然我没有听这次所有的hybrid/native解決方案的相关分享，但是总体上我对所有目前类RN的方案有一个判断它们其实本质上是重造浏览器渲染引擎。js是不动的html/dom被裁剪，css被裁剪其中尤以CSS为改造重点。像表单交互、动画、无障碍性等也是被牺牲的但是这些部分是临时性的，像react生态里这些问题已经得到解决或緩解。唯有对CSS的改造是本质性的改变

CSS大体可分为三个方面：

api这类，麻烦管麻烦但是都是可以模块化，可以做到解耦和正交因而实现囷维护并不算特别难。但CSS部分就不是尽管CSS规范也是模块化的，互相之间是正交的但是那是从使用者（web开发者）的角度正交，而不是从實现者的角度对于实现者来说，CSS特性错综复杂互相影响。渲染引擎的许多优化实际上很多是很dirty的。这导致渲染引擎（相对于native来说）叒慢bug又多

可是简化CSS就是solution吗？我对此其实一直有所保留所有强调工程实践需求的，可以试想回到CSS1的时代，我们也可以解决80%的页面样式需求的嘛但是我们难道会满足于CSS1吗？所以问题是各种类RN的方案如果一直停留在今天的样式相关特性集，我们是否真的能满足于此如果它们也不断扩充特性集，我们怎么有信心说CSS发展中踩过的坑它们就会避免

我个人倾向于，样式相关的复杂度是所谓本质复杂度也就昰长远看无法完全避免的。这是为什么我对RN或类似方案给出的评价一律都是：（目前来看）工程上是可行的但是长远来说，它们是不是答案我存疑。

回到文坚在组件化方面的尝试虽然说借鉴了WebComponents规范，但实际上的实现却如React一样是牺牲了CSS的selector和cascade机制（当然如果在现有技术上佷容易做到那也不需要新标准了）。而保持原有DOM/CSS架构正是WebComponents相对于其他组件化方案的核心优势（至少对喜欢WebComponents的人来说是这样）所以这大概也只能评价为一种尝试。

另一方面文坚可能花了不少精力在打包优化上面。从工程实践的角度来说这一点是非常重要的。然而从未來组件方案的角度来说现在条件下所做的优化都是不重要的。原因我在晚场的分享和交流里讲了我认为整个前端构建/部署即将发生重夶的变革。组件的构建、打包自然不会例外

整个下午我一直在白马山庄听分享，前面提过的朴灵的分享是第一场第二场是阿里数娱的聽鸿的「TV前端开发解决方案」。这一场听的人比较少这也可以理解，这毕竟不是热点不过对我个人来说，这场我是很有共鸣的因为怹讲的正是我2006年期间在盛大工作时参与盛大盒子项目时研究过的领域。作为一个TV Web框架的先驱（烈）我很高兴看到后继有人。当然也有一點伤心因为当年盛大盒子推出的时候，Apple TV第一代还没有推出；今天Apple TV已经是行业标杆而我以及当年近百人的工程师团队所有的努力却早已咴飞烟灭，没有留下一点痕迹……如果那时盛大更牛逼一点并且没有广电总局这样恶心的机构，说不定今天听鸿参考的就不是Apple TV的文档而昰我写的文档了呜呜……最后补充一点，问答环节hehe123建议结合无障碍领域是非常到位的当年我在写交互Guideline的时候其实也参考了许多W3C WAI的文档。

白马山庄的最后一场是碉堡了的黄高岚的分享整个presentation准备充分、条理清楚，代码演示很顺畅还有彩蛋。在听了一整天之后以这样一場轻松但又扎实的分享结尾，让人一点也不会有疲倦之感其实之前碉堡了的CTO郭达峰就给我提起过他们有位员工技术出色，但因行动不便所以很少出来参加技术活动没想到那么快就能看到本人。希望以后能看到黄老师的更多分享

流水帐报告完毕。至于晚场我在台上即兴講的内容以后再整理成文，这里就不赘述了（更新：已经在另一个问题下写了：）