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

　　注：文中所有的技术点都可以在http://blog.csdn.net/cenwenchu79 找到详细的文章，同时本文主要介绍开放平台技术发展历程，产品和业务内容不涵盖在此，因此受众群体主要是技术人员。

　　2006年底，阿里巴巴提出了workat alibaba的战略，20来号人就被拉到湖畔花园马云的公寓里面开始一个叫阿里软件的公司创业。当时对于Work at alibaba有个朦朦胧胧的感觉，就是要为中小企业提供一个工作平台，但是工作平台又需要是一个开放的平台，因为卖家的需求是长尾的，当时火热的 salesforce给了阿里人一些启示，那就是做一个支持二次开发的工作平台，半开放式的来满足各种卖家的长尾管理需求。此时，软件市场上就开始培养起来最早的一批TP(淘宝开放合作伙伴)，迄今为止很多非常成功的TP就是从那个时候开始进入淘宝卖家市场。

　　但经过一年的平台建设，发现开发者非常难利用平台做二次开发，只有阿里软件公司内部团队构建了三个不同的CRM软件。这时候淘宝来了一个业界的技术牛人：王文彬(花名：菲青)，这位淘宝新晋的首席架构师找到阿里软件的平台架构团队，谈到了当时业界还非常新颖的一种技术平台：开放平台，由于阿里软件已经在做类似的开放工作，希望能够合作的方式来试水开放平台。当时双方都是一种尝试的态度，因此最后敲定，投入一个人，两周时间，看是否能够出原型，如果可以，那么就继续做，如果出不了原型，那么就此结束。两周时间，负责阿里软件的架构师放翁，参看着美国雅虎的开放模式，吭哧吭哧的就搞出了开放平台第一个雏形，没想到就这样开启了5年的开放之路。后面会根据时间轴来说一下开放平台的产品和技术的变革，每一年会发生很多事情，但是调出的一点一滴是当年最有感触的。

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

　　08年：雏形。这一年到年底，平台开放淘宝服务30个，每天调用量2000w，这一年的开放平台的开发者面向的客户主要是阿里巴巴上的中小企业和淘宝C店卖家。开放平台建设初期要解决的就是三个问题：1.服务路由。(外部可以获取内部信息)2.服务接口标准化。(统一方式的获得各种标准化信息)3.授权。(外部合法的获取内部信息)。服务路由其实就是写一个高效的HttpAgent，服务接口标准化就是对象文本化(Json，xml)。今天在各大开放平台广为使用的 OAuth协议，当前处于0.6版本，没有任何实际的互联网开放平台使用，直到Google 08年底慢慢对外推广开放的时候，OAuth被封装到Google的Open SDK中，才使得很多中小互联网公司使用这种看似及其复杂的两阶段授权交互模式。淘宝初期采用的是自有协议，因为OAuth2以前的逻辑复杂且使用不方便，直到2011年才开始支持OAuth2，同时做了部分的安全增强。授权解决了开放最大的一个问题：用户安全的对应用访问其数据受信。用户从此不用赤裸裸的将用户名密码交给一个应用软件，应用也可以在允许的范围内(操作，数据，授权时长)充分利用用户授权来玩转创意。

　　有了上面的三板斧(路由，数据规范，授权)，开放平台正式开门迎客了，没有对外做任何的推广，数据就蹭蹭蹭的走到了第一个1000w日均调用，此时两个互联网的新兴技术开始在开放平台中尝试，Memcached和Hadoop。今天看来这两个技术已经被大规模使用，08年时却是在吃螃蟹，2台虚拟机要抗 1000w的路由，势必要求对于路由和校验信息能够有足够强的缓存，Memcached无疑是最好的选择，但当时号称分布式缓存的Memcached其实是集中式缓存的一种，正真的分布式缓存都还在纠结于一致性和效率的问题(2,3阶段提交)。此时需要有一种方式能够保证效率(可扩展)和稳定性，于是我们封装了Memcached客户端，提升当时BIO的Java客户端的性能，同时引入了客户端负载均衡和容灾的设计，这种设计已经被应用在现在很多大型分布式系统里面。另一方面每天上千万的访问也让技术和产品对访问的行为有很强的分析需求，此时Hadoop在雅虎的充分利用引起了我们的重视(当时的雅虎技术创新一直都是业界的领头人)，通过仅有的两台机器和一堆技术文档，摸索着我们搭建了公司内部的第一个Hadoop集群，而所写的hadoop入门实践也成为当时Hadoop入门的基础文档，对于每天2000w的日志分析需求来说，hadoop用的是游刃有余，但随着业务的不断发展，hadoop离线分析所带来的问题也凸显出来，MR程序面对灵活多变的分析需求显得不易维护且效率低下(数据反复读取分析)，于是我们也开始思考怎么来改进一下这个新玩意儿。

　　09年：产品化。这一年到年底，平台开放淘宝服务100多个，每天调用量4000w，这一年是开放平台的开发者面对的主要是淘宝C店卖家，卖家工具成为服务市场的主流。这一年是变化的一年，阿里软件年中的分拆使得开放平台的归属有些微妙，一种情况是留在阿里云，作为集团的基础设施，另一种情况就是跟着主要的业务需求方淘宝走，最后我们还是说服了博士，结束了阿里软件的老平台，淘宝正式开始自己的开放之路。来到了淘宝，业务开放迅猛增长，从30个API猛增到了100个 API，没有对外做任何业务推广，平台调用量到了年底翻番。此时技术上的挑战又聚焦到了性能上，一次API call的业务消耗平均在30-40ms，开放平台当时的平台处理消耗平均在10ms左右。我们做了数据打点和分析，发现最大的消耗在于互联网数据接收，同时大量的图片数据上行，更是加大了平台处理时间，同时从访问日志分析中可以看到很多无效的请求也占用了非常多的处理时间，这也意味着无效请求和有效请求一样在消耗着有限的容器线程资源。于是我们开始尝试自己封装字节流解析模块，按需解析上行数据，一来提升数据分析的性能(并行业务和数据增量分析操作)，二来可以用最小代价处理异常请求(当发现不满足业务规范，则立刻丢弃后续所有数据)，这块实现被叫做LazyParser，主要的实现重点就是最小化数据缓存来并行业务和数据解析操作，上线后效果不错，整体处理平均处理时间从10ms降低到了4ms。(包含了异常处理的优化和解析性能的提升)

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