淘宝网架构

淘宝用的是JBoss，框架是iBATIS，缓存服务器是本身开发的，基本遵循SNA架构，水平扩展，数据库是Oracle，阿里集团的DBA几乎是国内最强悍的。目前淘宝的系统架构正在重构，计划用两到三年时间重写，目标有两个：

一、水平扩展已经不知足需求了，还须要水平加垂直扩展
二、开放API，让店家能够把外部网站资源集成到淘宝，没必要直接在淘宝开店

淘宝首席架构师是原来JBoss的Ben Wang，如今正在招募技术高手加盟，从事这项颇有挑战性的工做：设计下一代开放性、支撑数十亿访问量的在线电子商务网站，有意着能够和我联系，向我投递简历： fankai@gmail.com

淘宝架构更详细的状况就不方便透露了。

淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大 规模的一个网站，我猜测你们必定会很是关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是彻底采用的商业 软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。

对于规模稍大的网站来讲，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模 的网站而言，就是应用也分红不少组。那么下面，我就从应用服务器操做系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。

操做系统
咱们首先就从应用服务器的操做系统提及。一个应用服务器，从软件的角度来讲他的最底层首先是操做系统。要先选择操做系统，而后才是操做系统基础上的应用软 件。在淘宝网，咱们的应用服务器上采用的是Linux操做系统。Linux操做系统从1991年第一次正式被公布到如今已? ? 走过了十七个年头，在PC Server上有普遍的应用。硬件上咱们选择PC Server而不是小型机，那么Server的操做系统供咱们选择的通常也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。若是不许备采用微软的一系列产品构建应用，而且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么仍是应该在Linux和 FreeBSD之间进行选择。能够说，如今Linux和FreeBSD这两个系统难分伯仲，很难说哪一个必定比另一个要优秀不少、可以全面的超越对手，应 该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪一种系统更加的熟悉，这个熟悉一方面是系统管理方面，另一方面是对于内核的熟悉，对内 核的熟悉对于性能调优和对操做系统进行定制剪裁会有很大的帮助。而应用全面的优化、提高性能也是从操做系统的优化开始的。

应用服务器
在肯定了服务器的硬件、服务器的操做系统以后，下面咱们来讲说业务系统的构建。淘宝网有不少业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么咱们要选择一款实现了JEE规范的应用服务器。咱们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，若是采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择通常也就 是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了如今，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给如今的开发人员提供了更多的选择。具体对于目 前JEE应用服务器的比较。这边就不在赘述。
在应用服务器前端，咱们采用了Web Server作了一次转发，咱们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的惟一选择。那个时候虽然也有一些其余的开源的Web Server，可是从功能和稳定性上来讲都没法和Apache相对。在今天来讲，Lighty也会是一个很是好的选择。Lighty是一个很是轻量级、占 用内存资源也比较少的Web Server。虽然功能上没有Apache强大，可是在很多场景下，性能是很是出色、强于Apache的。而微软的IIS，就只能工做在Windows的 系统上了。而且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。

数据库
说完了咱们采用的操做系统、应用服务器、WebServer后，下面就来谈谈咱们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一个是 Oracle公司的Oracle 10g，另一个是Sun MySQL的MySQL。Oracle是一款优秀的、普遍采用的商业数据库管理软件。有很强大的功能和安全性，能够处理相对海量的数据。而MySQL是一 款很是优秀的开源数据库管理软件，很是适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也很是的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，经过MySQL自身的Replication或者应用自身的处理，能够很好的保证容错(容许部分节点失 效)，保证应用的健壮性和可靠性。能够这么说，在关系数据库管理系统的选择上，能够考虑应用自己的状况来决定。
一个互联网应用，除了服务器的操做系统，Web Server软件，应用服务器软件，数据库软件外，咱们还会涉及到一些其余的系统，好比一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。 在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。可是，考虑到淘宝网本身的需求和 大并发量的压力，这些系统都选择了自主开发。

开发框架
前面谈的都是系统级的产品，下面咱们说说开发框架的使用。可能有朋友想问，做为一个如此大规模的网站，淘宝网的Web展示层采用的是什么框架，是怎么实现 的呢？曾? ? 也有到淘宝的应聘者问过我这个问题，他问我说是否是用的 struts。我告诉他说不是的。其实淘宝网的Web展示层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展示层的框架用的是集团内部自主开发的一套Web框架。这个框架可以解决一些其余Web框架不能解决的、在淘宝的应用中又会出 现并须要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，好比Spring、iBatis、jBPM、Hessian、Mina等等。这些开源 软件的采用为咱们构建应用系统提供了很大的帮助。
采用开源软件构建系统，我想有两个很大的好处：
一个是下降成本。假设你有1000 台应用服务器，若是你每台服务器上采用的不是JBoss AS或者其余开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是很是高的。
另一个好处(我以为最大的好处)是你能够看到软件的源码，你能够研究了解软件内部的工做过程、原理。这对于应用设计、开发、查错、优化都是很是有帮助的。

