淘宝网架构分享总结

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

一、为什么stateless比较有利于实现水平伸缩

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

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

但是相对于有状态，stateless是更好的，主要有3个原因：

1、负载均衡不需要做session绑定，也就可以用更简单的算法，比如随机、取模等，把请求分配到任意server上，因此相对于session绑定的做法，性能会比较好

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

3、如果某一台server down掉了，后续的请求就没法继续往这台server发了，影响可用性

二、为什么淘宝开发session框架

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

所以session还是要用的，但是如果session都放在app server里，stateless就不容易实现了，而且为了HA，还涉及到session迁移的问题，会比较复杂。所以淘宝自己搞了一个session框架出来

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

三、关于TFS

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

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

四、淘宝子应用之间的集成，为什么不使用ESB

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

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

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

五、特性开关和优雅降级

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

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

六、分布式的好处

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

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

我觉得不尽然，有时候分布式应该还是能提升性能的，对于那种CPU密集型的计算来说。比如NASA不是有一个项目，是利用很多个人PC，来计算小行星数量还是什么的。这个好像又叫啥网格计算。不过，我们做的大多都是企业应用，或者互联网应用，因此基本上CPU不是瓶颈（瓶颈主要在IO）；由于业务逻辑的关系，也很难说就能拆分成可并行的子任务，所以场景不太满足。因此对于曾先生的这个看法，我还是相当认可的

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

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

2、提升开发效率。淘宝把一个应用拆分成很多子应用以后，就可以实现“小团队维护小应用”，做到了“专人专事”，效率比较高。此外，小应用显而易见，也更容易维护

3、实现“差异化水平伸缩”。这个词是我自己瞎造的。考虑这种场景，数据库只能支持10个连接，但是需要20个系统才能支撑http并发。那么这时候应该部署几套应用来组成集群呢？10个肯定不行，并发撑不住；但是20个也不行，因为每个应用都直接连数据库，又超过了数据库连接的上限

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

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

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

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

七、数据库的水平伸缩

相对于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的方案，互为补充

八、关于虚拟化

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

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

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

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

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

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

九、OSGi在淘宝内部的使用

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

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

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

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

我个人觉得，除了明显增加开发复杂度之外，OSGi还有一个问题，就是和java ee规范的兼容性，离完美还是相去甚远。就连最简单的一个问题，“OSGi框架与servlet框架嵌套”，现在虽然有方案，但是同样相当复杂。我觉得对于OSGi，目前还是保持适度的关注就可以了

十、去IOE化，后续的趋势

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

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

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

十一、总结

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

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

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

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

反观我司，现在动辄就100多号人做一个小产品，想用数量弥补质量的不足。实际上我觉得反而是降低了效率（这些产品我觉得10个人左右的小团队，完全可以做得更好），同时也造就了大量的领导岗位，催生了各种流程，进一步降低了效率

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

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

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

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

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

楼主是如何去参加这次分享会的？

顶楼主,很好的分享,很务实,
很多地方都把 问题,方案及原因 都说了,并且简单明了.

  和

这两个东西就很能体现楼主下面说的:


请求多了,一台机器不够用了,想要弄两台,
那就得平衡下负载,还有 2个的请求要能分配到2个机器上,前后没关联,那么就得无状态,
还得让一个挂了另外一个能接着用,但是又要依赖 Session ,那就再弄个 Session 托管的地方.



TDDL 这就是把过来的SQL 分解, 根据路由再查对应的数据源.

现在大公司都有各种平台各种数据源,往往一个请求要去多个地方调用数据,再数据拼接,完成 ORM 的动作.
这样的设计也能满足这种情况,其实很多公司都有 TDDL 这样的层,或者说这样的动作.

还有 这个东西.
现在搞个项目,不论大小,不论多少用户,
模块化啊,易拆分啊,什么的概念都来上,否则体现不出来设计水平,这就是浮夸啊.

但是要拥有这些能力,是要在前期对有什么模块有足够好的分层.
有 90% 的项目都是边做边加功能模块.造成依赖混乱,
osgi 这个东西,没有好的,稳定的规划前提下,依赖混乱会让开发时很难搞,
怎么说呢,明天看起来很美好,但今天,只能呵呵呵呵了.

