淘宝的架构
淘宝用的是JBoss，框架是iBATIS，缓存服务器是自己开发的，基本遵循SNA架构，水平扩展，数据库是Oracle，阿里集团的DBA几乎是国内最强悍的。目前淘宝的系统架构正在重构，计划用两到三年时间重写，目标有两个：
1、水平扩展已经不满足需求了，还需要水平加垂直扩展
2、开放API，让店家可以把外部网站资源集成到淘宝，不必直接在淘宝开店
淘宝首席架构师是原来JBoss的Ben Wang，现在正在招募技术高手加盟，从事这项很有挑战性的工作：设计下一代开放性、支撑数十亿访问量的在线电子商务网站
淘宝架构更详细的情况就不方便透露了。
淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大 规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业 软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。
对于规模稍大的网站来说，其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. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件的移植。
对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定制，也能 够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡献者。而 作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。
淘宝网高性能可伸缩架构技术探秘
今天我们继续大型网站探秘，一起来探秘淘宝网的架构技术。作为国内最大的
B2C
网站，淘宝网的网站架构一直承载着数据量告诉增长压力，要保证良好的负载和流程的使用体验，一个可伸缩性的高性能网站架构必不可少。
一、应用无状态
一个系统的伸缩性的好坏取决于应用的状态如何管理。试想一下，假如我们在
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
服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。
二、有效使用缓存
做互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。
一般来说缓存根据与应用程序的远近程度不同可以分为：
local cache
和
remote cache
。 一般系统中要么采用
local cache
，要么采用
remote cache,
两者混合使用的话对 于
local cache
和
remote cache
的数据一致性处理会变大比较麻烦
.
在 大部分情况下
,
我 们所说到的缓存都是读缓存
,
缓存还有另外一个类型
:
写缓存
.
对于一些读写比不高，同时对数据安全性需求不高的数据，我们可以将其缓存起来从而减少对底层数据库的访问
,
比如 统计商品的访问次数
,
统 计
API
的调用量等等
,
可 以采用先写内存缓存然后延迟持久化到数据库，这样可以大大减少对数据库的写压力。
以店铺线的系统为例，在用户浏览店铺的时候，比如店铺介绍，店铺交流区页面，店铺服务条款页面，店铺试衣间页面，以及店铺内搜索界面这些界面更新不是非 常频繁，因此适合放到缓存中，这样可以大大减低
DB
的负载。另外宝贝详情页面相对也更新比较 少，因此也适合放到缓存中来减低
DB
负载。
三、应用拆分
首先，在说明应用拆分之前，我们先来回顾一下一个系统从小变大的过程中遇到的一些问题，通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期，用户数并不多，所有的逻辑也许都是放在一个系统中的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此将全部的逻辑都放在一个应用未尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户的需求，原有的系统需要增加新的功能进来，系统变得越来越复杂的时候，我们会发现系统变得越来越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），我们需要将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统，不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性
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
应用的全面使用
