淘宝开放平台架构组件体系初探

淘宝开放平台（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，需要在淘宝和淘宝的合作开发者之间建立起双向的用户互通的标准和流程，同时也为服务互通打好基础，毕竟业务的互动需要基于可以互通的用户体系。

总结

以上仅仅只是简单的罗列了一下 TOP 技术体系架构中的一些组件化的内容，同时在这些组件的背后有着更多的基础性项目的支持，例如统一配置中心对于系统动态扩容的支持，分布式缓存对于监控告警的支持，分布式文件系统对于海量小文件保存和获取的支持等等。同时以上每一个模块都有各自特殊的定制和优化，例如路由模块就需要有 Lazy 的服务参数解析模式来提高处理性能，安全体系中需要有动态密钥机制来保证高安全性等等。

TOP 从萌芽走向成熟，不论从技术架构还是商业规划都处于不断摸索和改进的过程，当前的技术体系仅仅是现阶段的一个需求缩影，未来在市场不断成熟，开发者不断介入和反馈的情况下，TOP 会走得更快更远，TOP 的“兵器谱”会更加丰富，更加出彩。