【转发】淘宝网架构分享总结

发表时间：2013-07-04   最后修改：2013-07-04

上周六参加了一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。而后立刻就出差了，一直没来得及总结，今晚比较有空，把此次听到的比较有启发的观点记录一下 

1、为何stateless比较有利于实现水平伸缩 

关于什么是stateless的扫盲，见这个贴：http://kyfxbl.iteye.com/blog/1831869 

通常有一个共识，就是把应用作成无状态的，会比较容易实现水平伸缩。可是之前一直有一个想法，就算应用是有状态的，也能够作成水平伸缩：只须要在负载均衡那里作一个session绑定就能够了，根据某种标识，把请求固定地发送到特定的server上 

可是相对于有状态，stateless是更好的，主要有3个缘由： 

一、负载均衡不须要作session绑定，也就能够用更简单的算法，好比随机、取模等，把请求分配到任意server上，所以相对于session绑定的作法，性能会比较好 

二、也是性能的问题，在7层网络模型中，session位于第7层，负载均衡若是是基于session的算法来决定要怎么分发请求，性能的损耗也会比较大 

三、若是某一台server down掉了，后续的请求就无法继续往这台server发了，影响可用性 

2、为何淘宝开发session框架 

若是将请求所需的信息，都放在cookie里，确实就不须要session框架了，并且也比较容易实现stateless。可是cookie也有本身的问题，cookie的大小是有限制的，还会增大网络流量（对于淘宝这种规模的应用，绝对不是一个小数），而且数据放在客户端，多少有点不安全 

因此session仍是要用的，可是若是session都放在app server里，stateless就不容易实现了，并且为了HA，还涉及到session迁移的问题，会比较复杂。因此淘宝本身搞了一个session框架出来 

具体的实现就不清楚，不过知道了这个思路，也不是很困难。我猜应该相似于把session集中放在session server里，其余的app server都来共享就能够了。而后将session server作成集群，避免单点故障。同时session迁移的事情，也就转化成了集群的迁移 

3、关于TFS 

在《淘宝技术这10年》这本书里，“淘宝大学”的校长神话了这个技术。那天据曾宪杰先生说，TFS只是比较擅长处理小而多的零散文件，单机部署时性能也不是很好，可是在集群部署时，性能和可用性，确实有一点优点 

这块我没有怎么研究过，当天曾先生也没有深刻讲，不是很了解，就很少说了 

4、淘宝子应用之间的集成，为何不使用ESB 

淘宝在11年左右开始拆分应用，走“服务化”方向以后，应用拆分了不少个独立的子应用（大约有1000个左右） 

这么多的应用要在一块儿完成业务，势必涉及到集成的问题。可是淘宝没有使用ESB，而是用了自研的服务框架和消息中间件 

这主要是由于ESB更擅长处理异构系统的集成，而淘宝这将近1000个应用，基本都是JAVA应用，因此ESB的这个优点不明显；另外，增长机器水平伸缩，是淘宝的杀手锏，若是采用ESB架构的话，那在水平伸缩的时候，就连ESB那层也要一块儿伸缩，比较麻烦 

5、特性开关和优雅降级 

稍微提到了一点，即在应用中放一些开关，在流量告警的时候，关闭一些功能，以主动避让的方式，避免系统压力过大而不可用。我理解相似于丢卒保车，在万不得已的时候，牺牲一些次要的业务，保护主要的业务 

具体的实现没有提到，目前好像咱们也没碰到过这种场景，先简单记录一下 

6、分布式的好处 

我本来认为，在知足条件的状况下，分布式架构会提高性能（条件是CPU是性能的瓶颈，以及大的任务能够分割成可并行的多个子任务） 

不过那天曾宪杰先生反对这个见解，他认为分布式只会把本地调用变成RPC，带来额外的传输损耗，因此不但不会提高性能，反而在大多数场景下，会下降性能 

我以为不尽然，有时候分布式应该仍是能提高性能的，对于那种CPU密集型的计算来讲。好比NASA不是有一个项目，是利用不少我的PC，来计算小行星数量仍是什么的。这个好像又叫啥网格计算。不过，咱们作的大多都是企业应用，或者互联网应用，所以基本上CPU不是瓶颈（瓶颈主要在IO）；因为业务逻辑的关系，也很难说就能拆分红可并行的子任务，因此场景不太知足。所以对于曾先生的这个见解，我仍是至关承认的 

