SD大会开放平台技术分享资料

SD大会开放平台技术分享资料
SD大会结束了,将开放平台技术分享的内容整理一下,PPT在: http://www.slideshare.net/cenwenchu/ss-6142016

从产品到技术看开放平台(放翁)
View more presentations from cenwenchu.


下面是现场记录的一些内容:

以下是演讲实录:

        岑文初:大家上午好,我叫岑文初,今天给大家讲的,看这个题目跟大家在我们册上印的有点不一样,我最早是来讲技术,商业不是我来讲,现在做任何平台,产品这个设计一定要去考虑,我们在上面稍微加了几页PPT,淘宝为什么现在做开放平台?大家会提出疑问,是不是喊口号。

        今天从三个方面讲:第一个开放之于服务提供者,第二开放之于应用开发者,最后一点我给大家讲一下开放平台体系设计基础性的共性的东西,其实任何一家开放平台做的事情肯定有自己垂直化的东西,不会有类似所有的东西都可以拷贝,今天会谈这些基础性的东西。

        这边有两个三角形,其实为什么今年大家会发觉很多大型网站慢慢提出一个开放的概念,每一个网站到一定阶段都变成一个平台期,平台期考虑一个事情,怎么样增加我们的用户,怎么拓展我们产品的推广度,我们遇到一些困境,找一些突破,特别你的流量很大,你的用户数很多,你会考虑你的安全,你的效率跟你本身设计的折中,我们会牺牲三和七,或者四和六,我们网站往往会满足60%的用户需求和用户体验。

        另外一点就是创新,今天做开放平台很多人说是为了创新这一件事情,没有错,但是创新这一点,会有很多的内涵在里面,后面会谈到。创新会给平台瓶颈期创造一定的条件,今天淘宝大家会发觉会去做很多方面的融合,跟传统媒体去做,跟手机终端去做,甚至给一些电视领域都去做,什么原因?不可能把淘宝照模照样去放在手机上,所以下面有领域性的延展,线上来卖,今天淘宝让他怎么样能够上线,以前看到很多传统ERP的企业,慢慢成为TP,它所做的事情就是把原先的ERP系统变成跟互联网打通的所谓电子商务的系统,领域性这一块,淘宝今天有很多商品,今天也会看到其实有些领域里面我们没有做,收藏领域没有做,原因很简单,水太深,做不了。还有更多传统领域的东西都没有做,领域性的东西,我昨天在微博里面发了一句话,今天开放平台是给更多的开发者,或者更多的领域专家有机会把大家现在面向技术做产品改变成面向用户去做产品,这个意思就是说,今天用开放平台能够降低很多开发门槛,用领域专家用领域思维事情,不是做用户。为什么这里面的流程是多年积累的经验,肯定是很规范,我们所谓行业性的规范一样,其实是不是这样,你把这个战场铺到传统战场,你根本不适合在其它的地方使用,规范的东西也是开放之后才发掘出来。今天在场有很多网站需要做开放。第二个大家看到这个饼,其实对于开放来说一直会存在双韧剑的问题,在这里面大家会看到,里面会谈到几点,第一个安全性,今天的开放在一个桶上开了一个孔,希望把桶里的水放出去,我告诉你,病菌会从这个桶钻进去,这是最大的口,最容易突破的口,后面会谈到会产生哪些问题。另外是性能,今天你会看,我们开放平台API的访问量跟主站访问量趋势完全不一样的,用户行为跟RSB的行为完全不一样,RSB自身的稳定性对访问量产生影响,你现在说能承担多少用户的PV,你今天所说的扩展性只是在这个桶范围内做到的,一旦开放就面临这些问题。

        另外一块是业务,在上个礼拜我去B2B跟阿里巴巴一家B2B去谈的时候,我问他的一个问题,你开放出去,别人做同样的产品,你怎么权衡这一件事情。我希望他考虑这一件事情,今天很多开放平台,所谓开放的服务者有可能不希望你在喊口号,你只是去拿这种引诱让RSB去跟随,你今天以数据为王你东西放出去就没有了,在业务方面最需要提供者考虑清楚,有一句话很简单,今天开放收回来很难。

        另外一点系统结构,昨天正好有一个北京的朋友跟我聊,他说他不想做开放,他希望他内部体系结构服务化一点,内部服务不要交错那么厉害,淘宝发展的过程有几个阶段,第一个把自己内部系统完全隔离开,这里面有一个度的问题,今天开放一定是局部性的,一定是阶段性的,你完全不可能一次性放出去,你没有做好服务化,没有做好隔离化,你放整个系统就垮掉了。

        这边我再谈一下对于我们的应用开发者,我相信有些同学做应用开发的,我记得每一次应用开发者跟我交流的时候最常问的问题,今天我开发这个软件如果跟淘宝冲突了怎么办,将来淘宝会不会收编,我用什么办法生存下来,我会谈到两点,这边有左右两块,第一块推广和授权,这个其实能够给开发者提供的便利,对于现在的互联网开发者来说,他本身产品的生产和产品的推广是最大的两个瓶颈,有两个最大的存在的风险在里面,它需要投入很多精力资金在里面,如果通过API的开放,他直接可以省去这两个东西,后续你的应用发展起来之后你能力的扩展也需要一定的风险避规。另外有行业门槛,渠道门槛,技术门槛,我一直希望大家不要站长再生淘宝这个小圈子里面看事情,你需要有什么不同,昨天我记得有一个朋友谈到,技术不是门槛,我相信技术不是门槛,技术一定是敲门砖,一定是基础,你需要做应用开发的时候需要了解你能够有和别人不同的地方,如果你做一个软件两个月,或者几天之内就能做出来你就不要做,技术只是应用成功其中很小一部分,或者其中一部分,另外有很多门槛,杭州有一个团购网一直是OK的,就是都市快报,有传统媒体作为渠道,做的跟别人一模一样,它一样能够产生效益,你一定要找不同点,不管是技术门槛,渠道门槛,一定要找到门槛,当这些门槛都不存在的时候可以看上面的这个服务,最终大家拼的领域里面的软件,你的服务好也是一种差异,但是创意这一件事情我希望大家去了解,这是一个概念,但是创意这一件事情一定要依托这个门槛,创意很虚,真正适合是旁边的东西。

 

        后面我讲一下具体的,有可能程序员比较关心的底层架构的东西,会提一下架构的链。第一个是生和养,后面谈到细节的优化都是最基础的环节,其实开放APR只是第一步,后面产品化,把产品推到用户面前,使开放平台生态体系有一个很好的发展,你不要想你开放了API就算了,今年开放了没有人用。第二个是共性和特质,有一些东西一定是特质的,今天你是做电子商务的开放平台跟做其它开放平台里面的东西是不同考虑的。最后是一个目标和愿景,其实每一个做开放平台的,包括淘宝,所有的人进淘宝的时候想要平台开放,很多人都说我要去做水厂,我要去做电厂,希望把人力都放进去,一个是网站型的开放,一个是平台型的开放,网站型的开放一定有核心的东西不能开放的,有些核心功能必须自己做,这些核心功能牵住用户,再把周边的东西常委交给更多的RSB做,说实话,大家发觉越来越把他的网站,客户端做的很好,原因是什么?今年依然是他的客户端访问量占很小的余地的时候,他本身的盈利所涉及的点很小,整个生态系统一定是多赢的,任何一方达到部分到赢,他一定想去改变。

         这是一些数据,淘宝开放平台有些人提的并不是很多,我说做淘宝开放平台的时候他一定对电子商务这一块东西了解比较透彻,但是电子商务其实有比较深的水。从2008年到2010年在ARR交易量上,大家看翻的很厉害,明年会翻的很厉害,包括明年买家性的工具会全部放出来,后续回去了解这一件事情。这个量大家看今天只有七亿,这方面我们会做很多限制,这边是我们整个架构的变革,最早我们会关注,我跟大家谈的你要做开放之前一定会把网站里面做服务化,做隔离,否则你没有办法开放,你开放就知道有多大的风险,到09年的时候,我最早阿里巴巴软件,最早淘宝跟阿里巴巴软件合作,阿里巴巴是做开放平台的角色,09年我转到淘宝那里,这个时候大家知道阿里巴巴变成云公司了,定位不同之后,淘宝变成开放平台的生态体系,后面谈的只是最基础的,真正的体系会影响整个生态圈的发展。

         2010年对于我来说,当然会关注商业性的东西,当然我会更关注技术性的东西,更关注透明化。透明化在我们技术上做这几点实施,第一个安全,我先把这些抛出,第一个是安全,首先你网站个人用户的安全一定会考虑到,你网站自身的安全,会不会钓鱼,会不会有些信息被抓取,第三个应用身份安全,淘宝会对于整个RSB分成不同的体系,不同的RSB体系是不一样的。第二是易用性,我后面会讲。

        然后有一块速度,速度对于服务来说,第一个是耗带宽服务,耗时服务,耗资服务。第二个是稳定性,平台不稳定大家很容易理解,其实我最希望看到的效果,它的开放不是专门的部门去做,是渗透在整个部门里面去做这一件,今天淘宝在初级的过程中,任何一家公司在做初期的过程中,中国里面一开始肯定是先以一个部门去集成一些服务,慢慢把这些渗透到整个公司里面。最后一个是服务易用,今天淘宝很慎重做买家公司的原因,今天有些工具能够潜入到交易页面里面,但是这些不稳定用户直接感受到淘宝出现问题了,这样的问题怎么减少发生。

        这边是基础的平台,最早的时候我们把服务接入平台和授权容器是授权在一起的,最早的版本我们相信授权和服务接入在一套体系里面,因为比较先进,放在一起的好处是能够负担相互风险在里面,但是其实你会发觉越到后期的时候,你容器的变更会越多,里面的安全,包括策略会很丰富,它会经常发布,你的服务接入平台本身很稳定,我们希望服务接入发布一个月,两个月太发一次,但是的容器可能经常发布,系统架构里面会把易变的东西,虽然觉得比较关联,易变的东西抽出来,就算没有容器我依旧跑下去,因为授权只是你自己保护你自己,用户不管。然后会有控制台,中间会有分布式的分析,中间会有透明化,透明化把所有的,不管是信用,还是业务,全部如实的记录下来,及时的了解这个状况,才能去做后面的事情。

 

        首先是速度,今天你调一个淘宝的RPR,速度我们认为不管任何开放平台的第一感触,刚才谈到几个问题,第一个是耗带宽的服务,一种是上行流量比较大,一种是下行流量比较大,像淘宝商品,图片描述,那个东西相当之大,不比下行速度小多少,我们用AA数据解析的分析,对于我们来说,因为大型的数据传输过来本来对带宽消耗很大,假如里面有一些参数是非法的,我们能不能事先就能解析出来,一方面通过客户端保障,可以放在靠前的位置,当这个管道校验发现校验已经出错了,就可以拿回去了,所以解析能够减少很多无用大数据量的传输。第二块是容器的选择,大家会看到在数据量比较大的,Java的读取可能由于数量量比较大,每次上传的数据包会很小,你会有很多次读取,这种消耗很大。在这个方面考虑,我们喜欢替换容器,现在测试效果蛮不错的。另外一块就是静态结果下来,前面都是在上行里面比较大的数据,当然这里面有下行的数据,有些卖家有很大的定单,他需要发货,这个定单超级大,对于容器有很大的消耗,其实对于我们来说,这个平台最大的功能是什么,安全,路由,有时候返回的数据,或者把一个请求拆成两个请求,这样的话不需要你中转数据,节省你下行带宽。第二个是耗时服务,我不知道其它的平台怎么样,淘宝每天数据量相当之大,对于很多定单查询,历史定单查询,包括历史性的东西查询都会很慢。我们会用什么方式呢?它是在前端做派克化,我们在后端在派克化,我们会切成小的任务,这样做的好处,每一个管道所需要的资源,在这个管道如果结束之后,这个环节结束之后他不再需要用的话,会很快的释放掉,管道化之后发现每一个资源一旦能够被快速释放的话本身它的生命周期短就能够大大增加它处理的能力,同时后面管道后之后你能够做降级,有人说有百利无一害,但是不是这样的,这个东西没有很好的框架封装上面的开发很复杂,原先保证他的顺序性,你切开之后会有很大的问题。为什么大家会谈到需要做异步化的事情,因为我们早先做容器去帮大家感觉回收,这样的好处让我们开发者屏蔽很多细节,不好的方法,你最后还得交易一把,等到它们全完了你还得把东西全部塞一下,你没有办法根据你的业务性去选择你应该去做什么处理,如果你把容器线程业务线程拆开之后,你会发觉第一个容器本身线程寿命周期短,处理效率高了,同时业务线程有更多的业务在里面去做。耗资源,这时候需要把原始的,如果是Java开发,需要把原始的Java转成类型,如果放在平台,大家发现拓扑有可能几十台机器,我们后台芳香油很多机器,我们能不能把结果后一到他们身上,很多把渲染的东西放在前端的,而不是现在放过来,这也是一种优化手段。当你有些东西可以后移,或者前移的东西,对方资源更多的时候,可以移过去,这个代价就是升级的代价。然后决策规则,开放平台,包括流控等,这一块的东西我们是不是把所有的决策都是在这里面做,我一个请求过来根据决策做很多的计算,最后得出你能不能继续访问,有没有出问题,需不需要这样,如果技术性要求不是很高,我们应该把决策外移出去,最后把一个结果推送给我们的接受平台,这种外移能够对开放平台有很大的性能上的提高,原先这些东西都是揉在一个东西里面,慢慢会抽出来,希望把性能提升到最高。

        第二个稳定性,内外兼修的工作。我经常在说,其实我们小病还可以生感冒到医院看看病,你得了重病起不了床怎么办呢?每天有人询问人你有没有生病,他会来做这个事情。对于系统一个内部做监控优化,另外是外部的监控优化,对于系统结构设计来说,第一个是多级缓存,增量与全量缓存,还有究竟换成增量,还是换成权量,第二个是基于基于布隆算法的白名单,有些系统不命中有可能从其它系统拿一些结果,这样的问题是当别人产生攻击的时候,大量的无用,缓冲是保证后台慢的,我们叫白名单,有可能叫它灰名单,在这个灰名单出现的内容未必在你的系统内合法,但是不在你灰名单出现的东西肯定不合法,这一块东西对于很多缓存系统很有帮助的,然后服务的分流和隔离,刚才也谈到拓扑平台上接入了各种各样的服务,这个时候你需要怎么隔离出来,我们把容器和业务分开之后,你就可以把你的服务进行分流,哪些服务应该优先处理,哪些服务应该慢一点处理,这些都是可以去考虑的,第二个是控制台,控制台有几个功能,对于开放平台来说,它每一次发布都影响面很广,因为RSB成千上万都在这上面,拓扑先把这个功能关掉,选出一台机器,通过控制台把它打开,看这个功能,我们分析的曲线错误率怎么样,当分析都没有问题的时候让这台机器跑,这时候发布大家会看到这个风险大大降低了,我们面对淘宝经常发布方式的一种改善。

        第二个是管道化的服务降级,每一个流程里面没有把它切开一错全错,但是你希不希望有些非关联性功能不要影响主功能,我打个比方说今天服务平台里面会有一个流量控制,流量控制依赖集中式缓存,这个流量控制是为了保证怎么服务体系的健康度,如果我的缓存失败了,这个管道自动,或者手动放下来,这样发觉我们主流不会受到影响,今天淘宝有很多秒杀系统,有很多关键性流程,不是秒杀系统特别好,而是大家真正把关键性的步骤抽出来,非关键性的步骤省掉,把分析的结果和决策在外部去运算,最后推到接入平台,让它做的很纯粹。最后一块就是监控系统,监控系统大家都会有,我这边大致谈一下,第一个基于历史基线的服务访问监控,这就是大窗口和小窗口,我们去比较,我今天的数据和昨天的数据去比,如果我比较的窗口比较小的话,大家会发觉产生的毛刺,或者不准确性会很多,因为每天细微的比较肯定会产生一些波动,我们希望把它放大,放的太大,如果我把一天24小时切成24块去比较又不精确了,我们用大窗口的方式去比较,比如0点到1点的数据跟明年的0点到1点的数据比较,把毛刺去掉,这样既能够精确上达到要求,又能够在我们整个所谓的准确性达到要求,第二个多纬度的业务比较,今天突然发现访问量突高了,这个时候需要很多的指标,监控团队就怕告警风暴,我们做组合设置,我们很快找到出现高警风暴的点。第二个多机对比的监控,像Bela发布,有两个环节做不同容器的实验也好,你怎么样去看这个数据,或者它的性能怎么样,不同的机器需要对比,才能了解到问题。

        第二个安全性,这也有三块,第一块是用户数据安全性,很少大家看到有应用的授权管理,对于做开放平台很敏感的事情,淘宝现在还没有提供,很快就提高了,有些应用,比如护粉率的测算,你只希望测算一把,有些平台是长期有效,就像谷歌一样,像拓扑是可延时的,你调一次就延一下,你给要死你不把门关上他每次都能进来,其实我想说,今天根据RSB的要求,今天是卖家工具,我当然不会解除授权,这个可以通过平台来解决,也可以通过给用户一个权限去解决。第二多方授权场景,我刚才说到差异性,今天你会看到我们SMS,或者其它开放平台授权完之后,哪个访问出去了,淘宝上大家会看到,如果一笔交易的产生需要两方授权,买家授权,卖家授权,这是一个双向授权,团购多方授权,这种就是差异化,不同的领域里面根本不会考虑这些问题,授权会有很大的不同,另外就是多应用的互通,今天江湖上有很多插件应用,平台用户进入之后他不希望反复跳出授权,需要考虑怎么样让平台授权得到很好的支持,授权里面需要解决的。

        另外应用的身份安全,刚才说的应用我们一直在纠结一个问题,有BS的应用,也有CS的应用。另外我谈一下淘宝主站的安全性,我们授权完成之后转到第三方的应用上去,转后就不告诉你,问题是今天钓鱼横行,如果转到钓鱼网站就完了,这个里面真的是水太深,只是做到初期的问题,后期一大堆的转跳。第三个是流程化的服务,刚才说到这个数据被人抓取出去怎么办,一种方式你尽量少开放,另外把中间过程封装,数据不要流到他们那边去。然后易用性,其实RSB,国外RSB开发那么多年,任何的平台一开就容错,这些东西都会做,在它的可用性达到一定指标之后,他更在乎易用性。易用性我们今天会花很大的力气去做,淘宝做开放水很深,在这一块上面我们去做这些事情。上面我还写了一句,与人方便自己方便,你今天做开放,我们会看到如果你的SDK应用率越广大将来你升级服务越方便。再就是易接入,原来后端接入进来都需要写一大堆的服务文件,今天我们通过一个很简单的平面,输入一些关键性的信息就自动生成文件,甚至连VT都能生成,其实在这一块上面我们做易接入,第二个易查错。昨天会拆成几个阶段,其实里面分成更多的阶段,包括DNS解析,包括连接的建立,包括页面渲染,网络交互,每个环节都是需要监控的点,这些其实是决定你服务质量很重要的一个保证。我再谈一下。刚才再说透明,透明是什么,中间是这一块,服务访问数据,加上旁边这些东西,如果把这些数据全部记录下来,全部有分析,如果加上比较,你就会去优化,我不相信人做系统优化,所以有数据加比较就是优化,有数据加上规则就是决策,加上业务就是趋势,我们每年会有不同的侧重点,去年会做一些卖家工具,大商家的扶植,明年会有数据APR的开放,这些业务数据能够直接告诉你,这些方向是不是用户真正的方向。另外就是阀值监控。这边会有成长轨迹,成长轨迹我们叫分析器的成长轨迹,跟刚才我们说的整个拓扑成长轨迹很相似,因为都是以数据为主,成长轨迹大家会看到数据量是不同的,开始有可能是单机单线程,最后变成多机多线程,其实是有不同的阶段,最早只是去做运营分析,后面变成对整个系统和运营的分析,最后变成及时告警的分析。分析里面,这边我谈,刚才说有一个延伸的阶段,这三个阶段里面有一层一直没有变,就是统计模型的抽象层,统计抽象,把这些东西抽象出来以后你不需要做很多的瑞迪欧斯。所以这一块东西一直是我们最早设计的初衷。第二个是数据通信层。第二个是任务管理层,前面两个任务都是从单机上面拿这些文件数据,其实的确有很多差距可以去适用,对于数据量不是很大,其实它并不是那么合适,大家会看到两个图,左边和右边,大家会看到。你这个任务,包括你的数据来源,数据获取方式,你配置的方式,这些东西都在焦克里面自描述的话,只需要把这些斯瑞沃,大家会看到这种松散的方式唯一的缺点是什么,如果有一个斯瑞沃出现问题,这个任务跑下去了,马斯特做粗爆的策略,就是我直接把这个任务,最坏的情况无非同样两个斯瑞沃做同样的事情,其实我们叫廉价的斯瑞沃,有时候难免系统会垮,有可能数据增长很快。随时随地一个运营,一个问题出现问题,我们希望看是什么数据产生的问题。第二我们本身的数据量不是很大,一个监控数据量不是很大,一个服务器本身监控的东西不是很多,你可以选择一些关键性的信息,这些处理可以作为其它系统二次处理的数据,那个数量很小,但是对于你网络上不会有数据风暴,你不要压缩,你压缩会产生CPU的消耗。最早期,这边会有两个,圆形的就是一个DB,底下就是FTP的,大家发觉跟多线程设计一样,有一环二串型的,瓶颈在哪里?DB的RO,没有问题,前面的斯迪沃再快也是串行的,这个并行的效果就不好。我们本身的数据来源不是大文件一次性拿过来,这个大家会看到,我一直坚信一个概念,大家做监控系统的时候,一定考虑监控系统是帮人家更好的生存而不是影响它生存,你推的时候,你推过去也是推在那儿,因为你是主动的过程,你需要做放慢脚步,推和拉还是有一定的差距,如果完全相信它的能力,你不要在业务数据里面加,如果你觉得它里面有可能产生问题,你完全根本时间冲做分析,不是当前时间段做易损。

         这边就是一个多组建的协同,大家会看到,这边有一个管理员,然后在我们的统计结果会及时更新这些结果,有些可以拿这些结果做一些告警,有些团队,比如RSB,他需要做二次处理就拿这些数据二次处理。再底下是监控平台,一旦搜集这些数据能得到这些信息告警,怎么样及时高效产生,包括监控和业务处理。刚才我说的有些东西都是比较基层的,淘宝这边有沙箱,还有推送的数据,如果淘宝一个流程里面需要推送的话,比如一笔交易成功了,那些IPR肯定不是交易用的,这边会有监控系统,拓扑服务器就是最稳定的这一块,就是接入这一块,真正的开放会渗透到骨子里去,每一个大的网站开放不是某一个部门的事情,是整个网站的事情,原始性的开放的确渗透到骨子里面,但是上升RSB引导上面有更多流程性的封装。这里面我们有一个叫TB,作为数据中心,好处大家的数据系统是统一的,但是拓扑必须有完整的设计里面做这一件事情。会有很多面向开发者,包括面向RSB去运营它的产品,这一系列的门户,你做开放平台,你真的做成有效果的东西一定做成一个体系,上面只是一个敲门砖,也是RSB继续信任你继续玩下去的重点。里面有很多东西。我稍微简单说一下运营门户,原先我们运营门户都在一个门户上运营,今天我们有一个蓝海项目,明年我们把这些运营切开,APA的产品运营其实有方向性和垂直化,这时候也只有这样的PT能享受更多的东西,初期的时候肯定是揉在一起的。

        今天讲的比较快,最后我一直在说两句话,第一个透明的平台是成功的平台,第二个是无声的技术是最好的技术,为什么这么说?你的用户,不管是程序员也好,感觉不到你有平台,你的平台就做成功了,他觉得你有平台就证明你有很多门槛他受不了。后面两个词,简单和直接,你不用觉得,画这个图,几个框框,很不好意思,如果你画几个框框,几个线就解决问题了就好了,画很多框框,画很多线反而不一定好。淘宝会把很多关联切掉。

你可能感兴趣的:(SD大会开放平台技术分享资料)