淘宝构建开放平台的技术历程(3)

　　但这担子放下了，那担子又挑上了，在上面谈到去年后台应用不稳定导致平台整体不稳定的问题在轻量化以后出现的频率和次数更多了，因为发布和维护都落到了后台部门，此时对于各个系统的把控就更弱了，这晚上睡觉不安稳，KPI中的稳定性指标基本就没法定了。唯一能够彻底解决问题的办法就是http服务异步化+ 事件驱动+虚拟隔离线程池。那年年中的时候对Jetty7做了一次压测，发现Continuations的效果已经可以上正式环境了，于是开始在 Jetty7的基础上做Http服务异步化+事件驱动的封装，同时也实现了一个虚拟隔离线程池做配合。具体设计细节这里就不多说了，参看blog，简单描述原理就是：1.将前端容器线程和业务处理隔离。(类似NIO和BIO的设计差异)2.业务处理如果依赖于外部系统则采用事件驱动的方式来减少线程等待，同时提高线程占用资源的利用率。(这点上来说理想和现实还是有很多细节差异的，在实现的时候必须根据依赖系统消耗时间占总时间的比例看是否需要事件驱动，事件驱动带来的切换消耗是比较大的)3.通过一个大的线程池虚拟设置不同业务可消耗的最大资源数，来充分的共享资源在异常情况下限制业务占用过多资源(任务处理开始排队而非无度的占用资源)。这个组件上线以后，没过几天就发生了一个典型的案例，一个业务2点开始响应时间从10ms上升到了40ms，然后继续上升到200ms，当时给这个业务模拟设置最大的线程资源数是20个，就发现那时候由于RT时间提升，线程资源释放的慢，20个慢慢的被消耗到顶了，此时这个业务的队列开始从0到100到200到…(当然防止内存过多占用，会丢弃超过队列长度的业务处理)，而其他业务还是正常的使用着资源，平台平稳，到了4点多，业务方收到告警修复以后，RT时间下降到了10ms，队列中的请求数量开始减少，最后队列清空，线程资源占用下降到正常水平。从此以后震子同学开心的和我说：开放平台稳定性的KPI可以随便大胆的写几个9了。(技术敢做敢想，才能高枕无忧)

　　11年：市场化。这一年到年底，平台开放淘宝服务758个，每天调用量19亿，这一年SNS热潮消退，游戏逐渐淡出，卖家市场依旧生意火爆(很多TP的年收益让人咂舌)，营销工具崭露头角成为开发者新宠，淘宝客成为了开放新宠(这一年返利网和团购一样火，只是前者收钱，后者烧钱)。

　　就在开放平台开发者前景一片大好的时候，出现了一个让开放转变和收缩的导火索，一家做营销工具的公司“团购宝”，每天凌晨都会通过接口同步客户设置的一些优惠商品信息到淘宝网，结果那天凌晨，微博上突然很多人说某些店都是一块钱的便宜货，要知道这种事情在微博盛行的时代，传播速度之快，影响之大，当即很多卖家商品都被1块钱拍下。最后发现是线下的商品价格不知道怎么全被修改成1块钱，然后凌晨一同步，就导致出现了上面的一幕。从那时候开始，开放平台的 KPI中增加了一个重中之重：安全，包括后面的很多技术产品都是围绕安全展开。此时第一个被波及提升能力的系统就是流式分析集群，20分钟一轮的数据分析要求压缩到3分钟，同时数据量已经从8亿每天增长到了19亿每天，化了2个月时间断断续续的优化集群结构设计和单机处理能力，里面经历的内容有一天我翻 Hadoop的优化过程时看到了相似的场景，具体就不在这里赘述，详细内容依然去挖blog。简单来说：1.充分利用多核能力用计算换内存。2.磁盘换内存，用并行设计来保证整体业务时间消耗不变甚至减少。3. Slave shuffle来减少Mater的合并压力。4.数据压缩减少数据传输消耗和内存占用。…