淘宝网的开源观
对于开源软件的应用，有些人可能担忧质量的问题，有些人可能担忧软件自己发展更新的问题，等等。对于质量的问题，我想如今不少的开源软件尤为是一些很著名 的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有屡次的测试版本发布，最后才是正式版。这和商业软件是同样的。而且 由于代码公开，反而更加的容易发现错误，提升质量。至于第二个问题，我想跟第一个问题同样，关键是组织和规划而不在是否开源，而且在不少著名的开源软件背 后，会有厂商在进行支持。软件自己的发展应该是不会成为问题的，不太会出现软件忽然中止发展的状况。
在从此的发展中，咱们仍是会一如既往的关注开源软件的发展，也还会根据须要采用不一样的开源软件。在选择一个开源产品的时候，我会考虑如下几点：
1. 这个软件目前的功能和它的RoadMap
2. 软件自己的架构
3. 该软件开发的活跃度
4. 该开源软件是不是遵照该领域内的国际规范的
5. 在同类产品中，要挑选有比较优点的。而且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其余软件的移植。
对于企业级系统、互联网应用来讲，采用开源软件不只能够下降成本，更重要的是可以真正了解软件的内部工做机制。还能够在如今的基础上进行加强和定制，也能 够从开源软件中借鉴到不少好的设计和实现。但愿国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者可以成为一些开源软件的贡献者。而 做为淘宝网，咱们也会很是积极的参与到开源的活动中，也会努力为开源的发展作出咱们应有的贡献。

淘宝网高性能可伸缩架构技术探秘
文章转载自网管之家：http://www.bitscn.com/pdb/php/201007/188788.html

今天咱们继续大型网站探秘，一块儿来探秘淘宝网的架构技术。做为国内最大的B2C网站，淘宝网的网站架构一直承载着数据量告诉增加压力，要保证良好的负载和流程的使用体验，一个可伸缩性的高性能网站架构必不可少。
1、应用无状态

一个系统的伸缩性的好坏取决于应用的状态如何管理。试想一下，假如咱们在session中保存了大量与客户端的状态信 息的话，那么当保存状态信息的server宕机的时候，咱们怎么办？一般来讲，咱们都是经过集群来解决这个问题，而一般 所说的集群，不只有负载均衡，更重要的是要有失效恢复failover,好比tomcat采 用的集群节点广播复制，jboss采 用的配对复制等session状 态复制策略，可是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能经过增长更多的机器来达到良好的水平伸缩，由于集群节点间 session的 通讯会随着节点的增多而开销增大，所以要想作到应用自己的伸缩性，咱们须要保证应用的无状态性，这样集群中的各个节点来讲都是相同的，从而是的系统更好的 水平伸缩。

上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥做用了。幸运的是公司已经具备了此类框架。公司的 session框架采用的是client cookie实现，主要将状态 保存到了cookie里 面，这样就使得应用节点自己不须要保存任何状态信息，这样在系统用户变多的时候，就能够经过增长更多的应用节点来达到水平扩展的目的.但 是采用客户端cookie的 方式来保存状态也会遇到限制，好比每一个cookie通常不能超过4K的大小，同时不少浏览器都限制一个站点最 多保存20个cookie.公司cookie框 架采用的是“多值cookie”， 就是一个组合键对应多个cookie的 值，这样不只能够防止cookie数 量超过20， 同时还节省了cookie存 储有效信息的空间，由于默认每一个cookie都会有大约50个字节的元信息来描述cookie。

除了公司目前的session框 架的实现方式之外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点链接一个session 服 务器，session服 务器将session保 存到缓存中，session服 务器后端再配有底层持久性数据源，好比数据库，文件系统等等。

2、有效使用缓存

作互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。

通常来讲缓存根据与应用程序的远近程度不一样能够分为：local cache 和 remote cache。 通常系统中要么采用local cache，要么采用remote cache,二者混合使用的话对 于local cache和remote cache的数据一致性处理会变 大比较麻烦.

在 大部分状况下,我 们所说到的缓存都是读缓存,缓存还有另一个类型:写缓存. 对 于一些读写比不高，同时对数据安全性需求不高的数据，咱们能够将其缓存起来从而减小对底层数据库的访问,好比 统计商品的访问次数,统 计API的 调用量等等,可 以采用先写内存缓存而后延迟持久化到数据库，这样能够大大减小对数据库的写压力。