那么，既然分布式对于性能有减无增，为何还要用分布式呢，总结了下面3个缘由： 

一、组件复用。这个很好理解，就不用多说了 

二、提高开发效率。淘宝把一个应用拆分红不少子应用之后，就能够实现“小团队维护小应用”，作到了“专人专事”，效率比较高。此外，小应用显而易见，也更容易维护 

三、实现“差别化水平伸缩”。这个词是我本身瞎造的。考虑这种场景，数据库只能支持10个链接，可是须要20个系统才能支撑http并发。那么这时候应该部署几套应用来组成集群呢？10个确定不行，并发撑不住；可是20个也不行，由于每一个应用都直接连数据库，又超过了数据库链接的上限 

若是实现了分布式，那么就能够这样：部署10个service server，来链接数据库，对上层提供服务；部署20个app server，来响应http请求，不直接链接数据库。挺巧妙的，架构上也挺有美感 

固然，数据库的链接数上限确定不仅是10个，上面只是打个比方。从侧面也看出，淘宝的业务量大到了一个超乎我想象的程度——竟然连数据库的链接都不够用了 

同时，这么多子系统要调来调去，是很复杂的（1000个子系统，想一想都以为很复杂）。因此淘宝开发了服务框架和消息中间件，来解决这个问题。或者说，正是先行一步有了这些基础框架，服务化拆分的路才能走得比较顺畅 

另外一方面，分布式架构也是有坏处的。好比部署和调试都变得复杂了，淘宝有专门的运维工具和开发工具，来减小这种痛苦。提到了一个google的Dapper，和淘宝自研的eagle eye。有须要的时候能够研究下 

7、数据库的水平伸缩 

相对于app的水平伸缩，数据库伸缩是比较复杂的。由于RDBMS本质上是单机系统。虽然能够部署N台db server组成集群，可是主要是保证了HA，也支撑更多的链接数。可是若是单个数据库里的数据量太大的话，读写都会变得很慢，仍是瓶颈 

最后没有别的选择，只能拆表，好比把user拆分红user1和user2（拆分的维度能够不少，基本上是水平拆分）。这就带来2个问题，第一是编程变得复杂了，简单的ORM+jdbc就搞不定了；第二就须要开始处理数据迁移的问题 

针对这2个问题，淘宝的答案是，用TDDL作数据库路由，对上层应用保持透明；开发专门的迁移工具，在拆表后作数据迁移（尽量缩短业务中断的时间） 

TDDL没有开源，相似的有一个叫cobar的框架 

大致的思路应该是这样的。原本应用的DAL层，直接就创建在JDBC之上，JDBC去连具体的数据库 

 

可是这样的话，应用就依赖底层的数据库。当须要查询一条数据的时候，应用须要知道应该去哪一个表（或者哪一个数据库）里查询；在数据库伸缩的时候，应用的代码也要跟着改才行。这样确定是不大好的 

因此，在DAL和JDBC之间，又增长了一层，也就是TDDL 

 

如今，DAL再也不是直接依赖JDBC，而是依赖TDDL。数据库路由的功能，都在TDDL里完成，底层数据库伸缩的时候，也是在TDDL里进行“配置”，应用的代码不须要变化。果真是应了那句话，“计算机的问题，大多能够经过增长一个抽象层来解决” 

TDDL的实现不清楚，也没有开源。不过我猜想应该也是封装成一个DataSource，适配JDBC规范，这样其上的ORM框架，也就能够直接使用了。而后在TDDL内部，会去解析SQL，处理配置文件（数据库路由），而且依赖厂商JDBC的实现，去真正链接底层的数据库 

总的来讲，淘宝这个基于TDDL的方案，仍是在解决RDBMS水平伸缩的问题。应该也正在引进NOSQL的方案，互为补充 

8、关于虚拟化 

淘宝内部也用到了虚拟机，也就是私有云。大体有几个好处： 

一、硬件一虚多，提高硬件利用率，降成本 

二、应用和具体硬件隔离，便于维护 

三、硬件的内存太大时，JVM对内存的管理不是很好，不如把一台硬件虚拟化成多个虚拟机 

淘宝很是重视对硬件和应用情况的监控，好像因为历史遗留缘由，监控的工具不少是针对单个进程的。因此目前常见的作法，是一台虚拟机上只启一个JVM（单进程），和过去的监控工具相兼容（这里没有详细说，恰好那会我也有点累了，听得不是很仔细，不知道有没有理解错） 

