淘宝技术框架分析方案报告.docx

淘宝技术框架分析方案报告.docx

《淘宝技术框架分析方案报告.docx》由会员分享，可在线阅读，更多相关《淘宝技术框架分析方案报告.docx（8页珍藏版）》请在冰豆网上搜索。

淘宝技术框架分析方案报告

淘宝技术框架分析报告

淘宝作为国内首屈一指的大型电子商务网站,每天承载近30亿PV的点击量,拥有近50PB的海量数据,那么淘宝是如何确保其网站的高可用的呢？

本文将对淘宝在构建大型网站过程中所使用到的技术框架做一个总结,并结合XX银行现有技术框架进行对比分析。

另外,本文还会针对金融互联网以及公司未来技术发展方向给出个人看法。

淘宝技术分析

CDN技术及多数据中心策略

国内的网络由于运营商不同〔分为电信、联通、移动,造成不同运营商网络之间的互访存在性能问题。

为了解决这个问题,淘宝在全国各地建立了上百个CDN节点,当用户访问淘宝网站时,浏览器首先会访问DNS服务器,通过DNS解析域名,根据用户的IP将访问分配到不同的入口。

如果客户的IP属于电信运营商,那么就会被分配到同样是电信的CDN节点,并且保证访问的〔这里主要指JS、CSS、图片等静态资源CDN节点是离用户最近的。

这样就将巨大的访问量分散到全国各地。

另外,面对如此巨大的业务请求,任何一个单独的数据中心都是无法承受的,所以淘宝在全国各主要城市都建立了数据中心,这些数据中心不但保证了容灾,而且各个数据中心都在提供服务。

不管是CDN技术还是多个数据中心,都涉及到复杂的数据同步,淘宝很好的解决了这个问题。

XX银行现在正在筹建两地三中心,但主要目的是为了容灾,数据中心的利用率差,而淘宝的多个数据中心利用率为100%。

LVS技术

淘宝的负载均衡系统采用了LVS技术,该技术目前由淘宝的章文嵩博士负责。

该技术可以提供良好的可伸缩性、可靠性以及可管理型。

只是这种负载均衡系统的构建是在Linux操作系统上,其他操作系统不行,并且需要重新编译Linux操作系统内核,对系统内核的了解要求很高,是一种软负载均衡技术。

而XX银行则通过F5来实现负载均衡,这是一种硬负载均衡技术。

Session框架

Session对于Web应用是至关重要的,主要是用来保存用户的状态信息。

但是在集群环境下需要解决Session共享的问题。

目前解决这个问题通常有三种方式,第一个是通过负载均衡设备实现会话保持,第二个是采用Session复制,第三个则是采用集中式缓存。

第二种方式严重制约了集群环境的可伸缩性,不利于集群的横向扩展,即使是采取两两复制也会造成集群内部网络负载严重,更别说采用广播的方式,会造成网络垃圾。

淘宝采用了第三种方式,因为第一种方式对于淘宝来说成本比较高,而且他们已经采用了LVS的负载均衡技术。

XX银行由于采用F5来实现负载均衡,所以第一种方式是必然选择。

HSF框架

HSF是淘宝的高性能服务框架,它是在淘宝进行应用拆分后诞生的。

应用拆分后,各系统变得更加"专业",因此产生了很多服务调用者和服务提供者。

HSF框架就是负责协调服务调用者与服务提供者之间的通讯。

服务提供者在启动时会向HSF框架的ConfigServer注册服务信息〔接口、版本、超时时间、序列化方式等,这样ConfigServer上面就定义了所有可供调用的服务〔同一个服务也可能有不同的版本；服务调用者启动时向ConfigServer注册对哪些服务感兴趣,当服务提供者的信息变化时,ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；服务调用者则根据服务信息列表直接访问相应的服务提供者,无需经过ConfigServer。

由于服务的提供者大多是集群,HSF还可以提供软负载均衡,引导服务调用者调用负载状况比较轻的服务提供者。

HSF的作用很像是XX银行的ESB,但是XX银行的ESB要求事先做好服务的注册工作,而不是在服务提供者启动时向ESB自动注册；服务调用者也是事先就知道ESB所提供的服务接口,而不是等到启动时向ESB注册需要的服务。

另外,XX银行的服务调用者和服务提供者之间的通讯必须经过ESB,也做不到对后端服务提供者进行软负载均衡,后端的服务提供者需要自己完成负载均衡。

可以看出HSF虽然在逻辑上将服务调用者与服务提供者进行了解耦,但是在实际操作上服务调用者和服务提供者是直接交互的,在通讯层面上并没有彻底解耦,如果服务调用者通讯协议改变,服务调用者也需要跟着改变,但是性能上的确比ESB要好。

Notify框架

