岑文初谈淘宝开放平台技术发展历程

淘宝架构师岑文初（放翁）最近在博客中详细介绍了淘宝开放平台的技术发展历程，随着数据的天量增长，开放平台的架构、实现都在不断演进，其中的技术积累值得业界关注。

岑文初在文章开头回忆了阿里软件的创业期（2006底），初衷是为中小企业提供一个工作平台，因为卖家的需求是长尾的，参考Saleforce的模式，阿里想做一个支持二次开发的平台。不过经过一年多的建设，团队发现开发者非常难利用平台做二次开发，只有内部团队构建了三个不同的CRM系统。随着王文彬的参与，团队决定尝试一种新的技术模式——开放平台。在此背景下，岑文初考照雅虎的开放模式，在两周时间内做出了开放平台的一个模型，从而开启了以后的开放之路。

07年：萌芽

文初将2007年概括为萌芽期，SOA架构的企业思想和开放平台的互联网本质使得一线开发者和平台框架实现者出现非常多的矛盾：

SOA盛行的年代，内部架构服务化成为开放的第一步，内部服务不做好隔离，开放就意味着风险不可控。支付宝今天的服务框架SOFA（类ESB），淘宝的HSF（OSGI），阿里软件的ASF（SCA）都是那个年代的产物，但服务化带来的痛却是一样的，不论是OSGI或者SCA之类的服务框架，本身服务化规约设计都类似，但难题也都摆在每个架构师和开发者面前：服务单元Bundle的粒度控制，服务之间依赖管理，性能与规范的冲突，调试与隔离的平衡。这些都使得一线开发者和平台框架实现者出现非常多的矛盾，而这个过程最后能活下来的框架，最后都是摒弃掉了很多企业级的设计思路，因为SOA架构从企业级产品演变而来，而服务化后的内部平台要面对的开放平台天生就是互联网的产物。

08年：雏形

到这年年底，平台开放淘宝服务30个，每天调用量2000万，这一年的开放平台的开发者面向的客户主要是阿里巴巴上的中小企业和淘宝C店卖家。

文初指出，开放平台建设初期要解决的就是三个问题：

1. 服务路由。（外部可以获取内部信息）
2. 服务接口标准化。（统一方式的获得各种标准化信息）
3. 授权。（外部合法的获取内部信息）。

接着，他详细介绍了三种问题的解决方案：

服务路由其实就是写一个高效的HttpAgent，服务接口标准化就是对象文本化（Json，xml）......淘宝初期采用的是自有协议，因为OAuth2以前的逻辑复杂且使用不方便，直到2011年才开始支持OAuth2，同时做了部分的安全增强。授权解决了开放最大的一个问题：用户安全的对应用访问其数据受信。用户从此不用赤裸裸的将用户名密码交给一个应用软件，应用也可以在允许的范围内（操作，数据，授权时长）充分利用用户授权来玩转创意。

同时，文初还透漏早在2008年时，淘宝开放平台就开始探索实施Memcached和Hadoop。

09年：产品化

淘宝开放平台从30个API猛增到了100个API， 文初指出性能成为了瓶颈：

此时技术上的挑战又聚焦到了性能上，一次API call的业务消耗平均在30－40ms，开放平台当时的平台处理消耗平均在10ms左右。我们做了数据打点和分析，发现最大的消耗在于互联网数据接收，同时大量的图片数据上行，更是加大了平台处理时间，同时从访问日志分析中可以看到很多无效的请求也占用了非常多的处理时间，这也意味着无效请求和有效请求一样在消耗着有限的容器线程资源。于是我们开始尝试自己封装字节流解析模块，按需解析上行数据，一来提升数据分析的性能（并行业务和数据增量分析操作），二来可以用最小代价处理异常请求（当发现不满足业务规范，则立刻丢弃后续所有数据），这块实现被叫做LazyParser，主要的实现重点就是最小化数据缓存来并行业务和数据解析操作，上线后效果不错，整体处理平均处理时间从10ms降低到了4ms。

除此之外，文初还讲述了Hadoop的MR问题以及解决过程和网络软负载切割。

10年：平台化

此时，平台开放淘宝服务300多个，每天调用量8亿，在这样一个背景下，淘宝技术团队又遇到了新的问题，文初谈到了流式分析系统的演变：

8个亿的访问量下再用Mysql做流式分析已经不靠谱了，分析时间要求也从一个小时提升到了20分钟，此时经过快1年半的Hadoop使用和学习，再加上对分布式系统的了解，正式开始写第一版的流式分析系统，MR的抽象依旧保留，而底层的数据计算分析改用其他方式......总的来说就是数据来源变了，数据不通过磁盘文件来做节点计算交互（只在内存使用一次就丢掉了），简化任务调度，简化数据归并。这样第一版本的流式分析出来了，当然后面这些设计遇到的挑战让这个项目不断在演进，演进的各种优化几年后发现都在hadoop或者Hive之类的设计中有类似的做法这个系统3台虚拟机抗住了8亿的日志即时分析，Mysql日志分析就此结束。

11年：市场化

在这一年，平台开放淘宝服务758个，每天调用量19亿。文初提到了开放平台的KPI中增加了一个重中之重——安全：

......最后发现是线下的商品价格不知道怎么全被修改成1块钱，然后凌晨一同步，就导致出现了上面的一幕。开放平台的KPI中增加了一个重中之重：安全，包括后面的很多技术产品都是围绕安全展开。此时第一个被波及提升能力的系统就是流式分析集群，20分钟一轮的数据分析要求压缩到3分钟，同时数据量已经从8亿每天增长到了19亿每天，化了2个月时间断断续续的优化集群结构设计和单机处理能力，里面经历的内容有一天我翻Hadoop的优化过程时看到了相似的场景。

简单来说：1.充分利用多核能力用计算换内存。2.磁盘换内存，用并行设计来保证整体业务时间消耗不变甚至减少。3. Slave shuffle来减少Mater的合并压力。4.数据压缩减少数据传输消耗和内存占用。

12年：垂直化

到现在，平台开放淘宝服务900多个，每天调用量25亿。文初提到了两个比较创新的项目——JS SDK和无线SDK（IOS，安卓）：

.....最成功的案例就是Facebook，于是年初的时候，拿这FB的JS SDK一阵看，就开始动手写了，期间很高兴拉了UED同学入伙，这才使得这个JS SDK变的更加靠谱，更加专业......同时有了JS SDK，买家类的服务安全性有所保证，因为原先的REST调用在授权以后是无法知道是否是用户发起的还是服务器发起的，而JS SDK一定程度上还要校验Cookie的有效性，可以部分的保证用户的在场知情。

而下半年的无线SDK，就是间或的苦读1个月的各种文档，然后就开始动手玩了.......此时在开放平台的技术团队内部正在执行一个叫做Hack project的活动，其中一个自主项目就是安卓的SDK，因此一个月后，安卓的SDK顺利的诞生了。这两个无线SDK所担负的职责就是把控无线安全问题，不仅淘宝，业界其实很多公司都还没理解无线开放的风险到底有多大，OAuth2基本就无法保证无线的用户安全，因此如何在SDK和服务端融入更高级别的安全设计，成为了无线SDK诞生的第一个重要需求.....

想要完整了解淘宝开放平台技术发展历程的读者可以查看文初的博客全文。