以店铺线的系统为例，在用户浏览店铺的时候，好比店铺介绍，店铺交流区页面，店铺服务条款页面，店铺试衣间页面，以及店铺内搜索界面这些界面更新不 是非 常频繁，所以适合放到缓存中，这样能够大大减低DB的负载。另外宝贝详情页面相对也更新比较 少，所以也适合放到缓存中来减低DB负载。

3、应用拆分

首先，在说明应用拆分以前，咱们先来回顾一下一个系统从小变大的过程当中遇到的一些问题，经过这些问题咱们会发现拆分对于构建一个大型系统是如何的重要。

系统刚上线初期，用户数并很少，全部的逻辑也许都是放在一个系统中的，全部逻辑跑到一个进程或者一个应用当中，这个时候由于比较用户少，系统访问量 低，所以 将所有的逻辑都放在一个应用何尝不可。可是，兄弟们都清楚，好景不长，随着系统用户的不断增长，系统的访问压力愈来愈多，同时随着系统发展，为了知足用户 的需求，原有的系统须要增长新的功能进来，系统变得愈来愈复杂的时候，咱们会发现系统变得愈来愈难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那 么这个时候咱们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），咱们须要将原来的系统根据必定的标准，好比业务相关性等分为不一样的子系统， 不一样的系统负责不一样的功能，这样切分之后，咱们能够对单独的子系统进行扩展和维护，从而提升系统的扩展性和可维护性，同时咱们系统的水平伸缩性scale out大大的提高了，由于咱们能够有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统，而不会像拆分之前，每次系统压力变大的时候，咱们都 须要对整 个大系统进行伸缩，而这样的成本是比较大的，另外通过切分，子系统与子系统之间的耦合减低了，当某个子系统暂时不可用的时候，总体系统仍是可用的，从而整 体系统的可用性也大大加强了。

所以一个大型的互联网应用，确定是要通过拆分，由于只有拆分了，系统的扩展性，维护性,伸缩性，可用性才会变的更好。可是拆分也给系 统带来了问题，就是子系统之间如何通讯的问题，而具体的通讯方式有哪些呢？通常有同步通讯和异步通讯，这里咱们首先来讲下同步通讯，下面的主题“消息系 统”会说到异步通讯。既然须要通讯，这个时候一个高性能的远程调用框架就显得很是总要啦，所以我们公司也有了本身的HSF框 架。

上面所说的都是拆分的好处，可是拆分之后必然的也会带来新的问题，除了刚才说的子系统通讯问题外，最值得关注的问题就是系统之间的依赖关系，由于系 统多了， 系统的依赖关系就会变得复杂，此时就须要更好的去关注拆分标准，好比可否将一些有依赖的系统进行垂直化，使得这些系统的功能尽可能的垂直，这也是目前公司正 在作的系统垂直化，同时必定要注意系统之间的循环依赖，若是出现循环依赖必定要当心，由于这可能致使系统连锁启动失败。

既然明白了拆分的重要性，咱们看看随着公司的发展，公司自己是如何拆分系统的。

在这个演变的过程当中，咱们所说的拆分就出现V2.2和V3.0之间。在V2.2版 本中，公司几乎全部的逻辑都放在一个系统中，这样致使的问题就是系统扩展和修改很是麻烦，而且更加致命的是随着公司业务量的增 加，若是按照V2.2的 架构已经没有办法支撑之后公司的快速发展，所以你们决定对整个系统进行拆分，V3.0版本的系统对整个系统进行了水平和垂直 两个方向的拆分，水平方向上，按照功能分为交易，评价，用户，商品等系统，一样垂直方向上，划分为业务系统，核心业务系统以及以及基础服务，这样以来，各 个系统均可以独立维护和独立的进行水平伸缩，好比交易系统能够在不影响其它系统的状况下独立的进行水平伸缩以及功能扩展。

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

淘宝网架构师岳旭强的年度展望

2009年是挑战和机遇并存的一年，对大部分人来讲，已经习惯了金融危机，并努力解决危机。在技术圈子也同样，被裁人的确定也找到了工做，因此都在踏实作技术。言归正传，先念叨念叨2009年的一些故事，寻个回忆，找个乐子。

数据扩展性探讨和总结
金融危机是电子商务的机遇，因此09年是淘宝高速发展的一年。当一个网站从百万、千万记录的数据规模，增加到亿、十亿、几十亿记录的数据规模时，是一个量 变到质变的过程，单纯的硬件升级已经达到了瓶颈，而须要在总体结构上作文章。09年一年，大部分时间都在数据的扩展性上努力。

