5.8架构设计原则案例分析

date

comments

淘宝

注，以下部分内容摘自淘宝技术发展。

淘宝技术发展主要经历了个人网站 oracle支付宝旺旺 Java1.0时代，Java2.0时代，Java3.0时代，以及最后的分布式时代。我们看看每个阶段的主要驱动力是什么。

一、个人网站

2003年4月7日马云提出成立淘宝，2003年5月10日淘宝就上线了，中间只有一个月是怎么做到的，淘宝的答案就是买一个网站，估计那部分人很难想象，如今技术牛气冲天的阿里，最初的淘宝竟然是买来的一个简单的php网站，我们看看当初做决策的依据。

当时对整个项目组来说压力最大的就是时间，怎么在这段的时间内把一个从来就没有的网站从0开始建立起来，了解淘宝历史的人知道淘宝是在2003年5月10日上线的，这之间只有一个月，要是你在这个团队，你怎么做？我们的答案，就是只能买一个。

淘宝当时在初创时没有过多考虑技术是否优越，性能是否海量，以及稳定性和主要的考虑因素，就是要尽快上线。

因为此时业务要求快速，商店时间不等人，等你花几个月甚至十几个月搞出一个强大的系统出来，可能市场机会就没有了。

当决定是买的方案之后，那就是考虑如何买买哪个。

买一个网站显然比做一个网站要省事一些，但是他们的梦想可不是做一个小网站而已，要做大就不是随便买个就行的，要有比较低的维护成本，要能够方便的扩展和进行二次开发。

所以答案就是要买一个轻量级的，尽量简单一点的网站。

买了一个系统是为了快速可用而买一个轻量级的系统，是为了快速开发，因为新的网站上线后肯定有大量的需求需要做，这时候能够快速开发是非常重要的。

从这个案例我们可以看到，淘宝最开始的时候业务要求就是要快,因此反过来要求技术同样要快,业务决定技术，这里架构设计和选择主要遵从的是合适原则和简单原则。

二、Oracle支付宝旺旺

淘宝退出后，由于正好碰到非典网购很火爆，加上采取了成功的市场运作，流量和交易量迅速上涨，业务发展很快，在2003年底mysql就撑不住了。

一般人或者团队小企业在这个时候可能就开始优化系统优化架构分拆业务了，因为这些是大家耳熟能详的很拿手的动作，那我们来看看淘宝这个时候是怎么采取措施优化的。

其实他们采用的替代方案非常简单，就是换成Oracle，原因是除了它容量大稳定安全性能高，还有就是这Oracle方面的人才比较多。

也就是说这个时候淘宝的策略还是买买更高配置的oracle，这个是当时情况下最快的方法，除了购买奥瑞克，后来为了优化又买了更强强大的存储。

为什么他要在这个时候继续采用买的方式来快速解决问题呢？我们可以从时间上看出端倪，此时离刚上线才半年不到，业务飞速发展最快的方式，支撑业务的发展还是去买。如果说第一阶段买的是方案，这个阶段买的就是性能，这里架构设计和选择主要是遵循的还是合适原则和简单原则。

三、脱胎换骨的Java时代1.0

淘宝从PHP切换到JAVA的原因很简单，主要是因为找了一个php的开源连接池——SQL RELAY,连接到Oracle，可是这个连接池经常出现死锁的情况，一旦系统死锁了，就必须重启，数据库又必须用oracle，于是决定换个开发语言，最后淘宝选择了Java语言，而且当时还请来了sun公司(当时还没被oracle收购)的人，这帮人很厉害，先是将淘宝php热切换到了java，后来又做了支付宝。

这次技术切换的最主要原因是技术影响了业务的发展，频繁的思索和重启对于用户业务产生了严重的影响，从业务角度来看，这已经是不得不解决的问题了。

淘宝一贯都是通过买的方式去解决，但这次为什么没有去买呢？我们来看当初选择sql realy的原因。

php语言是放在apache服务器上的，每一个请求都会对数据库产生一个连接，它没有连接池的功能，java语言有serverlet容器可以存放链接池,这时候怎么抉择呢?.他们又打听了Ebey在php下面用了一个连接池工具，是BEA卖给他们的,BEA的东西，特别的贵，他们买不起，于是就在网上找了找，找了一个开源的连接池代理服务SQL RELAY.

可见他们当初也并没有所谓的高瞻远瞩，也是一步一步逼着做出来的,能省的也尽量省。

四、坚若磐石的java2.0时代

Java 时代 2.0，淘宝做了很多优化工作：数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss。为什么在这个时候要做这些动作？原文作者很好地概括了做这些动作的原因：