我不清楚一个项目做出来后,模块拆分出去的情况有多少,
有那个负载要求的时候,一般刚开始就分开做,没那个要求,大多是过度的设计.
而从 无要求 到 有要求 这个期间,恐怕原来做的已经不符合业务了.

神也是人.懂的多,就不会太专, 太专一,就不会懂很多.
阿里这个神, 也是几个会的多的加上一群专一的组成的.

alipay 里, 吐槽  sofa osgi 那个东西的不知道有多少...

分布式在通讯方面是降低性能的，如曾说的“分布式只会把本地调用变成RPC，带来额外的传输损耗”。不过在CPU和IO方面是会提升性能的，毕竟原来在一个物理设备上执行的东西现在由多个设备来完成了。

采用分布式的真正原因我认为不是什么重用，效率这些。因为分布式后实际上把一些问题都复杂化了。原本在一台机器上的程序，你不需要考虑通讯，同步，分布式后这些都要考虑。一个原因是金钱，分布式后可以用一些廉价机器代替哪些昂贵的大中型机了。还有个原因是大中型机器和Oracle这些大型商业数据库都有上限，总有撑不住的那一天。

朋友，你说的这个是集群，不是分布式，2个概念你搞混了

重用和效率的价值很大的，你可能没理解到。举个例子，不说淘宝这么大的应用吧，就我以前做过的一个系统，有8个子系统组成，难道要实现8次用户和权限管理？所以把这块独立出来，为业务系统提供服务。这还只是8个子系统的小应用，业务逻辑也很简单，重用就可以体现出价值了

效率的价值也很明显，你试试带一个30人的团队，还是带一个4,5个人的小组，实际带一段时间，你就会发现明显的不同

不同意，分布式由于有多台机器，将部分的计算分配到别的机器上，反而充分的利用多台机器的CPU，RPC也不一定会比本地慢，原因在于本地的CPU资源有限，IO等待等；并且快和慢本身就是一个相对的概念，如果这种慢是可接受的慢，例如RPC操作只比本地慢1、2ms，那么这种慢是不影响用户体验的。


我认为分布式的好处其实很多，重用、性能，开发效率，可维护性，系统可用性、价格都算是，分布式的好处是可以把“一大件事”分成“小而美”的若干部分。
分布式的缺点是，如果是项目不大，用户量不多，采用分布式，反而会使问题复杂话，即上面的优点，都变成了缺点；
分布式的难点是，如何对项目进行合理的切分，使之达到良好的性能；
所以问题的关键不是分布式好不好，而是看项目，项目是否需要分布式，如何进行项目切分。
关于分布式，baidu以前有个哥们写过一个介绍性的文章，写的挺好，不过好像是现在找不到了。

我认为分布式的好处其实很多，重用、性能，开发效率，可维护性，系统可用性、价格都算是

2、Session的问题，其实不难解决，只需要在Filter里把Session的访问做一下Wrapper，把数据放到远程内存服务器上，淘宝用Tair，就可以实现Session共享了。
3、TFS的确没有那么夸张，只是为了解决文件的快速存取和备份，特别是小文件，与HDFS的设计有很大区别。
6、华黎那天估计不是这样简单说降低性能，估计是大部分情况下，一般的应用，分布式只会降低性能，特别是单机还不成为瓶径的时候。 其实分布式更多是为了服务化，包括可用性，不停机维护等，而且系统大到一定程度，不分布式，就只能上小机了，成本也是原因。
7、TDDL不方便细说，但数据分布，很多时候，难点往往不在技术上，而在业务上。如果数据分散了，你的查询怎么处理，你的FailOver怎么做，FailOver之后的数据回迁，你对可用性的要求等等。
9、早在很久以前就说过，OSGi只适合一个小组的人全是高手，因为用好OSGi，需要对JVM很多内容有深入了解，否则全是坑。

楼主总结的很不错，赞一个
关于第六条的分布式，从单机部署到服务化现在又回归单机，仿佛应验了三国演义的开篇词。回归单机部署多系统的理由也很简单，在超高的并发压力之下，服务调用的传输开销已经无法被忽视。如果我没记错的话，我们这边的核心系统这个开销大概在200ms左右。将相关系统（不是全部）部署在一台服务器上，压测发现吞吐量有非常显著提升。