淘宝网采用什么技术架构来实现网站高负载的

从上图可以看出V3.0版 本的系统对整个系统进行了水平和垂直两个方向的拆分，水平方向上，按照功能分为交易，评价，用户，商品等系统，同样垂直方向上，划分为业务系统，核心业务系统以及以及基础服务，这样以来，各个系统都可以独立维护和独立的进行水平伸缩，比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩展。

从上面可以看出，一个大型系统要想变得可维护，可扩展，可伸缩，我们必须的对它进行拆分，拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题，关于通信方面，淘宝目前独立开发了自己的高性 能服务框架HSF， 此框架主要解决了淘宝目前所有子系统之间的同步和异步通信(目前HSF主要用于同步场合，FutureTask方 式的调用场景还比较少)。至于系统间的依赖管理，目前淘宝还做的不够好，这应该也是我们以后努力解决的问题。

四 数据库拆分(TDDL)

在前面“应用拆分”主题中，我们提到了一个大型互联网应用需要进行良好的拆分，而那里我们仅仅说了”应用级别”的拆 分，其实我们的互联网应用除了应用级别的拆分以外，还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统，通常就是所说的RDBMS进 行拆分。

好了，确定了这个小节的主题之后，我们回顾一下，一个互联网应用从小变大的过程中遇到的一些问题，通过遇到的问题来引出我们拆分RDBMS的 重要性。

系 统刚开始的时候，因为系统刚上线，用户不多，那个时候，所有的数据都放在了同一个数据库中，这个时候因为用户少压力小，一个数据库完全可以应付的了，但是随着运营那些哥们辛苦的呐喊和拼命的推广以后，突然有一天发现，oh,god,用户数量突然变多了起来，随之而 来的就是数据库这哥们受不了，它终于在某一天大家都和惬意的时候挂掉啦。此时，咱们搞技术的哥们，就去看看究竟是啥原因，我们查了查以后，发现原来是数据库读取压力太大了，此时咱们都清楚是到了读写分离的时候，这个时候我们会配置一个server为master节 点，然后配几个salve节 点，这样以来通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统终于又恢复了正常，开始正常运行了。但是好景还是不长，有一天我们发现master这哥们撑不住了，它负载老高了，汗 流浃背，随时都有翘掉的风险，这个时候就需要咱们垂直分区啦(也就是所谓的分库)，比如将商品信息，用户信息，交易信息分别存储到不同的数据库中，同时还可以针对商品信息的库采用master，salve模式，OK， 通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样数据库的压力终于有恢复到正常状态。但是是不是这样，我们就可以高枕无忧了呢?NO,这个NO， 不是我说的，是前辈们通过经验总结出来的，随着用户量的不断增加，你会发现系统中的某些表会变的异常庞大，比如好友关系表，店铺的参数配置表等，这个时候无论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，因此此时就需要我们进行“水平分区”了(这就是俗话说的分表，或者说sharding).

OK,上 面说了一大堆，无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”，一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库)，然后再到水平分区(分表，sharding)的过程，而在这个过程中，Master/salve 以 及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查 询数据，如何平衡各个shards的 负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。

拿淘宝目前的情况来说，淘宝目前也正在从昂贵的高端存储(小型机+ORACLE)切换到MYSQL,切 换到MYSQL以 后，势必会遇到垂直分区(分库)以及水平分区(Sharding)的问题，因此目前淘宝根据自 己的业务特点也开发了自己的TDDL框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制

五 异步通信(Notify)

在”远 程调用框架”的 介绍中,我 们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是 拆分了以后,子 系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节 中,我 们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既 然说到了异步通信,那 么”消 息中间件”就 要登场了,采 用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.

说 到异步通信，我们需要关注的一点是这里的异步一定是根据业务特点来的，一定是针对业务的异步，通常适合异步的场合是一些松耦合的通信场合，而对于本身业务上关联度比较大的业务系统之间，我们还是要采用同步通信比较靠谱。

OK,那 么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想，假如系统有A和B两个 子系统构成，假如A和B是 同步通信的话，那么要想使得系统整体伸缩性提高必须同时对A和B进行 伸缩，这就影响了对整个系统进行scale out.其次，同步调用还会影响到可用性，从数学推理的角度来说，A同 步调用B， 如果A可 用，那么B可 用，逆否命题就是如果B不 可用，那么A也 不可用，这将大大影响到系统可用性，再次，系统之间异步通信以后可以大大提高系统的响应时间，使得每个请求的响应时间变短，从而提高用户体验，因此异步在提高了系统的伸缩性以及可用性的同时，也大大的增强了请求的响应时间(当然了，请求的总体处理时间也许不会变少)。

下面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很多其它的业务系统交互，如果在一次交易过程中采用同步调用的话，这就要求要向交易成功，必须依赖的所有系统都可用，而如果采用异步通信以后，交易系 统借助于消息中间件Notify和 其它的系统进行了解耦，这样以来当其它的系统不可用的时候，也不会影响到某此交易，从而提高了系统的可用性。

最后，关于异步方面的讨论，我可以 推荐大家一些资源：

1 . J2EE meets web2.0

2. Ebay架构特点(HPTS 2009)

六 非结构化数据存储 ( TFS,NOSQL)

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!