对于通知类的解决方案,莫过于采取消息中间件技术。

Notify框架就是淘宝根据自身业务需要量身定制的一款消息中间件。

它的架构与HSF框架一样,也有一个ConfigServer。

消息的客户端〔NotifyClient通过ConfigServer订阅消息服务,消息的服务端〔NotifyServer在ConfigServer上注册消息服务。

为了保证消息一定能发出且对方也一定能收到,消息数据本身就需要记录下来,而这些消息则保存在数据库中。

在Notify框架中消息具有中间状态〔已发送、未发送等,所以应用系统可以通过Notify框架实现分布式事务。

说起消息中间件,XX银行采用的是WebLogicJMS和IBMMQ。

这两款消息中间件对消息的持久化是采用文件的形式保存在本地,WebLogicJMS的横向扩展依赖于WebLogic的横向扩展,而IBMMQ的集群部署比较麻烦。

而Notify框架可以很容易地进行横向扩展,处理大量的消息。

TDDL框架

一个大型网站在成长过程中,除了要对应用进行拆分外,还要对数据进行拆分。

数据拆分可以分为"垂直拆分"和"水平拆分"。

当数据库里有很多表,可以根据表之间的关联程度进行垂直拆分；当数据库的表的记录很多时,可以进行水平拆分。

通常情况下,数据拆分都指的是水平拆分。

但是数据拆分之后,会带来很多应用上的问题,例如应用程序需要知道哪些记录被拆分到了哪个数据库上,应用程序需要做很大的改动。

另外数据拆分也会不可避免地造成跨库查询,一旦跨库查询将严重损耗系统的性能。

为了解决以上问题,淘宝根据自身业务特点开发了TDDL框架,该框架屏蔽了数据拆分对应用程序的影响,通过缓存来解决跨库查询的问题,另外TDDL还支持搜索引擎。

XX银行由于业务量不大,还谈不上数据拆分。

TFS框架

在淘宝上有着大量的图片、商品描述以及评价信息,这些信息占据了淘宝的大部分数据存储。

而图片、商品描述、评价信息这种数据并不是传统意义上的结构化数据,用关系数据库或者一般的文件系统对这些数据进行存储并不合适。

这些非结构化数据特点是规模大、空间小,而对于大多数系统来说,最头疼的就是大规模小文件的读写,因为磁头需要频繁的寻道和换道,很容易带来延迟。

当并发量增大之后简直就是系统的噩梦。

为了解决这个问题,淘宝根据GFS〔GoogleFileSystem自主研发了TFS。

TFS在架构上和Hadoop很像,因为他们都源自GFS。

TFS由一对NameServer和多台DataServer构成,以Block文件的形式存放数据文件〔一个Block的大小一般为64MB,Block在多个DataServer上存储多份,这样做主要是为了冗余,保证数据安全。

NameServer主要是负责保存元数据,采取一对NameServer是为了避免单点失效。

应用程序在读写文件过程中直接与DataServer进行数据传输,不经过NameServer。

XX银行在运营中心项目中采用了TFS,用它来保存影像信息。

由于XX银行受限于业务要素,内部的数据大多是结构化数据,非结构化数据很少。

Tair框架

缓存技术在淘宝可谓是用到了极致,无论是前端的Web应用还是后端的业务处理都采用了缓存。

可以这么说,淘宝之所以能够提供如此高并发的访问,缓存技术的使用占了大头,把几乎所有能缓存的数据都缓存起来。

Tair框架是淘宝基于memcached开发的一款Key-Value缓存,由一个中心控制点和多个服务节点组成。

控制节点用来维护服务节点的状态信息,而服务节点用来提供各种数据服务。

目前为了保证可用性,中心控制点采用一主一备的形式部署。

XX银行并没有向淘宝这样一款全局性的缓存系统,缓存的使用情况也很少,即使使用也大多都局限于各个业务系统内部。

Hadoop技术

前面说过,Hadoop与TFS在架构上基本一样,所以淘宝对于Hadoop的使用重点放在了对大数据的分析处理上,这也正是Hadoop的强项,而TFS更专注于对非结构化数据的存储。

淘宝通过Dbsync框架来实现从Oracle、Mysql数据库向Hadoop实时同步数据,这种同步是以增量方式进行的；通过TimeTunnel2框架来实现从日志文件向Hadoop实时同步数据,也是以增量方式进行。

另外,又通过DataX将Oracle、Mysql数据库中的数据以全量非实时的方式同步到Hadoop当中。

Hadoop利用MapReduce将同步过来的数据进行分析处理,然后将结果再通过DataX传回给Oracle、Mysql数据库。

XX银行由于数据量小并且多为结构化数据,所以采用传统的数据仓库方式对数据进行联机分析处理〔OLAP。

