51CTO年终策划《开放平台，你的选择》
一、什么是淘宝开放平台
淘宝开放平台（Taobao Open Platform）是基于淘宝各类电子商务业务的开放平台，提供外部合作伙伴参与服务淘宝用户的各类原材料，例如API、账号体系、数据安全等。她是大淘宝电子商务基础服务的重要开放途径，将推动各行各业定制、创新、进化，并最终促成新商业文明生态圈的建立。我们的使命是把淘宝网的商品、用户、交易、物流等一系列电子商务基础服务，像水、电、煤一样输送给有需要的商家、开发者、社区媒体和各行各业。
二、平台特点
业务母体强大、商机无限：
淘宝开放平台所依托的母体淘宝网，拥有注册用户数以亿级的买家和上百万卖家，每日近15亿的交易额，淘宝会员需求的多样性和淘宝业务需求的多样性为各类合作伙伴提供了大量的商业机会。
开放规模大、程度深、限制少：
淘宝开放平台为外部合作伙伴提供了极大的商业想象空间——截至2011年6月，对外开放的 API近300个，涵盖了淘宝核心交易和各项垂直业务的主要流程，API日均调用量超过10亿次/天。无论是从业务开放的广度和深度，淘宝开放平台都是国内开放业务规模最大的开放平台。同时，淘宝开放平台形式自由——不限语言、不限平台（支持浏览器、桌面）、不限使用场所（除了淘宝自身网站外，鼓励和支持外部所有网站使用淘宝开放平台服务）。
盈利模式清晰：
淘宝开放平台为各类应用提供了清晰的盈利模式，如应用销售分成、淘宝客成交抽佣、淘宝客工具分成、P4P广告分成等，并且还会根据合作伙伴反馈，不断提供更多更灵活的盈利模式，全力支持各合作伙伴不断地成长和壮大。
合作形式丰富：
淘宝开放平台是基于电子商务业务的综合开放平台，除了基本的流量平台特点之外，还有丰富的电子商务业务。因此，将业务开放到尽可能多的领域是淘宝开放平台的宗旨。目前，已经为合作伙伴提供了10类以上的合作形式，包括商家系统、卖家应用、买家应用、淘宝客应用、无线应用等。
三、到 TOP 能做什么？
《大淘宝宣言》指出，合作伙伴是新商业文明中极其重要的新兴力量，由各类合作伙伴组成的“大淘宝”生态系统也是新商业文明的主要结构与功能单位。合作伙伴通过与经营者、消费者及交易平台的紧密合作，使经营者的服务更高效、更专业、更经济，使消费者的购物更便捷、更愉悦、更完美。从淘宝开放平台的特点来看，能支持的业务方向可以分成卖家服务和买家服务两类，而具体实现的功能和服务类型非常多，这些只局限于各自的想象力。
无论您是第三方开发者（ISV）、传统软件厂商、行业型网站或者大商家，都能基于淘宝开放平台找到适合自己的业务方向。
卖家服务：
我们提供的丰富API涵盖淘宝各个核心业务流程，基于这些内容可以为卖家提供各类应用，解决店铺管理、营销推广、数据分析等方面的问题。淘宝开放平台还基于商家所需的电子商务后台系统，提供解决方案。如果您是富有企业信息系统开发经验的传统软件厂商，您可以基于淘宝开放平台为商家提供包括但不限于BI、ERP、DRP、CRM、SCM 等。淘宝开放平台还为各种应用提供了清晰的盈利模式。通过服务市场的应用销售分成、软件直接销售收入等获得回报。
买家服务：
淘宝数亿消费者，越来越需要各种个性化、专业化的服务，帮助他们方便地购物，以及解决各类生活服务需求。从导购、健康、娱乐、兴趣、交友等方方面面，构建自由的买家应用。各个专业的类目，也吸引着各行业的专业团队深入合作，为消费者打造最佳体验，而通过导购交易成交抽佣，已经成为一种有效的盈利模式。
#p#
淘宝开放平台（TaoBao Open Platform，简称TOP）的整个架构体系是组件化体系架构，可以是很少的几个基础组件构成的Skeleton，也可以是融入了商业想象的Amazing Architecture。这里就通过对于这些组件的罗列，描述出在TOP这个大体系中，各个组件所处的地位及作用。TOP的“兵器谱”是在现阶段商业需求及平台非业务性需求指导下形成的，未来TOP将继续发展，“兵器谱”也会不断演进。
下图是整个TOP当前的一个组件结构图：
图中，红色虚线就是TOP的Skeleton。TOP当前从业务模块功能角度来划分，可以分成三个层次：基础平台组件层，基础业务组件层，普通业务组件层。基础平台组件层，倾向于平台级别功能满足及对平台稳定性，可用性的支持。基础业务组件层，是介于平台服务于普通业务服务之间的组件，部分利用了平台基础组件层的组件，来抽象出一层公用业务服务组件，为业务组件提供通用的基础支持。
安全组件
安全组件主要从四个角色去考虑整体的安全策略及具体的实施方案，这四个角色是：用户，应用，平台，服务。
平台本身的安全主要是基于在大并发和大流量的情况下，保证平台自身稳定性和可用性，同时也要兼顾在平台开放的服务不相互干扰和影响。因此采取服务分流隔离机制，通过虚拟配置及软负载方式将服务请求动态分流和隔离，保证了服务之间相互的独立性，同时也充分利用TOP的能力。频率控制及流量控制除了保护TOP自身不受到攻击，也为后端服务提供者作了天然的一个保护屏障，保证服务请求压力可以在TOP上可控，防止流量直接压倒服务提供者。用户隐私安全在淘宝尤为重要，用户信息的安全性也在淘宝开放的过程中被放到了首位。在开放平台设计中，除了采用普通开放平台的认证模式以外（OAuth类似流程），还在服务调用过程中通过区分应用角色来限制对于用户信息的获取和使用。同时针对不同的应用类型（插件，Web应用，客户端应用，手机应用）都有各自不同的用户授权方式，保证用户的知情权。App的安全其实也是为了保证对服务的请求及对用户信息的获取不被不法的应用信息盗取者所利用，根据应用角色及自己对于安全的需求，采取多种方式或者组合的方式来实现App信息的保密性，保护App自身安全，也保证了平台服务的数据安全。服务安全指的是对于服务来说分成了几个层级，不同层级的服务对于安全级别的要求不同（不需要交验应用身份，需要交验应用身份，需要用户授权，用户可选择授权等），在应用访问服务的时候，就会需要根据服务级别的不同采用不同的访问控制流程。根据上述的四个角色对于安全的考虑，通过应用角色的定义，服务虚拟组的编排，黑名单（频率控制及流量控制），多模式用户令牌等手段，形成了多种模式的安全控制流程。
服务路由组件
服务路由是开放平台最基本的功能，如果排除商业因素，那么对于TOP最基本上来看可以看作一个服务路由器，服务路由主要的功能如下图展示：
服务路由组件需要支持多服务类型的服务接入，不同服务类型主要表现在两个维度：1.服务对外的展现方式（REST OR RPC），这两种形态的服务没有任何好坏之分，只是根据各自的系统形态来选择采用哪一种模式来对外暴露，RPC比较符合过去应用开放的风格，REST比较适合面向资源的架构。同时对于同步，异步，通知，大数据量的服务，都会有不同的接入方式和调用方式支持，满足各种业务场景的需求。多通信协议支持，表示服务请求到了TOP以后，TOP负责将请求继续发送给服务提供者，不论服务提供者采用什么方式和TOP交互，最终将得到的结果返回给客户，服务调用者将会对后端的服务请求过程透明，同时可以使TOP很容易接入一些传统遗留系统的服务，或者是对通信有特殊需求的服务。特性支持主要是会有对内容的一些特殊处理，例如压缩，在CS或者手机应用交互过程中，就会需要对数据量有所压缩，满足业务需求。
监控告警组件
下图是监控告警组件的基本功能图
监控和告警模块在TOP中起到越来越重要的作用，访问量逐日膨胀，运行期TOP是一个黑盒，无法知晓当前系统实际的健康状况，当出现问题以后比较难以定位。服务监控主要是服务质量（响应时间），短时间段内的服务请求峰值，和阶段性的趋势。系统和平台主要是对底层基础组件的监控，同时及时地通知TOP负责人处理线上即将要发生的事情。对于应用的监控通常就是从客户端和服务端两面对于应用当前的情况作汇总分析。当监控发现异常以后，就交由告警部分按照一定的发送策略给相关的负责人，在第一时间将问题解决。
日志组件
日志组件和其他系统的日志组件基本没有太大的区别，只是在对于海量数据写出和获取的方法做了优化（例如异步分页批量输出等）。日志组件主要负责，打点，收集，分析，数据库记录，归档。
协议转换组件
这里谈到的协议转换指的是对于请求和返回的协议，TOP可以做适配，来满足服务调用者和服务发布者之间在服务协议失配的情况下还是能够正常通信。当前支持JSON,XML,Atom,二进制协议之间的转换，当然转换描述文档将会配置在TOP。同时返回的数据内容，也可以通过协议转换，返回给客户端常规的xml或者json类型的数据。
服务流程化组件
服务流程化指的是将离散的服务通过流程描述文档能够虚拟的串联成为一个新的服务，这样更加适合调用者使用，同时将服务的一些内部逻辑隐藏起来。这很类似于SOA中的服务编排，同时也可以参看Yahoo的Pipe，那就是一种典型的服务串联，同时还提供了方便的界面直接交由用户通过手动拖拉的方式来使用服务串联。
服务流程化最大的特点就是将不同类型的服务能够根据业务场景的需求组合成简单的流程性服务，极大降低了服务开发者由于对服务流程不熟悉而犯错的几率，同时也为服务开发者提高了开发效率。
计费组件
当前计费模型主要是按流量收费和插件分成两种模式，因此计费组件还比较简单，当前就是基于日志做分析，未来会考虑在流量上的各种特殊模式（打包，优惠等等）。
容器组件（TBML）
产生原因：
- 数据隐私性
- 开发便利性
- 业务升级透明化
- 监控全局化
- 开发标准化
作用：
- 数据操作可控，保护终端用户隐私（结合cookie和标签，控制ISV业务数据操作尺度，提高数据安全性）
- 提供标准业务流程标签，简化开发者对于业务流程理解过程。
- 标签化接口方式，完成数据获取和页面渲染，后台业务升级对ISV透明化。
- 标签获取客户端信息，将监控扩展到整个业务请求过程。制定行业化标签库，形成统一开发标准。
TBML首先需要根据业务需求及场景定义出对应的标签库，也就是制定Taobao的标签标准，最简单的获取用户信息标签，到最复杂的业务操作流程标签都会成为标签库中的一部分。同时在服务端需要有解释引擎来翻译标签，解释引擎一方面需要去了解标签内容和含义，同时需要请求后台多个API，串联成为流程化的服务，从应用的输入，得到最后的输出，当然期间也需要处理异常的情况。最后还需要关注的就是安全控制，在交验标签传递来的数据时，需要对数据作完整性及合法性的交验，防止通过标签数据的特殊性攻击后台服务接口。
TBQL组件
TBQL其实是一种服务调用的方式，也是通过一种程序员和开发者习惯的方式，将对资源的REST请求转换成一种类似QL的请求，对于面向资源性的架构体系来说是十分有利的。同时对于API来说，使用者会更加自然的去采用连接和过滤得方式得到需要的数据。
QL解释引擎负责对于TBQL的翻译工作，数据存储的MetaData保存在数据库中，可以指导QL解释引擎翻译。需要支持不同数据来源的连接和过滤，在获得结果以后需要做格式转换返回给服务调用者（通常就是xml）。与容器一样，需要着重考虑安全性问题，对于传统的SQL注入就是典型攻击QL系统的案例，需要谨慎处理解析中对于字符的翻译工作。在流程中出现异常，需要制定策略来判断是否直接返回错误还是支持部分容错。
TOPID组件
TOPID组件有点类似于Facebook的Connect，需要在淘宝和淘宝的合作开发者之间建立起双向的用户互通的标准和流程，同时也为服务互通打好基础，毕竟业务的互动需要基于可以互通的用户体系。