　　另一方面，由于10年对于jetty7的充分理解和封装，此时看到了又一个新技术的契机，10年的时候去美国参加Javaone，当时看到有老外用 Jetty7的特性来实现Comet功能，Comet原先主要用于CS结构的应用搬到互联网上，因为不能用TCP的长连接，所以不得不用Http的长连接来替代原来的模式，同时国外开放平台也关注很多新型的API设计，其中就有Twitter的Streaming api，这种通过http长连接方式推送消息到外部isv的模式引起了我们的注意。因此我们决定将Jetty7上的封装近一步升级，支持Comet长连接方式，后端通过事件驱动的模式主动推送内部消息给外部，避免外部轮询业务接口。这个设计的最重要点就是如何用最有效最少的线程来守护多个长连接，支持到后端事件驱动的数据下行，如果给每一个长连接支持一个数据推送守护线程，自然即时性最高，但代价就是众多空置连接的守护线程消耗，预知细节挖blog。这种模式刚出来的时候，从上到下都是质疑声，觉得太不符合常规做法了，常规做法就是pull，认为开发和无法接受，认为稳定性一定不靠谱。经过2011年的双十一，当天几个“尝鲜”的开发者一台PC就支持几百万的订单高速处理，就让很多人明白了，技术要敢想，代码要敢写，细节要敢专，没什么不可能。也就从这以后，多样化服务TQL，Schedule API，ATS从开放平台的土壤上都长了出来，为更多的场景，更多的终端，提供了各种解决方案和创新实现。

　　12年：垂直化。这一年到现在，平台开放淘宝服务900多个，每天调用量25亿，这一年淘宝客由于公司方向转变热潮消退，无线乘势而起，新业务(机彩票，酒店，理财等)，P4P，数据类服务都开始运营API，开放平台开发者的客户群体也从C店卖家增加到了B的品牌商，渠道商等。

　　这是一个业务多变的一年，这也是淘宝内部对开放平台认可的新阶段。第一个阶段是放任不管，开放平台部门自己要开什么，封装什么。第二阶段是开放什么业务方负责支持开放，但开放后的结果概不了解，也无所谓了解。第三阶段就是业务主动要开放，开放后开始运营服务，培养isv市场，带动业务的正向发展。

　　这一年由于业务量的增长以及分析需求到用户纬度，因此在11年底启动了流式分析集群重构升级的项目，将新的分析集群项目命名为beatles，希望他能够象甲壳虫一样，小虫吃树叶，再多都吃的下。11年底到12年初，用了近2个半月的时间做了一次完整的重构，将那么多年的补丁经验和老代码重新设计和实现，并且将Mater根据业务可垂直切分，最终解决Master归并压力的问题，当然期间的技术优化点也不少，因为我们的目标从3分钟压缩到了1分钟，而我们的数据量翻番，统计纬度细化到了用户纬度。(意味着结果也会很大，不靠文件做中转如何来实现需要更多的分拆和协同设计)

　　这一年起了两个比较创新的项目：JS SDK和无线SDK(IOS，安卓)，这两个SDK的出现一定程度上由业务和安全两方面决定。首先11年年底启动了社区电子商务化的项目，也就是现在所说的轻电商(XTao)项目，将更多的网站和淘宝衔接起来，此时网站间的融合就要求更轻便和简易，最成功的案例就是Facebook，于是年初的时候，拿这 FB的JS SDK一阵看，就开始动手写了，期间很高兴拉了UED同学入伙，这才使得这个JS SDK变的更加靠谱，更加专业。(前端这活谁都可以玩，但要玩好最终还是要对那一系列苦逼的浏览器兼容有所深入理解，现在想想自己当时还是有点无知者无谓的)。同时有了JS SDK，买家类的服务安全性有所保证，因为原先的REST调用在授权以后是无法知道是否是用户发起的还是服务器发起的，而JS SDK一定程度上还要校验Cookie的有效性，可以部分的保证用户的在场知情。而下半年的无线SDK，就是间或的苦读1个月的各种文档，然后就开始动手玩了，由于对Java语言，动态语言，脚本语言都有比较多的使用，因此Obj-c上手并不是那么困难，同时没有涉及到过多的MVC的内容，做SDK基础层的东西还是比较得心应手，就这样IOS的无线SDK版本就出来了，此时在开放平台的技术团队内部正在执行一个叫做Hack project的活动，其中一个自主项目就是安卓的SDK，因此一个月后，安卓的SDK顺利的诞生了。这两个无线SDK所担负的职责就是把控无线安全问题，不仅淘宝，业界其实很多公司都还没理解无线开放的风险到底有多大，OAuth2基本就无法保证无线的用户安全，因此如何在SDK和服务端融入更高级别的安全设计，成为了无线SDK诞生的第一个重要需求。

原文转自：http://www.ltesting.net