另外,XX银行现在对数据的处理还停留在OLAP阶段,并没有深入到数据挖掘阶段。

搜索引擎技术

淘宝使用的搜索引擎技术与XX、Google这种通用搜索引擎不同,淘宝的搜索引擎更关注于网站自身的东西,例如商品搜索、店铺搜索等等。

所以,淘宝搜索引擎本质上是一款垂直搜索引擎。

淘宝的搜索引擎对时效性要求很高,例如,店铺发布了一款新的商品,不可能十几分钟之后还没有在搜索引擎上搜索到。

而XX、Google对时效性要求不高,当然这与通用搜索引擎采用的技术有关,一般来讲,通用搜索引擎是通过网络爬虫在网上搜索相关数据并建立索引供检索系统使用的,所以爬虫的收录周期决定了其时效性。

商品、店铺这些信息都是淘宝自身的数据,不需要网络爬虫,当这些数据生成时就可以建立索引供检索系统使用。

XX银行还没有自己的垂直搜索引擎,将来有必要在这方面进行投入。

总结

1.分布式

从以上的分析来看,淘宝在处理大并发、大数据的时候总体思路是分布式。

无论是应用拆分还是数据拆分都是分布式技术的运用。

淘宝基于HSF框架和Notify框架搭建了自己的分布式通讯系统；基于TDDL框架搭建了自己的分布式数据库系统；基于TFS框架搭建了自己的分布式文件系统；基于Tair框架搭建了自己的分布式缓存系统。

可见分布式是解决高并发、大数据的最有效手段。

XX银行目前根据业务也划分为很多系统,例如核心系统、信贷系统、卡系统、支付系统等,这本身就是分布式的思想。

遥想几年前采用的胖核心系统,什么都做什么都管,到现在的瘦核心系统只做账务处理,这不正是淘宝所做的应用拆分吗？

2.Scaleup与Scaleout

在谈这个问题之前我想先说一下数据拆分。

可能有人会说,即使一个表的记录有很多,我们不也可以通过分区来解决吗？

为什么非要数据拆分不可,弄得那么复杂。

这里我做下解释。

我们的确可以在RAC上通过分区技术来解决单表记录很多的问题,但是这里有一个瓶颈。

我们知道RAC虽然在实例上做到了可以横向扩展〔Scaleout,但是RAC的体系架构是共享存储结构,最终的压力会落到存储上。

如果随着数据量的增大导致已有存储空间不够用,IO成为瓶颈,就只能对存储进行升级〔Scaleup。

目前业内的主流思想是拥抱Scaleout,设法从Scaleup中解脱出来。

另外,之所以这样做也是出于成本的考量。

Scaleup不但成本会越来越高,而且有个天花板；而Scaleout可以采用大量廉价的PCServer来构建拥有强大计算能力和存储能力的机群〔这里不是集群,并且没有限制。

3.去IOE

这个问题其实与上个问题有很大的关联性,但是我想从另外一个角度来看去IOE。

在我看来,去IOE并不是完全抛弃IBM、Oracle、EMC的产品,而是在某些场景下去做这些事情。

通过对淘宝的分析,我发现淘宝也没有完全去IOE,在其关键性业务领域里还是使用了IOE的产品,例如跟账务有关的系统还是采用了RAC〔Oracle+小型机〔IBM+SAN〔EMC的体系结构。

去IOE还有另外一个目的,就是争取话语权。

对于XX银行来说,去IOE至少目前是不可行的,首先XX银行的大多数应用都是基于IOE的,如果进行去IOE成本和风险都太大。

另外去IOE是在大并发、大数据量的情况下才考虑实施,IOE是基于企业级应用的,而不是互联网应用,他们的产品横向扩展性都不够,而XX银行是典型的企业级应用,还没有达到互联网应用这样的程度。

接下来我们看看为什么我说XX银行不是面向互联网的。

互联网金融

在对淘宝的研究过程中,我的关注点并没有只停留在对它的技术研究上。

其实通过对淘宝技术发展史的了解,不难看出其背后所隐藏的"历史发展趋势"。

淘宝从一开始就将自身立足于互联网,也就是说它的客户完全来源于互联网。

它的技术是面向互联网,它的文化是面向互联网的,它的方方面面都是面向互联网的。

说起目前的互联网我不得不说说"Web2.0"。

那么什么是Web2.0呢？

Web2.0是相对Web1.0的新一类互联网应用的统称。

Web1.0的主要特点是用户通过浏览器获取信息,信息的主要来源为网站本身。

Web2.0则更注重与用户的互动,用户既是网站内容的浏览者,也是网站内容的创造者。

由被动地接收互联网信息向主动创造互联网信息发展,从而更加人性化。

