《淘宝技术框架分析报告》由会员分享，可在线阅读，更多相关《淘宝技术框架分析报告（14页珍藏版）》请在金锄头文库上搜索。
1、淘宝技术框架分析报告 淘宝作为国内首屈一指的大型电子商务网站，每天承载近30亿PV的点击量，拥有近50PB的海量数据，那么淘宝是如何确保其网站的高可用的呢？本文将对淘宝在构建大型网站过程中所使用到的技术框架做一个总结，并结合吉林银行现有技术框架进行对比分析。另外，本文还会针对金融互联网以及公司未来技术发展方向给出个人看法。淘宝技术分析CDN技术及多数据中心策略国内的网络由于运营商不同（分为电信、联通、移动），造成不同运营商网络之间的互访存在性能问题。为了解决这个问题，淘宝在全国各地建立了上百个CDN节点，当用户访问淘宝网站时，浏览器首先会访问DNS服务器，通过DNS解析域名，根据用户的IP将访
2、问分配到不同的入口。如果客户的IP属于电信运营商，那么就会被分配到同样是电信的CDN节点，并且保证访问的（这里主要指JS、CSS、图片等静态资源）CDN节点是离用户最近的。这样就将巨大的访问量分散到全国各地。另外，面对如此巨大的业务请求，任何一个单独的数据中心都是无法承受的，所以淘宝在全国各主要城市都建立了数据中心，这些数据中心不但保证了容灾，而且各个数据中心都在提供服务。不管是CDN技术还是多个数据中心，都涉及到复杂的数据同步，淘宝很好的解决了这个问题。吉林银行现在正在筹建两地三中心，但主要目的是为了容灾，数据中心的利用率差，而淘宝的多个数据中心利用率为100%。LVS技术淘宝的负载均衡系统
3、采用了LVS技术，该技术目前由淘宝的章文嵩博士负责。该技术可以提供良好的可伸缩性、可靠性以及可管理型。只是这种负载均衡系统的构建是在Linux操作系统上，其他操作系统不行，并且需要重新编译Linux操作系统内核，对系统内核的了解要求很高，是一种软负载均衡技术。而吉林银行则通过F5来实现负载均衡，这是一种硬负载均衡技术。Session框架Session对于Web应用是至关重要的，主要是用来保存用户的状态信息。但是在集群环境下需要解决Session共享的问题。目前解决这个问题通常有三种方式，第一个是通过负载均衡设备实现会话保持，第二个是采用Session复制，第三个则是采用集中式缓存。第二种方式严
4、重制约了集群环境的可伸缩性，不利于集群的横向扩展，即使是采取两两复制也会造成集群内部网络负载严重，更别说采用广播的方式，会造成网络垃圾。淘宝采用了第三种方式，因为第一种方式对于淘宝来说成本比较高，而且他们已经采用了LVS的负载均衡技术。吉林银行由于采用F5来实现负载均衡，所以第一种方式是必然选择。HSF框架HSF是淘宝的高性能服务框架，它是在淘宝进行应用拆分后诞生的。应用拆分后，各系统变得更加“专业”，因此产生了很多服务调用者和服务提供者。HSF框架就是负责协调服务调用者与服务提供者之间的通讯。服务提供者在启动时会向HSF框架的ConfigServer注册服务信息（接口、版本、超时时间、序列化
5、方式等），这样ConfigServer上面就定义了所有可供调用的服务（同一个服务也可能有不同的版本）；服务调用者启动时向ConfigServer注册对哪些服务感兴趣，当服务提供者的信息变化时，ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；服务调用者则根据服务信息列表直接访问相应的服务提供者，无需经过ConfigServer。由于服务的提供者大多是集群，HSF还可以提供软负载均衡，引导服务调用者调用负载状况比较轻的服务提供者。HSF的作用很像是吉林银行的ESB，但是吉林银行的ESB要求事先做好服务的注册工作，而不是在服务提供者启动时向ESB自动注册；服务调用者也是事先就
6、知道ESB所提供的服务接口，而不是等到启动时向ESB注册需要的服务。另外，吉林银行的服务调用者和服务提供者之间的通讯必须经过ESB，也做不到对后端服务提供者进行软负载均衡，后端的服务提供者需要自己完成负载均衡。可以看出HSF虽然在逻辑上将服务调用者与服务提供者进行了解耦，但是在实际操作上服务调用者和服务提供者是直接交互的，在通讯层面上并没有彻底解耦，如果服务调用者通讯协议改变，服务调用者也需要跟着改变，但是性能上的确比ESB要好。Notify框架对于通知类的解决方案，莫过于采取消息中间件技术。Notify框架就是淘宝根据自身业务需要量身定制的一款消息中间件。它的架构与HSF框架一样，也有一个C
7、onfigServer。消息的客户端（Notify Client）通过ConfigServer订阅消息服务，消息的服务端（Notify Server）在ConfigServer上注册消息服务。为了保证消息一定能发出且对方也一定能收到，消息数据本身就需要记录下来，而这些消息则保存在数据库中。在Notify框架中消息具有中间状态（已发送、未发送等），所以应用系统可以通过Notify框架实现分布式事务。说起消息中间件，吉林银行采用的是WebLogic JMS和IBM MQ。这两款消息中间件对消息的持久化是采用文件的形式保存在本地，WebLogic JMS的横向扩展依赖于WebLogic的横向扩展，而
8、IBM MQ的集群部署比较麻烦。而Notify框架可以很容易地进行横向扩展，处理大量的消息。TDDL框架一个大型网站在成长过程中，除了要对应用进行拆分外，还要对数据进行拆分。数据拆分可以分为“垂直拆分”和“水平拆分”。当数据库里有很多表，可以根据表之间的关联程度进行垂直拆分；当数据库的表的记录很多时，可以进行水平拆分。通常情况下，数据拆分都指的是水平拆分。但是数据拆分之后，会带来很多应用上的问题，例如应用程序需要知道哪些记录被拆分到了哪个数据库上，应用程序需要做很大的改动。另外数据拆分也会不可避免地造成跨库查询，一旦跨库查询将严重损耗系统的性能。为了解决以上问题，淘宝根据自身业务特点开发了TD
9、DL框架，该框架屏蔽了数据拆分对应用程序的影响，通过缓存来解决跨库查询的问题，另外TDDL还支持搜索引擎。吉林银行由于业务量不大，还谈不上数据拆分。TFS框架在淘宝上有着大量的图片、商品描述以及评价信息，这些信息占据了淘宝的大部分数据存储。而图片、商品描述、评价信息这种数据并不是传统意义上的结构化数据，用关系数据库或者一般的文件系统对这些数据进行存储并不合适。这些非结构化数据特点是规模大、空间小，而对于大多数系统来说，最头疼的就是大规模小文件的读写，因为磁头需要频繁的寻道和换道，很容易带来延迟。当并发量增大之后简直就是系统的噩梦。为了解决这个问题，淘宝根据GFS（Google File Sys
10、tem）自主研发了TFS。TFS在架构上和Hadoop很像，因为他们都源自GFS。TFS由一对Name Server和多台Data Server构成，以Block文件的形式存放数据文件（一个Block的大小一般为64MB），Block在多个Data Server上存储多份，这样做主要是为了冗余，保证数据安全。Name Server主要是负责保存元数据，采取一对Name Server是为了避免单点失效。应用程序在读写文件过程中直接与Data Server进行数据传输，不经过Name Server。吉林银行在运营中心项目中采用了TFS，用它来保存影像信息。由于吉林银行受限于业务要素，内部的数据大多
11、是结构化数据，非结构化数据很少。Tair框架缓存技术在淘宝可谓是用到了极致，无论是前端的Web应用还是后端的业务处理都采用了缓存。可以这么说，淘宝之所以能够提供如此高并发的访问，缓存技术的使用占了大头，把几乎所有能缓存的数据都缓存起来。Tair框架是淘宝基于memcached开发的一款Key-Value缓存，由一个中心控制点和多个服务节点组成。控制节点用来维护服务节点的状态信息，而服务节点用来提供各种数据服务。目前为了保证可用性，中心控制点采用一主一备的形式部署。吉林银行并没有向淘宝这样一款全局性的缓存系统，缓存的使用情况也很少，即使使用也大多都局限于各个业务系统内部。Hadoop技术前面说过
12、，Hadoop与TFS在架构上基本一样，所以淘宝对于Hadoop的使用重点放在了对大数据的分析处理上，这也正是Hadoop的强项，而TFS更专注于对非结构化数据的存储。淘宝通过Dbsync框架来实现从Oracle、Mysql数据库向Hadoop实时同步数据，这种同步是以增量方式进行的；通过TimeTunnel2框架来实现从日志文件向Hadoop实时同步数据，也是以增量方式进行。另外，又通过DataX将Oracle、Mysql数据库中的数据以全量非实时的方式同步到Hadoop当中。Hadoop利用MapReduce将同步过来的数据进行分析处理，然后将结果再通过DataX传回给Oracle、Mys
13、ql数据库。吉林银行由于数据量小并且多为结构化数据，所以采用传统的数据仓库方式对数据进行联机分析处理（OLAP）。另外，吉林银行现在对数据的处理还停留在OLAP阶段，并没有深入到数据挖掘阶段。搜索引擎技术淘宝使用的搜索引擎技术与百度、Google这种通用搜索引擎不同，淘宝的搜索引擎更关注于网站自身的东西，例如商品搜索、店铺搜索等等。所以，淘宝搜索引擎本质上是一款垂直搜索引擎。淘宝的搜索引擎对时效性要求很高，例如，店铺发布了一款新的商品，不可能十几分钟之后还没有在搜索引擎上搜索到。而百度、Google对时效性要求不高，当然这与通用搜索引擎采用的技术有关，一般来讲，通用搜索引擎是通过网络爬虫在网上
14、搜索相关数据并建立索引供检索系统使用的，所以爬虫的收录周期决定了其时效性。商品、店铺这些信息都是淘宝自身的数据，不需要网络爬虫，当这些数据生成时就可以建立索引供检索系统使用。吉林银行还没有自己的垂直搜索引擎，将来有必要在这方面进行投入。总结1. 分布式从以上的分析来看，淘宝在处理大并发、大数据的时候总体思路是分布式。无论是应用拆分还是数据拆分都是分布式技术的运用。淘宝基于HSF框架和Notify框架搭建了自己的分布式通讯系统；基于TDDL框架搭建了自己的分布式数据库系统；基于TFS框架搭建了自己的分布式文件系统；基于Tair框架搭建了自己的分布式缓存系统。可见分布式是解决高并发、大数据的最有效
15、手段。吉林银行目前根据业务也划分为很多系统，例如核心系统、信贷系统、卡系统、支付系统等，这本身就是分布式的思想。遥想几年前采用的胖核心系统，什么都做什么都管，到现在的瘦核心系统只做账务处理，这不正是淘宝所做的应用拆分吗？2. Scale up与Scale out 在谈这个问题之前我想先说一下数据拆分。可能有人会说，即使一个表的记录有很多，我们不也可以通过分区来解决吗？为什么非要数据拆分不可，弄得那么复杂。这里我做下解释。我们的确可以在RAC上通过分区技术来解决单表记录很多的问题，但是这里有一个瓶颈。我们知道RAC虽然在实例上做到了可以横向扩展（Scale out），但是RAC的体系架构是共享存
16、储结构，最终的压力会落到存储上。如果随着数据量的增大导致已有存储空间不够用，IO成为瓶颈，就只能对存储进行升级（Scale up）。目前业内的主流思想是拥抱Scale out，设法从Scale up中解脱出来。另外，之所以这样做也是出于成本的考量。Scale up不但成本会越来越高，而且有个天花板；而Scale out可以采用大量廉价的PC Server来构建拥有强大计算能力和存储能力的机群（这里不是集群），并且没有限制。3. 去IOE这个问题其实与上个问题有很大的关联性，但是我想从另外一个角度来看去IOE。在我看来，去IOE并不是完全抛弃IBM、Oracle、EMC的产品，而是在某些场景下去做这些事情。通过对淘宝的分析，我发现淘宝也没有完全去IOE，在其关键性业务领域里还是使用了IOE的产品，例如跟账务有关的系统还是采用了RAC（Oracle）+小型机（IBM）+SAN（EMC）的体系结构。去IOE还有另外一个目的，就是争取话语权。对于吉林银行来说
