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

作者 岑文初 发布于 2009年9月29日

zz from: http://www.infoq.com/cn/news/2009/09/top-arch-components

淘宝开放平台(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的“兵器谱”会更加丰富,更加出彩。

========================

http://www.csdn.net/article/2012-07-26/2807765

SDCC讲师专访:淘宝岑文初谈开放平台架构

CSDN:请您对自己做个简单介绍,尤其是在开放平台方面的技术经验和积累。您目前最关注哪些技术领域?

岑文初:从2007年底开始构建阿里系最早的开放平台,2009年正式加入淘宝开始负责淘宝开放平台基础架构建设,2012年负责整个淘宝的开放平台技术和产品团队。

开放平台发展的过程中技术也不断的在发展,从最早的网站服务化(SCA,OSGI),平台授权(OAuth),服务流控与服务隔离(Web容器异步化服务处理),服务生命周期管理(服务接入与文档,SDK自动化等),到后来的平台透明化(海量流式数据即时分析),多样化服务(ATS异步大任务处理服务,Streaming API流式数据推送服务,支持并行和串行化的QL服务),无线客户端的安全及服务易用(IOS、Android),JS组件(支持网站接入)。

CSDN:作为电商开放平台的代表,您觉得淘宝开放平台在架构方面有哪些特点?尤其在系统稳定和数据安全性方面,淘宝用到了哪些技术、经历了哪些磨历?

岑文初:淘宝开放平台架构关键词:透明,核心模块小,按需简化设计,多层次设计配合(js,client,server),服务模式创新。

系统稳定:1.Web容器异步化支持服务流控和隔离。同步的http服务处理模式在初期后端服务不多,服务质量差异不大的情况下能够满足需求,但是当后端服务越来越多(最初30个公开服务到今天300多个公开服务),服务质量和响应参差不齐的情况下,开放平台自身的稳定性直接受制于后端某一个服务,因此当后端某一个服务出现不稳定,就会直接使得淘宝开放平台服务全线无法服务,因此将同步的http服务中转改造为异步中转并设置了权重线程池来差异化对待不同重要度的服务,最后实现服务之间质量影响隔离,服务与平台稳定性隔离。

2.基于流式数据分析可以每一分钟产出业务和系统的统计数据。对比一些基线和告警阀值,最快速度的定位问题,并且采取运行期控制的方式来避免问题的扩大。

数据安全:

1.淘宝开放平台是所有开放平台中对于数据安全要求最高最细的开放平台,当前除了使用业界标准的OAuth2,同时还将安全控制从服务纬度细化到了服务字段级别,同时对于数据安全性分成了四个级别,结合应用形态和应用安全指标差异化控制。

2.通过JS组件化集成实现对用户发起服务和isv应用服务端发起服务的差别验证,对于电子商务买家类服务开放提高了安全性。3.提供无线端SDK静态类库方式,平衡无线用户的安全性和用户体验。

CSDN:在淘宝11.11活动中,面对这种突发的海量访问请求,淘宝开放平台采取了哪些应对措施?

岑文初:淘宝的11.11访问量其实一直在预期以内,因为平台自身对于数据流解析,异步化都保证了高效的系统处理能力,同时可以卸载的一些服务控制保证了服务控制流程如果出现问题可以随时降级处理,保证业务正常支持。另一方面,对于海量订单的对外输出,提供了Streaming api,降低轮询服务带来的压力,同时能够给开发者和商家最快速的消息投递。

CSDN:定义设计API接口有哪些学问和经验可以分享的?

岑文初:对于数据获取类服务非常重要的一点就是保留fields字段,也就是可以支持有选择的数据返回,这样对于服务升级(字段增加或者减少)都会非常主动,同时也非常适合做QL映射。

另一方面,对外提供服务必须要先定义服务处理所对应的资源定义,这样可以避免服务过程化设计开放(服务要设计为面向资源开放),保证业务内部逻辑变更对外透明。对于操作型服务(更新,删除,新增),需要防范重放攻击,业务需要支持一些主键字段或者随机一次性会话字段。

Leave a Reply