淘宝开放平台架构组件体系初探
- 格式:doc
- 大小:143.50 KB
- 文档页数:6
SDCC中国软件开发者大会电商架构专题淘宝商品体系架构的历史和演进汇报人:范围淘宝资深开发工程师目录C O N T EN T1淘宝体系架构的演进2淘宝商品架构3元数据在淘宝商品体系架构中的应用01淘宝体系架构的演进PART ONEWHY为什么要升级架构l●架构升级的目的•节约成本•提高收益l●淘宝商品体系架构随着业务的发展不断变迁•降低开发成本•提升开发效率•支持更灵活、复杂的业务电商系统发展的四个阶段WHAT石器时代单一业务系统中世纪分布式业务系统工业革命业务平台化未来业务中台化02淘宝商品架构PART TWO商品的特点1l●商品形态•实物、服务、虚拟、零售、分销、批发、供应链l●灵活的结构•基于不同的场景、视角和形态,商品千差万别l●稳定性和确定性•10亿+在线商品•亿级+条码•百万级+品牌卖家买家服务实物交易金额交易额价格交易量线上资质线下信用标签性别年龄地址商品淘宝商品结构2SPU标准产品单元Product商品SKU库存量单元营销价格库存时间地点物流市场规则规范效率个性描述描述信息特征标题多媒体图片地址库品牌库类目属性库行业属性产品要素卖家要素销售要素商品发布产品中心市场3商品生命周期前后台商品体系4商品数据流转5后台商品库后台类目标准属性……商品算法平台前台类目体系前台商品库前台类目集导购PV集……导购算法平台运营干预搜索导航用户行为配置类目属性商品发布平台治理后台类目体系运营平台数据推送服务版本化数据包前台类目属性服务数据治理服务03元数据在淘宝商品体系架构中的应用PART THREE1元数据驱动元数据•描述数据的数据元数据驱动架构•利用元数据来控制和实现应用的逻辑元数据一直都存在,并常被我们所使用•Java POJO•数据库Schema•配置信息理念-应用基础架构2•绝大多数应用采用经典Web结构•部分配置从代码中抽离出来单独管理•抽象比较好的业务提供运营平台,让运营、产品人员直接配置规则•新业务需求需要编码实现,周期以周记•通过接口接收请求、返回结果•调用初始化配置和逻辑•调用依赖应用获取数据•调用多种存储获取数据•应用根据请求执行计算逻辑,获得结果应用逻辑配置中心依赖应用依赖应用依赖应用MySql搜索KV 缓存理念-元数据驱动架构3——元数据驱动架构核心思想就是提高元数据使用比例应用逻辑配置中心依赖应用依赖应用依赖应用数据库搜索KV 缓存模型规则流程界面l 元数据包含:•模型:接口(API)、数据(DO对象)、存储(DB)•逻辑(基本能力):组件化代码片段、脚本片段、规则、规则集•流程:组件选取、执行编排•界面:UI组件管理、可视化编辑•配置:开关、业务配置4元数据驱动的思路l●未来全局架构•不同角色的运营平台•控制逻辑配置和规则抽离•业务执行系统•三类数据:控制数据,基础数据,过程数据l●好处•通过动态配置改变应用执行逻辑,提高效率•业务和技术分离,PD、运营等非技术人员可以直接参与开发•逻辑和能力可视化好元数据驱动架构平台512 3 41 2 3 4/元数据引擎6l●元数据等同于代码,元数据修改等同于开发l●特性:–需要多版本、快照–需要继承、引用–事务、数据一致性–环境隔离(沙箱)–发布、回滚Trunk项目环境预发环境生产环境项目2日常1deploydeploydeploy日常2日常3S优点T挑战通过增加动态配置的比例,提高开发效率业务和技术分离,非技术人员可以参与开发逻辑和能力可视化好学习曲线、理念上的转变对于稳定性和性能方面有较高要求需要丰富的配套工具支撑此处添加副标题汇报人:某某此处添加主标题谢谢聆听。
/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类似流程),还在服务调用过程中通过区分应用角色来限制对于用户信息的获取和使用。
淘宝网架构:解密淘宝网的开源架构疯狂代码 / ĵ:http://DataBase/Article2500.html来源: Linux论坛淘宝网,是一个在线商品数量突破一亿,日均成交额超过两亿元人民币,注册用户接近八千万的大型电子商务网站,是亚洲最大的购物网站。
那么对于淘宝网这样大规模的一个网站,我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构,也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。
那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说,其IT必然是一个服务器集群来提供网站服务,数据库也必然要和应用服务分开,有单独的数据库服务器。
对于像淘宝网这样规模的网站而言,就是应用也分成很多组。
那么下面,我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。
操作系统我们首先就从应用服务器的操作系统说起。
一个应用服务器,从软件的角度来说他的最底层首先是操作系统。
要先选择操作系统,然后才是操作系统基础上的应用软件。
在淘宝网,我们的应用服务器上采用的是Linux操作系统。
Linux操作系统从1991年第一次正式被公布到现在已¾ ¬ 走过了十七个年头,在PC Server上有广泛的应用。
硬件上我们选择PC Server而不是小型机,那么Server的操作系统供我们选择的一般也就是Linux,FreeBSD, windows 2000 Server或者Windows Server 2003。
如果不准备采用微软的一系列产品构建应用,并且有能力维护Linux或者FreeBSD,再加上成本的考虑,那么还是应该在Linux和 FreeBSD之间进行选择。
可以说,现在Linux和FreeBSD这两个系统难分伯仲,很难说哪个一定比另外一个要优秀很多、能够全面的超越对手,应该是各有所长。
淘宝服务端技术架构详解目录一、前言 (3)二、单机架构 (4)三、多机部署 (4)四、分布式缓存 (5)五、Session 共享解决方案 (7)六、数据库读写分离 (9)七、CDN 加速与反向代理 (10)八、分布式文件服务器 (11)九、数据库分库分表 (11)十、搜索引擎与NoSQL (13)十一、后序 (13)一、前言以淘宝网为例,简单了解一下大型电商的服务端架构是怎样的。
如图所示最上面的就是安全体系系统,中间的就是业务运营系统,包含各个不同的业务服务,下面是一些共享服务,然后还有一些中间件,其中ECS 就是云服务器,MQS 是队列服务,OCS 是缓存等等,右侧是一些支撑体系服务。
除图中所示之外还包含一些我们看不到的,比如高可用的体现。
淘宝目前已经实现多机房容灾和异地机房单元化部署,为淘宝的业务也提供了稳定、高效和易于维护的基础架构支撑。
这是一个含金量非常高的架构,也是一个非常复杂而庞大的架构,当然这个架构不是一天两天演进成这样的,也不是一开始就设计并开发成这样的,对于初创公司而言,很难在初期就预估到未来流量千倍、万倍的网站架构会是怎样的状况,同时如果初期就设计成千万级并发的流量架构,也很难去支撑这个成本。
因此一个大型服务系统,都是从小一步一步走过来的,在每个阶段找到对应该阶段网站架构所面临的问题,然后不断解决这些问题,在这个过程中,整个架构会一直演进,同时内含的代码也就会演进,大到架构、小到代码都是在不断演进和优化的。
所以说高大上的项目技术架构和开发设计实现不是一蹴而就的,这是所谓的万丈高楼平地起。
二、单机架构从一个小网站说起,一般来说初始一台服务器就够了,文件服务器、数据库以及应用都部署在一台机器上。
也就是俗称的 allinone 架构。
这篇推荐看下:厉害了,淘宝千万并发,14 次架构演进…三、多机部署随着网站用户逐渐增多,访问量越来越大,硬盘、cpu、内存等开始吃紧,一台服务器难以支撑。
淘宝开放API 技术分析API列表与说明TFS实现.NET数据实体Ray Zhang, 2010用户API提供了用户基本信息查询功能数据结构Location用户地址User用户UserCredit用户信用UserSubscribe用户订购信息API列表taobao.appstore.subscribe.get查询appstore应用订购关系er.get获取单个用户信息ers.get获取多个用户信息产品API提供了产品相关的发布,修改等功能数据结构Product产品结构ProductImg产品图片ProductPriceStat产品价格统计结构ProductProp属性统计结构ProductPropImg产品属性图片ProductSearch产品统计查询结果ProductStat产品统计结构API列表taobao.product.add上传一个产品,不包括产品非主图和属性图片taobao.product.get获取一个产品的信息taobao.product.img.delete删除产品非主图taobao.product.img.upload上传单张产品非主图,如果需要传多张,可调多次taobao.product.propimg.delete删除产品属性图taobao.product.propimg.upload上传单张产品属性图片,如果需要传多张,可调多次taobao.product.update修改一个产品,可以修改主图,不能修改子图片taobao.products.get获取产品列表taobao.products.search搜索产品信息类目属性API提供了标准类目,类目属性和类目属性值的查询功能数据结构Brand品牌Feature类目属性ItemCat商品类目结构PropValue属性值SellerAuthorize授权API列表taobao.itemcats.authorize.get查询B商家被授权品牌列表和类目列表taobao.itemcats.get获取后台供卖家发布商品的标准商品类目taobao.itemprops.get获取标准商品类目属性taobao.itempropvalues.get获取标准类目属性值商品API提供了商品以及商品相关的sku,邮费增加,修改功能数据结构AfterSale卖家设置售后服务对象Item Item(商品)结构ItemCategory商品查询分类结果ItemExtra商品扩展结构,通过iid和Item结构相关联ItemImg ItemImg结构ItemProp商品属性ItemSearch商品搜索Postage运费模板结构PostageMode运费方式模板收费方式PropImg商品属性图片结构Sku Sku结构SkuExtra Sku扩展表的扩展sku记录Video商品视频关联记录API列表taobao.aftersale.get查询用户售后服务模板taobao.item.add添加一个商品taobao.item.delete删除单条商品taobao.item.get得到单个商品信息taobao.item.img.delete删除商品图片taobao.item.img.upload添加商品图片taobao.item.propimg.delete删除属性图片taobao.item.propimg.upload添加或修改属性图片taobao.item.recommend.add橱窗推荐一个商品taobao.item.recommend.delete取消橱窗推荐一个商品taobao.item.sku.add添加SKUtaobao.item.sku.delete删除SKUtaobao.item.sku.get获取SKUtaobao.item.sku.update更新SKU信息taobao.item.skus.get根据卖家昵称和商品ID列表获取SKU信息taobao.item.update更新商品信息taobao.item.update.delisting商品下架taobao.item.update.listing一口价商品上架taobao.items.custom.get根据外部ID取商品taobao.items.get搜索商品信息taobao.items.inventory.get得到当前会话用户库存中的商品列表taobao.items.list.get批量获取商品信息taobao.items.onsale.get获取当前会话用户出售中的商品列表taobao.items.search搜索商品信息taobao.postage.add添加邮费模板taobao.postage.delete删除单个运费模板taobao.postage.get获取单个运费模板taobao.postage.update修改邮费模板taobao.postages.get获取卖家的运费模板taobao.skus.custom.get根据外部ID取商品SKU交易API提供了订单下载,修改收货地址、修改交易备注等功能数据结构Order订单结构PicUrl图片链接PromotionDetail交易的优惠信息详情Refund退款结构RefundMessage留言/凭证数据结构RefundRemindTimeout退款超时结构ShippingAddress收货地址数据结构Trade交易结构TradeAccountDetail淘宝卖家绑定的支付宝账户的财务明细TradeConfirmFee确认收货费用结构API列表taobao.refund.get单笔退款详情taobao.refund.refuse卖家拒绝退款taobao.refunds.apply.get查询买家申请的退款列表taobao.refunds.receive.get查询卖家收到的退款列表taobao.trade.amount.get交易订单帐务查询taobao.trade.close卖家关闭一笔交易taobao.trade.confirmfee.get获取交易确认收货费用taobao.trade.fullinfo.get获取单笔交易的详细信息taobao.trade.get获取单笔交易的部分信息(性能高) taobao.trade.memo.add对一笔交易添加备注taobao.trade.memo.update修改一笔交易备注taobao.trade.ordersku.update更新交易订单的销售属性taobao.trade.shippingaddress.update更改交易的收货地址taobao.trade.snapshot.get交易快照查询taobao.trades.bought.get搜索当前会话用户作为买家达成的交易记录taobao.trades.sold.get搜索当前会话用户作为卖家已卖出的交易数据taobao.trades.sold.increment.get搜索当前会话用户作为卖家已卖出的增量交易数据评价API提供了评价的添加和查询功能数据结构TradeRate评价列表API列表taobao.traderate.add新增单个评价taobao.traderate.list.add针对父子订单新增批量评价taobao.traderates.get搜索评价信息物流API提供了发货,物流单详情,区域地址和物流公司信息查询功能数据结构LogisticsCompany物流公司结构LogisticsPartner物流公司信息Shipping物流数据结构TransitStepInfo物流跟踪信息的一条API列表taobao.areas.get查询地址区域taobao.delivery.cod.send货到付款(cod)发货处理taobao.delivery.send发货处理panies.get查询物流公司信息taobao.logistics.orders.detail.get批量查询物流订单,返回详细信息taobao.logistics.orders.get批量查询物流订单taobao.logistics.partners.get查询物流公司信息taobao.logistics.trace.search物流流转信息查询收费API提供了B商家保证金查询功能数据结构GuarantyFund保证金Suite套餐VasProduct产品订购信息VasSignInfo代扣协议接口数据处理后的返回信息VasSignUrl客户查询是否签约的信息回馈,返回message,aplipaySignAddressAPI列表taobao.guarantyfunds.get B商家保证金查询店铺API提供了店铺查询,店铺自定义类目的查询和更新,图片空间图片的查询和删除等功能数据结构ItemVideo商品视频MediaCategory媒体文件分类MediaFile媒体文件Picture图片PictureCategory图片分类SellerCat店铺内卖家自定义类目Shop店铺信息ShopCat店铺类目ShopScore店铺动态评分信息API列表taobao.picture.category.get获取图片分类信息taobao.picture.delete删除图片空间图片taobao.picture.get获取图片信息taobao.picture.upload上传单张图片taobao.sellercats.list.add添加卖家自定义类目taobao.sellercats.list.get获取前台展示的店铺内卖家自定义商品类目taobao.sellercats.list.update更新卖家自定义类目taobao.shop.get获取卖家店铺的基本信息taobao.shop.remainshowcase.get获取卖家店铺剩余橱窗数量taobao.shop.update更新店铺基本信息taobao.shopcats.list.get获取前台展示的店铺类目分销API提供了分销商信息和采购单信息的查询以及分销产品的添加和更新等功能数据结构Distributor分销API返回数据结构FenxiaoSku分销产品ProductCat产品线PurchaseOrder采购单及子采购单信息Receiver收货人详细信息SupplierStat供应商的汇总信息。
淘宝开放平台架构组件体系初探
作者岑文初发布于2009年9月29日上午11时22分
社区
Architecture,
Java
主题
平台,
企业架构
标签
基于组件的架构
淘宝开放平台(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的“兵器谱”会更加丰富,更加出彩。