另外淘宝用的虚拟化工具是linux container，好像跟VMware那套解决方案也不太同样，不是彻底的虚拟机，而是更轻量级的硬件资源的隔离，后面能够再研究一下 

9、OSGi在淘宝内部的使用 

如今基本不怎么用了，OSGi主要的价值，在实际中体现得不太明显 

好比类隔离，用更简单的自定义ClassLoader也能够实现；单机多版本服务，用的场景也不多；热部署也不是很实用 

可是，基于OSGi框架作开发，复杂度的上升又是显而易见的。所以，用很高的代价，只能换来较少的收益，在开发人员之间推进很困难，渐渐地就不怎么用了 

咱们以前的一个产品，也是相似的状况。公司内部一个平台，三年前的一个主要卖点就是OSGi架构，好处也就是OSGi官方宣传的那一套，而如今最新的版本也在“去OSGi化”，有一种走了弯路的感受 

我我的以为，除了明显增长开发复杂度以外，OSGi还有一个问题，就是和java ee规范的兼容性，离完美仍是相去甚远。就连最简单的一个问题，“OSGi框架与servlet框架嵌套”，如今虽然有方案，可是一样至关复杂。我以为对于OSGi，目前仍是保持适度的关注就能够了 

10、去IOE化，后续的趋势 

这一节原本不想写，是关于淘宝去IOE化，以及后续的技术规划。感受没有什么新东西，可是大领导就喜欢听这些。仍是先记一下，后面写胶片说不定有用 

淘宝有一个动做是去IOE（IBM的小型机、Oracle数据库、EMC高端存储）。早期的淘宝，主要靠的是高端硬件，思路就是用钱解决问题。可是这样作的成本很高，淘宝的业务规模又扩张得太快，因此要用更经济的方案。用PC Server、MySQL数据库等，经过大量廉价的硬件，水平伸缩组成集群，来替代昂贵的硬件，思路就是用技术解决问题。跟google的思路一致 

淘宝V4.0的几个技术趋势：页面组件化、私有云部署、多终端。没有什么新东西，实际上咱们2012年也在考虑这几个规划，那天听到曾宪杰先生说淘宝也想作这么几件事，我以为有点惊讶，怎么这么巧。实际上咱们产品目前的规模（并发和数据量），连淘宝的零头都不到，所以也不是很急迫，应该是预研性质的 

11、总结 

本文大体记录了那天的收获，有些内容很受启发；另一些当前不太用得上，先记录下来留着之后再想一想 

总的来讲，我对曾宪杰先生的水平很佩服，淘宝架构师确实是名不虚传 

此外还有一些技术以外的感悟，主要有2点 

一成天的交流下来，我能感觉到淘宝一种很务实的精神，我感受这是我司目前所缺乏的。曾先生屡次提到“先work，再优化”、“当时也没想那么多，只是先解决问题，否则就死了”、“专人专事，小团队负责小系统”，我以为很朴实，可是颇有道理 

反观我司，如今动辄就100多号人作一个小产品，想用数量弥补质量的不足。实际上我以为反而是下降了效率（这些产品我以为10我的左右的小团队，彻底能够作得更好），同时也造就了大量的领导岗位，催生了各类流程，进一步下降了效率 

还很喜欢搞“架构”，花了不少的资源，最终却没有在产品中落地，带来什么业务价值，只是把产品作得更烂，同时制造了一些“专家” 

我以为淘宝也有这个趋势。公司慢慢大了，优越感就来了，夸夸其谈的风气慢慢也滋生了。只能说，并非话多声音大的就是专家，各人有各人的活法。我的感受，淘宝慢慢也会走向我司目前的状态，可能这是大公司的通病，也是人的通病。。 

另一个感想，就是以为淘宝如今有这么一批技术高手，很大程度上是业务造就的。所谓时势造英雄，业务规模不断扩大，逼迫技术必须进步，解决业务问题，反过来也促进了业务的发展 

而做为早期的淘宝技术人员，见招拆招，解决各类技术问题，慢慢也就成为了高手。因此，应该要认可淘宝技术的强大，可是也要客观看待，不必盲目神话和崇拜。淘宝作的也就是一个规模巨大的商城，不是原子弹或人类基因图谱什么的 

再次感谢曾宪杰先生，水平很棒，表达得也很好。下次有相似的机会，还会去参加