从0开始学架构_10_09_架构设计原则案例
你好，我是华仔。
今天我和你分享的主题是架构设计原则的案例。
周二，我给你介绍了架构设计的三条核心原则，先复习一下。
这三个原则是合适原则、简单原则和演化原则，即们在架构设计实践中应该时刻谨记这三条设计原则，直到我们设计出合适的架构。
即使是代表中国互联网技术最顶尖水平的BAT,其架构的发展历程也同样遵循这三条原则。
今天呢我就以大家耳熟能详的淘宝和手机QQ作为案例来简单分析一下。
先来介绍一下淘宝的案例。
我会结合淘宝技术发展文章里的内容，从中给你解读架构设计的原则。
这部分设计各阶段的架构图，你可以点击文稿查看淘宝技术发展，主要经历了个人网站到oracle支付宝旺旺，再到扎马时代一点零、扎马时代二点零、扎马时代三点零以及分布式时代。
我们看看每个阶段的主要驱动力是什么。
第一阶段个人网站。
二零零三年四月七日，马云提出成立淘宝。
二零零三年五月十日，淘宝就上线了，中间只有一个月，怎么办呢？淘宝的答案就是买一个估计大部分人很难想象，如今技术牛气冲天的阿里最初的淘宝竟然是买来的。
我们看看当初决策的依据，当时对整个项目组来说，压力最大的就是时间。
怎么在最短的时间内把一个从来就没有的网站从零开始建立起来呢？了解淘宝历史的人知道，淘宝是在二零零三年五月十日上线的这之间，只有一个月。
要是你在这个团队里，你怎么做，我们的答案就是买一个来淘宝。
当时在初创时没有过度考虑技术是否优越性，能是否海量，以及稳定性如何，主要的考虑因素就是快。
因为此时业务要求快速让线时间不等人等，你花几个月甚至十几个月搞出一个强大的系统出来，可能市场机会就没有了，黄花菜都凉了。
同样在考虑如何买的时候，淘宝的决策依据主要也是快买一个网站，显然比做一个网站要省事儿一些。
但是他们的梦想可不是做一个小网站而已，要做大就不是随便买个就行的。
要有比较低的维护成本，要能够方便的扩展和二次开发。
那接下来就是第二个问题，答一个什么样的网站呢？答案是轻亮一点的。
简单一点的，买一个系统是为了快速可用，而买一个轻量级的系统，是为了快速开发。
因为系统上线后肯定有大量的需求需要做，这时能够快速开发就非常重要。
从这个实例我们可以看到，淘宝最开始的时候，业务要求就是快。
因此，反过来，要求技术同样要快，业务决定技术。
这里架构设计和选择主要遵循的是合适原则和简单原则。
第二阶段，oracle支付宝旺旺淘宝网推出后，由于正好碰到非典，网购很火爆，加上采取了成功的市场运作，流量和交易量迅速上涨，业务发展很快。
在二零零三年底，mysql已经撑不住了，一般人或者团队在这个时候可能就开始优化系统优化架构分拆业务了。
因为这是大家耳熟能详也很拿手的动作。
那我们来看看淘宝这个时候怎么采取的措施。
技术的替代方案非常简单，就是换成oracle换oracle的原因，除了它容量大、稳定、安全性能高，还有人才方面的原因。
可以看出，这个时候淘宝的策略主要还是买买更高配置的oracle.这个是当时情况下最快的方法，除了购买oracle,后来为了优化，又买了更强大的存储。
后来数据量变大了，本地存储不行了。
买了NAS net app的NAS存储作为了数据库的存储设备，加上oracle RAC来实现负载均衡。
为什么淘宝在这个时候继续采取买的方式来快速解决问题呢？我们可以从时间上看出端倪，此时离刚上线才半年不到，业务飞速发展，最快的方式支撑业务的发展，还是去买。
如果说第一阶段买的是方案，这个阶段买的就是性能。
这里架构设计和选择主要遵循的还是合适原则和简单原则。
第三阶段脱胎换骨的java时代一点零淘宝切换到java的原因很有趣儿，主要因为找了一个PHP的开源连接池，c ql relay连接到oracle,而这个代理经常死锁，死锁了就必须重启，而数据库又必须用oracle,于是决定换个开发语言。
最后淘宝挑选了java,最且当时挑选java也是请散公司的人，这帮人很厉害。
先是将淘宝网站从PHP热切换到了java,后来又做了支付宝。
这次切换的主要原因是因为技术影响了业务的发展，频繁的死锁和重启，对用户业务产生了严重的影响。
从业务的角度来看，这是不得不解决的技术问题。
但这次淘宝为什么没有去买呢？我们看最初选择seql relay的原因，但对于PHP语言来说，它是放在apache上的，每个请求都会对数据库产生一个连接。
它没有连接池这种功能，那如何是好呢？这帮人打探道，ebay在PHP下面用了一个连接池的工具是BEA卖给他们的。
我们知道BEA的东西都很贵，我们买不起。
于是，多龙在网上寻寻觅觅，找到一个开源的连接池代理服务。
Seql relay不清楚当时到底有多贵oracle都可以买连接池买不起。
所以我个人感觉这次切换语言呢，更多是为以后业务发展做铺垫。
毕竟当时PHP语言远远没有java那么火，那么好招人。
淘宝选择java语言的理由可以从侧面验证这点。
Java是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用。
另外有java开发经验的人才也比较多，后续维护成本会比较低。
综合来看，这次架构的变化没有再简单通过买来解决，而是通过重构来解决架构设计和选择，遵循了演化原则。
第四阶段，坚若磐石的java时代二点零java时代二点零淘宝做了很多优化工作。
数据分库放弃EJB,引入spring加入缓存，加入CDN,采用开源的j boss.为什么在这个时候要做这些动作呢？原文作者很好的概括了做这些动作的原因。
这些杂七杂八的修改，我们对数据分库放弃EJB,引入spring,加入缓存，加入CDN,采用开源的j boss,看起来没有章法可循。
其实呢都是围绕着提高容量、提高性能、节约成本来做的。
我们思考一下，为什么在前面的阶段，淘宝考虑的都是快，而现在开始考虑容量性能成本了呢？而且为什么这个时候不采取买的方式来解决容量性能成本问题呢？简单来说就是买也搞不定了。
此时的业务发展情况是这样的。
随着数据量的继续增长，到了二零零五年，产品数有一千六百六十三万，PV,有八千九百三十一万注册会员有一千三百九十万。
这给数据和存储带来的压力依然很大，数据量大，性能就慢。
原有的方案存在固有缺陷，随着业务的发展，已经不是靠买就能够解决问题了。
此时必须从整个架构上去进行调整和优化。
比如说oracle在强大，在做likely搜索的时候，也不可能做到纯粹的搜索系统，如solar、斯芬克斯等的性能，因为这是机制决定的。
另外，随着规模的增大，纯粹靠买的一个典型问题开始成为重要的考虑因素，那就是成本。
当买一台两台oracle的时候，可能对成本并不怎么关心，但如果要买一百台oracle,成本就是一个关键因素了。
这就是量变带来质变的一个典型案例。
业务和系统发生质变后，架构设计，遵循演化原则的思想，需要再一次重构甚至重写。
第五阶段，java时代三点零和分布式时代，java时代三点零。
我个人认为是淘宝技术飞跃的开始。
简单来说就是淘宝技术从商用转为自研，典型的就是去IOE化。
分布式时代。
我认为是淘宝技术的修炼成功。
到了这个阶段，自研技术已经自成一派，除了支撑本身的海量业务，也开始影响整个互联网的技术发展。
到了这个阶段，业务规模急剧上升后，原来并不是主要复杂度的IOE成本开始成为了主要的问题。
因此，通过自研系统来降低IOE的成本，去IOE也是系统架构的再一次演化。
接下来我介绍一下手机QQ的案例，有部分内容摘自QQ,一点四亿在线背后的故事。
我来给你解读各个阶段的架构图。
你可以点击文稿，查看手机QQ的发展历程。
按照用户规模可以粗略划分为四个阶段，十万级、百万级、千万级亿级。
不同的用户规模IM后台的架构也不同，而且基本上都是用户规模先上去，然后产生各种问题，倒逼技术架构升级。
第一阶段十万级IM一点x最开始的手机QQ后台呢是图中这样的，可以说是简单的不能再简单普通的，不能再普通的一个架构了。
因为当时业务刚开始架构设计遵循的是合适原则和简单原则。
第二阶段，百万级IM二点x随着业务发展到二零零一年，QQ同时在线人数也突破了一百万。
第一代架构很简单，明显不可能支撑百万级的用户规模。
主要的问题有所接入服务器的内存为例，单个在线用户的存储量约为二KB,索引和在线状态为五十。
字节好友表四百个好友乘以五字节，每好友等于两千字节。
大致来说，二GB内存只能支持一百万在线用户，CPU网卡包量和流量、交换机、流量等瓶颈，单台服务器支撑不下所有在线用户和注册用户。
于是针对这些问题，做架构改造，按照演化原则的指导进行了重构。
重构的方案呢相比现在来说也还是简单的多，因此当时做架构设计时也遵循了合适原则和简单原则。
第三阶段，千万级IM三点x业务发展到二零零五年，QQ同时在线人数突破了一千万。
第二代架构支撑百万级用户是没问题的，但支撑千万级用户又会产生新问题，表现有同步流量太大状态，同步服务器遇到单机瓶颈，所有在线用户的在线状态，信息量太大单台接入服务器存不下。
如果在线数进一步增加，甚至单台状态同步，服务器也存不下单，台状态同步，服务器支撑不下所有在线用户单台接入服务器支撑不下所有在线用户的在线状态信息。
针对这些问题，架构需要继续改造升级，再一次演化。
可以看到这次的方案相比之前的方案来说并不简单了。
这是业务特性决定的。
第四阶段e级IM四点x业务发展到二零一零年三月，QQ同时在线人数过亿。
第三代架构此时也不适应了，主要问题有灵活性很差，比如昵称长度增加一半，需要两个月增加固乡字段需要两个月，最大好友数从五百变成一千，需要三个月，无法支撑某些关键功能。
比如好友数上万隐私权限控制PCQQ与手机QQ不可互踢，微信与QQ互通，异地容灾除了不适应，还有一个更严重的问题。
Im后台从一点零到三点五都是在原来基础上做改造升级的，但是持续打补丁已经难以支撑一级在线IM后台四点零必须从头开始重新设计实现。
这里再次遵循了演化原则，决定重新打造一个这么复杂的系统，不得不佩服当时决策人的勇气和魄力重新设计的。
Im四点零架构和之前的架构相比，架构本身都拆分为两个主要的架构。
存储架构和通信架构，你可以点击文稿查看这两个架构图。
今天呢我给你讲了淘宝和手机QQ两个典型互联网业务的架构发展历程。
通过这两个案例我们可以看出，即使是现在非常复杂非常强大的架构，也并不是一开始就进行了复杂设计，而是首先采取了简单的方式及简单原则，满足了当时的业务需要及合适原则。
随着业务的发展逐步演化而来的及演化原则，罗马不是一天建成的架构，也不是一开始就设计成完美的样子，然后可以一劳永逸，一直用下去。
这就是今天的全部内容，留一道思考题给你吧。
搜索一个互联网大厂的架构发展案例，分析一下其发展过程，看看哪些地方体现了这三条架构设计原则。
欢迎把你的答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。