淘宝技术框架分析报告(精编文档).doc

【最新整理，下载后即可编辑】

淘宝技术框架分析报告

淘宝作为国内首屈一指的大型电子商务网站，每天承载近30亿PV的点击量，拥有近50PB的海量数据，那么淘宝是如何确保其网站的高可用的呢？本文将对淘宝在构建大型网站过程中所使用到的技术框架做一个总结，并结合吉林银行现有技术框架进行对比分析。另外，本文还会针对金融互联网以及公司未来技术发展方向给出个人看法。

淘宝技术分析

CDN技术及多数据中心策略

国内的网络由于运营商不同（分为电信、联通、移动），造成不同运营商网络之间的互访存在性能问题。为了解决这个问题，淘宝在全国各地建立了上百个CDN节点，当用户访问淘宝网站时，浏览器首先会访问DNS服务器，通过DNS解析域名，根据用户的IP将访问分配到不同的入口。如果客户的IP属于电信运营商，那么就会被分配到同样是电信的CDN节点，并且保证访问的（这里主要指JS、CSS、图片等静态资源）CDN节点是离用户最近的。这样就将巨大的访问量分散到全国各地。另外，面对如此巨大的业务请求，任何一个单独的数据中心都是无法承受的，所以淘宝在全国各主要城市都建立了数据中心，这些数据中心不但保证了容灾，而且各个数据中心都在提供服务。不管是CDN 技术还是多个数据中心，都涉及到复杂的数据同步，淘宝很好的解决了这个问题。吉林银行现在正在筹建两地三中心，但主要目的是为了容灾，数据中心的利用率差，而淘宝的多个数据中心利用率为100%。

LVS技术

淘宝的负载均衡系统采用了LVS技术，该技术目前由淘宝的章文嵩博士负责。该技术可以提供良好的可伸缩性、可靠性以及可管理型。只是这种负载均衡系统的构建是在Linux操作系统上，其他操作系统不行，并且需要重新编译Linux操作系统内核，对系统内核的了解要求很高，是一种软负载均衡技术。而吉林银行则通过F5来实现负载均衡，这是一种硬负载均衡技术。

Session框架

Session对于Web应用是至关重要的，主要是用来保存用户的状态信息。但是在集群环境下需要解决Session共享的问题。目前解决这个问题通常有三种方式，第一个是通过负载均衡设备实现会话保持，第二个是采用Session复制，第三个则是采用集中式缓存。第二种方式严重制约了集群环境的可伸缩性，不利于集群的横向扩展，即使是采取两两复制也会造成集群内部网络负载严重，更别说采用广播的方式，会造成网络垃圾。淘宝采用了第三种方式，因为第一种方式对于淘宝来说成本比较高，而且他们已经采用了LVS的负载均衡技术。吉林银行由于采用F5来实现负载均衡，所以第一种方式是必然选择。

HSF框架

HSF是淘宝的高性能服务框架，它是在淘宝进行应用拆分后诞生的。应用拆分后，各系统变得更加“专业”，因此产生了很多服务调用者和服务提供者。HSF框架就是负责协调服务调用者与服务提供者之间的通讯。服务提供者在启动时会向HSF框架的ConfigServer注册服务信息（接口、版本、超时时间、序列化方式等），这样ConfigServer上面就定义了所有可供调用的服务（同一个服务也可能有不同的版本）；服务调用者启动时向

ConfigServer注册对哪些服务感兴趣，当服务提供者的信息变化时，ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；服务调用者则根据服务信息列表直接访问相应的服务提供者，无需经过ConfigServer。由于服务的提供者大多是集群，HSF还可以提供软负载均衡，引导服务调用者调用负载状况比较轻的服务提供者。HSF的作用很像是吉林银行的ESB，但是吉林银行的ESB要求事先做好服务的注册工作，而不是在服务提供者启动时向ESB自动注册；服务调用者也是事先就知道ESB所提供的服务接口，而不是等到启动时向ESB注册需要的服务。另外，吉林银行的服务调用者和服务提供者之间的通讯必须经过ESB，也做不到对后端服务提供者进行软负载均衡，后端的服务提供者需要自己完成负载均衡。可以看出HSF虽然在逻辑上将服务调用者与服务提供者进行了解耦，但是在实际操作上服务调用者和服务提供者是直接交互的，在通讯层面上并没有彻底解耦，如果服务调用者通讯协议改变，服务调用者也需要跟着改变，但是性能上的确比ESB要好。

Notify框架

对于通知类的解决方案，莫过于采取消息中间件技术。Notify 框架就是淘宝根据自身业务需要量身定制的一款消息中间件。它的架构与HSF框架一样，也有一个ConfigServer。消息的客户端（Notify Client）通过ConfigServer订阅消息服务，消息的服务端（Notify Server）在ConfigServer上注册消息服务。为了保证消息一定能发出且对方也一定能收到，消息数据本身就需要记录下来，而这些消息则保存在数据库中。在Notify框架中消息具有中间状

态（已发送、未发送等），所以应用系统可以通过Notify框架实现分布式事务。说起消息中间件，吉林银行采用的是WebLogic JMS和IBM MQ。这两款消息中间件对消息的持久化是采用文件的形式保存在本地，WebLogic JMS的横向扩展依赖于WebLogic 的横向扩展，而IBM MQ的集群部署比较麻烦。而Notify框架可以很容易地进行横向扩展，处理大量的消息。

TDDL框架

一个大型网站在成长过程中，除了要对应用进行拆分外，还要对数据进行拆分。数据拆分可以分为“垂直拆分”和“水平拆分”。当数据库里有很多表，可以根据表之间的关联程度进行垂直拆分；当数据库的表的记录很多时，可以进行水平拆分。通常情况下，数据拆分都指的是水平拆分。但是数据拆分之后，会带来很多应用上的问题，例如应用程序需要知道哪些记录被拆分到了哪个数据库上，应用程序需要做很大的改动。另外数据拆分也会不可避免地造成跨库查询，一旦跨库查询将严重损耗系统的性能。为了解决以上问题，淘宝根据自身业务特点开发了TDDL 框架，该框架屏蔽了数据拆分对应用程序的影响，通过缓存来解决跨库查询的问题，另外TDDL还支持搜索引擎。吉林银行由于业务量不大，还谈不上数据拆分。