这些杂七杂八的修改，我们对数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的。

这个时候淘宝的超高并发量，已经不是可以靠买就能解决的了。而且这个时候，买的代价太大，我记得又一次马云在接收采访的时候提到，当时算了下按照当时业务发展速度，将来几年光是买服务器的前都能把淘宝高破产。这就是“量变带来质变”的一个典型案例，业务和系统发生质变后，架构设计遵循“演化原则”的思想，需要再一次重构甚至重写。

五、Java3.0时代和分布式时代

Java 时代 3.0 我个人认为是淘宝技术飞跃的开始，简单来说就是淘宝技术从商用转为“自研”，典型的就是去 IOE 化。分布式时代我认为是淘宝技术的修炼成功，到了这个阶段，自研技术已经自成一派，除了支撑本身的海量业务，也开始影响整个互联网的技术发展.

到了这个阶段，业务规模急剧上升后，原来并不是主要复杂度的 IOE 成本开始成为了主要的问题，因此通过自研系统来降低 IOE 的成本，去 IOE 也是系统架构的再一次演化。

腾讯QQ

注：以下部分内容摘自《QQ 1.4 亿在线背后的故事》。

QQ 的发展历程按照用户规模可以粗略划分为 4 个阶段：十万级、百万级、千万级、亿级，不同的用户规模，IM 后台的架构也不同，而且基本上都是用户规模先上去，然后产生各种问题，倒逼技术架构升级。

一、十万级 IM 1.X

最开始的手机 QQ 后台是这样的，可以说是简单得不能再简单、普通得不能再普通的一个架构了，因为当时业务刚开始，架构设计遵循的是“合适原则”和“简单原则”。如下图所示

二、百万级 IM 2.X

随着业务发展到 2001 年，QQ 同时在线人数也突破了一百万。第一代架构很简单，明显不可能支撑百万级的用户规模，主要的问题有：

以接入服务器的内存为例，单个在线用户的存储量约为 2KB，索引和在线状态为 50 字节，好友表 400 个好友 × 5 字节 / 好友 = 2000 字节，大致来说，2GB 内存只能支持一百万在线用户。
CPU/ 网卡包量和流量 / 交换机流量等瓶颈。
单台服务器支撑不下所有在线用户 / 注册用户。

于是针对这些问题做架构改造，按照“演化原则”的指导进行了重构，重构的方案相比现在来说也还是简单得多，因此当时做架构设计时也遵循了“合适原则”和“简单原则”。IM 2.X 的最终架构如下图所示

三、千万级 IM 3.X

业务发展到 2005 年，QQ 同时在线人数突破了一千万。第二代架构支撑百万级用户是没问题的，但支撑千万级用户又会产生新问题，表现有：

同步流量太大，状态同步服务器遇到单机瓶颈。
所有在线用户的在线状态信息量太大，单台接入服务器存不下，如果在线数进一步增加，甚至单台状态同步服务器也存不下。
单台状态同步服务器支撑不下所有在线用户。
单台接入服务器支撑不下所有在线用户的在线状态信息。

针对这些问题，架构需要继续改造升级，再一次“演化”。IM 3.X 的最终架构如下图，可以看到这次的方案相比之前的方案来说并不简单了，这是业务特性决定的。

四、亿级 IM 4.X

业务发展到 2010 年 3 月，QQ 同时在线人数过亿。第三代架构此时也不适应了，主要问题有：

灵活性很差，比如“昵称”长度增加一半，需要两个月；增加“故乡”字段，需要两个月；最大好友数从 500 变成 1000，需要三个月。
无法支撑某些关键功能，比如好友数上万、隐私权限控制、PC QQ 与手机 QQ 不可互踢、微信与 QQ 互通、异地容灾。
除了不适应，还有一个更严重的问题：IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的，但是持续打补丁已经难以支撑亿级在线，IM 后台 4.0 必须从头开始，重新设计实现！

重新设计的 IM 4.0 架构如图所示，和之前的架构相比，架构本身都拆分为两个主要的架构：存储架构和通信架构。

总结

通过淘宝和手机 QQ 这两个典型互联网业务的架构发展历程，我们可以看出，即使是现在非常复杂、非常强大的架构，也并不是一开始就进行了复杂设计，而是首先采取了简单的方式（简单原则），满足了当时的业务需要（合适原则），随着业务的发展逐步演化而来的（演化原则）。罗马不是一天建成的，架构也不是一开始就设计成完美的样子，然后可以一劳永逸一直用下去。