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

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

岑文初在文章开头回忆了阿里软件的创业期（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 诞生的第一个重要需求…

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