淘宝技术框架分析实施报告.docxVIP

- . z 淘宝技术框架分析报告 淘宝作为国内首屈一指的大型电子商务，每天承载近30亿PV的点击量，拥有近50PB的海量数据，则淘宝是如何确保其的高可用的呢.本文将对淘宝在构建大型过程中所使用到的技术框架做一个总结，并结合**银行现有技术框架进展比照分析。另外，本文还会针对金融互联网以及公司未来技术开展方向给出个人看法。 淘宝技术分析 CDN技术及多数据中心策略 国内的网络由于运营商不同〔分为电信、联通、移动〕，造成不同运营商网络之间的互访存在性能问题。为了解决这个问题，淘宝在全国各地建立了上百个CDN节点，当用户访问淘宝时，浏览器首先会访问DNS效劳器，通过DNS解析域名，根据用户的IP将访问分配到不同的入口。如果客户的IP属于电信运营商，则就会被分配到同样是电信的CDN节点，并且保证访问的〔这里主要指JS、CSS、图片等静态资源〕CDN节点是离用户最近的。这样就将巨大的访问量分散到全国各地。另外，面对如此巨大的业务请求，任何一个单独的数据中心都是无法承受的，所以淘宝在全国各主要城市都建立了数据中心，这些数据中心不但保证了容灾，而且各个数据中心都在提供效劳。不管是CDN技术还是多个数据中心，都涉及到复杂的数据同步，淘宝很好的解决了这个问题。**银行现在正在筹建两地三中心，但主要目的是为了容灾，数据中心的利用率差，而淘宝的多个数据中心利用率为100%。 LVS技术 淘宝的负载均衡系统采用了LVS技术，该技术目前由淘宝的章文嵩博士负责。该技术可以提供良好的可伸缩性、可靠性以及可管理型。只是这种负载均衡系统的构建是在Linu*操作系统上，其他操作系统不行，并且需要重新编译Linu*操作系统内核，对系统内核的了解要求很高，是一种软负载均衡技术。而**银行则通过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上注册消息效劳。为了保证消息一定能发出且对方也一定能收到，消息数据本身就需要记录下来，而这些