对于一个电子商务网站来说，订单是最核心的数据，也是增加最快的数据。对于数据的扩展性来说，最传统也是最简单有效的模式是数据库的分库分表。当订 单和分库分表相遇，会有什么火花迸发出来？09年初碰撞了好久，结果产生的火花很小。最大的问题在于数据分割的规则，无规则的水平分割确定会带来数据合并 的开销，而按照业务规则拆分，会由于买家和卖家的查询需求不一样而致使数据不能分割，惟一可行的火花是把订单双份保存，买家卖家各自一份，只是成本比较高， 并且对数据同步的要求很是高。

因而咱们初步决定按照双份保存的方式拆分订单，而有一天，仔细查看了订单访问的状况，发现订单数据库90%以上的压力来自于查询，而查询中90%以上的压力来自于非核心业务，仅仅是订单数据的展示，对一致性和实时性的要求很低。

由于数据量大，形成数据库压力大，自然想到的是分散压力，其办法就是分库分表。有些时候咱们想问题不妨直接一点，既然压力大，能不能减少压力呢？通 过对订单访问状况的了解，发现昂贵的主数据库，有80%以上的压力给了不重要的需求，这个就是咱们优化的关键，因此订单最后采用了读写分离的方案，高成本 的主数据库解决事务和重要的查询业务，80%以上不重要的读，交给了低成本的数据库服务器来解决，同时对数据复制的要求也很低，实现无太大难度。

另一个有意思的案例是商品的数据扩容，商品的水平分割很是容易，按照卖家进行拆分便可。有了订单的先例，首先想到了读写分离，由于成本能够作低。 开始实施后一段时间，又仔细回想了一下商品的总体需求，忽然发现商品其实不须要和订单同等的要求，必定要采用高成本的主数据库吗？ 所有采用低成本的普通服务器来作数据库是否可行？通过仔细的评估，发现是能够接受的，而这样就致使以前已经启动的商品读写分离项目的一部分工做白作了！

故事讲完了老是要有点总结，来点虚的先：对于原始需求的清晰了解是系统决策的前提，不然弯路确定要走，而对原始需求的了解并不容易，中间会有不少干 扰和阻力，前面的实例看起来很简单，可是在一个运行了5年的系统上来了解本质，来进行变动，并没那么容易。另外，经验有些时候会成为系统决策的障碍，这个 很矛盾，因此须要有归零的心态来思考问题。说到底，回归本源。

再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是很是必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路 由、复制、合并、搬迁、热点处理等功能，而且要对应用透明，应用针对性的，能够在JDBC层面包装，数据库针对性的，能够在数据库协议层包装，好比 Amoeba。

关注系统和人的交互
还有一个故事，在数据层的前期版本，为了作到透明的路由，曾经采用无SQL的方式，全部的数据库访问都是写代码来作。上线后发现一个很是痛苦的问题，没法 和SQL对应，排错很是难。曾经一次DBA发现数据库上一个查询耗费太多资源，把优化后的SQL给开发人员改进，开发人员好几天没找到具体是哪一个查询。

另一个在2009年的感触是业界服务化的实施状况，不少组织都在实施服务化，系统层面都很成功，通讯、负载均衡、消息系统、服务容器等都有不少成 果，可是实施一段时间之后的效果并非很是好，依赖复杂，变动混乱，效率低下。究其根本，是对人的关注不够，缺乏的产品化的服务运维，缺乏服务治理。

上面的两个例子都是对人的关注缺失，技术人员作系统，大部分都更关注技术，而忽视技术的创造者和使用者——人。软件或服务的可测试性是对测试人员的 关注、可维护性和可管理性是对运维人员的关注，而一个框架的易用性是对全部使用人员的关注。除非能作出本身进化的Skynet（注：Skynet（天网） 出如今《终结者》系列电影中，是一我的类于20世纪后期创造的以计算机为基础的人工智能防护系统，最初是研究用于军事的发展。天网在控制了全部的美军的武 器装备后不久，得到自我意识，而且认定人类是它存在的威胁。因而马上倒戈对抗其创造者，采用大规模杀伤性武器（甚至核暴）来灭绝全人类。），不然仍是要多 关注系统和人的交互。

关注可用性
还有一个感触是业界对可用性这个基本指标的关注度不够。几乎全部的框架都会说本身的扩展性多高，性能多好，而不多会提到监控有多强、排错有多容易，不多提 到在故障时怎么作隔离，怎么作降级；从这个角度看，商用的产品确实作得好不少；关于性能相关的文章搜索一下，不少，各类优化策略，各类优化方法，而可用性 方面，找到的系统性的知识真的不多；但愿是我了解的很少。

回顾过去，展望将来。2010年，不少能够作的事情，面向服务系统的隔离和降级、系统可维护性的提升、协程和异步模式在web应用的全面使用……