在我看来Web2.0是真正的"以人文本",互联网金融其实说到底就是立足于互联网,将金融服务与Web2.0的思想进行有机的结合。

互联网金融就是我所说的"历史的发展所趋"。

Web2.0强调以用户为中心,我说马云干上了潮流,并不是说他创立了淘宝〔C2C、阿里巴巴〔B2C等电子商务平台,而是他所创造的这些东西都是面向Web2.0的。

Web2.0更注重用户体验,想客户之所想,忧客户之所忧,所以淘宝发展如此迅猛,短短10年时间成为全世界数一数二的电子商务平台,拥有数量极大的客户群。

其实对一家企业来说,最宝贵的财富不是钱,而是客户,谁拥有了客户谁就拥有了资本。

淘宝的客户群如此之大,马云可以利用其庞大的客户群做他想做的任何事。

例如马云现在就已经开始对其电子商户提供小微贷款,解决电子商户们一时的资金周转问题。

照这样发展下去,他可以在淘宝和阿里平台上促成个人与个人,个人与企业、企业与企业之间的小微贷款,而平台只是提供相关信息的服务,如提供信用等级和资质。

如果真有这么一天,那么银行的日子可就不好过了,在这种情况下假如我有闲钱我是不会存在银行的,把钱存给银行说到底是对银行进行放贷,有了像淘宝、阿里这样的平台能够进行直接放贷,需要钱的一方可以不经过银行直接进行融资,无论对借方还是贷方都是有益的。

银行没了存款还怎么活？

更何况中国的银行业普遍是靠存贷利息差活着的,中间业务不发达。

马云曾说过,如果银行不改变,那么我们改变银行。

这句话犹言在耳,可不是一时心血来潮。

放眼看看现阶段的银行业,死气沉沉,无所作为,无论在技术上还是业务上都被几个互联网巨头牵着鼻子走。

这是为什么？

就是因为传统的金融业是以业务为核心,而不是以客户为核心,这是业务驱动带来的必然结果。

在我看来,未来的金融领域是互联网金融的天下,所谓世界大势浩浩荡荡,顺之者昌,逆之者亡,银行作为传统金融业的"带头大哥",要想活下去,必须转型。

要想转型就必须立足于互联网,面向Web2.0,而不是像现在这样只是将互联网作为一个业务渠道〔网银、手机银行——这种做法是典型的业务驱动。

互联网金融对银行业来说既是挑战也是机遇,特别是像城商行这种小的商业银行,可以借着互联网金融这股趋势充分发展自己。

从业务上来说,像XX银行这种小型商业银行根本无法与国有四大行相抗衡,业务网点数比不了、存款比不了、业务范围比不了,等等。

但是在互联网上,大家都是平等的,并且谁先意识到互联网金融这个趋势,谁先做出改变,谁将走到前面,并且谁将最终活下来。

XX银行应当将未来的重心放在互联网上,立足于互联网还可以节省开设业务网点的成本,避免排队。

随着移动支付〔移动互联网金融的一种表现形式的逐渐普及,我相信有一天ATM、POS将会消失,银行卡也会逐渐退出历史舞台。

你能说支付宝是一张卡吗,但它却有着与银行卡同样的功能——目前支付宝不但可以作为个人结算工具,而且可以转账。

平安集团董事长前日又提出与马云、马化腾〔所谓三马同台合作,可以在淘宝和腾讯上销售保险和理财产品,淘宝随后也推出了自己的理财产品余额宝,可见未来的互联网金融是银行、电子商务、保险、证券的大一统,这些原本的行业界限将逐渐模糊,最终消失。

公司未来的技术走向

说了这么多,其实目前对于XX银行来说,淘宝的很多技术都用不上。

问题在于两者的立足点不一样,一个是企业级应用,一个是互联网应用。

那么公司作为XX银行的合作伙伴,在IT领域拥有较强的技术实力,应当引领客户认清形势,从传统的企业级应用向互联网应用转变。

既然互联网金融是大势所趋,那么公司就需要对相关技术进行储备,形成自己的产品。

我不建议公司对相关技术采取购买的策略,我更倾向于研发。

从下图可见,当公司规模发展到一定程度时,研发的投资回报率〔ROI要好于购买。

淘宝一开始也是采取购买,但随着自身的不断发展,很多现有技术都是自主研发的。

以下我将给出互联网金融所需要的相关技术。

1）基于SpringMVC的Web开发框架

2）工作流引擎和规则引擎技术

3）分布式技术〔分布式缓存、分布式数据库、分布式文件系统

4）云技术〔这里主要指私有云

5）大数据技术〔大数据存储、大数据分析

6）移动开发技术

7）搜索引擎技术〔这里主要指垂直搜索引擎

8）数据挖掘技术