穿越回过去，妹纸怎么活(分布式架构演化)

2.1 从一个故事说起

2.2 访问量驱动架构
2.3 单机架构
2.4 多机架构-三分天下
2.5 集群架构-负载均衡
2.6 分布式架构-MySQL分表分库分片
2.7 小张讲解
2.8 课后作业

2.1 从一个故事说起

7月7日，晴，外面下起了小雨，屋里女朋友盯着手机，各种淘宝，各种衣服...  目不转睛的看着手机屏幕。

而我呢，盯着没有信号的电视发呆...思绪一下子就回到了好多年前。

2006年7月7日，路上，熙熙攘攘的人群，好多妹纸在逛街，女人天生就喜欢买衣服，你去到步行街的only, 优衣库的品牌店看看，

大把的妹纸好像等着你一样！

2009年7月7日，互联网一下子火爆起来，抢车位、偷菜这些社交游戏十分火爆，有的妹纸为了偷好友的菜，竟然晚上一直守到了

凌晨3点，除了买衣服还有什么事情可以让妹纸熬夜到这么晚呢。

2012年7月7日，随着社交游戏的褪去，妹纸们依旧是回到了购物买衣服这件事情上面来了，只是这次不是逛街，而是网上逛淘宝，想想那会

女朋友偶尔打开电脑开个把小时网页，看看衣服购物，因为当时物流还不是非常的发达，不是经常网上购物，很多时候还是会去步行街逛逛。

2016年7月7日，晃了一下神，整个人回到了现在，旁边，女朋友还在看着手机，逛着唯品会，雨也还在下着，可想而知，如今移动互联网的

发达，已经没有多少妹纸愿意去逛街了，东门步行街人少了，华强北没落了，波司登、利郎、百丽、佐丹奴、安踏、九牧王、七匹狼这些传统

知名品牌接连关店了。

这到底是好事还是坏事呢，互联网带给我们很多方便和快捷，但是似乎让我们少了很多购物的乐趣和面对面的沟通。

世界上最遥远的距离是我和你在一起，而你却在玩手机。

亲爱的，洗洗睡了吧。。

2.2 访问量驱动架构

为什么说是访问量驱动架构的变革呢？

技术的发展离不开业务的需求，如果我们网站一天的访问量只有几百人，我们还需要做分布式架构吗，我肯定的说：不需要。

当用户访问量达到了几万或者几十万的PV访问，单机架构肯定是支撑不了的，这个时候就需要新的架构，但不一定是分布式，

这个就是 “量（访问量）变到质（架构）变”。一定的访问量以后，需要新的架构来支撑整套系统，不然系统就崩溃了。

为什么会有如今这么复杂的各种架构呢，得益于电商的发展，得益于中国劳动人民的人群基数，我代表。。额，代表我自己

感谢大家了 ：）.

架构是一直在发展的，除了分布式，现在比较流行的 微服务架构也正在快速的发展。

上一节通过不同时期的生活场景，让大家感受到互联网的发展，以及各个阶段所用的架构是怎么样的，下面就介绍各个时期所用的架构。

2.3 单机架构

每个开发者都会经历一遍这个架构，现在来看，他实在是太简单了，让很多人都以为他不是一种架构，小张想说的就是，

这是最简单的单机架构，现在物资生活丰富了，大家一个人会有很多部手机，如果你有废弃的手机不妨拿来做个服务器，

手机做服务器，这也是单机架构的一种实践。

小张推荐一款Android 下面的APP ksweb ，下载安装十分简单，安装好了以后就可以启动一个网站服务器，通过

http://ip:8080 网页就可以访问了。

KSWEB

ksweb 里面包含 php应用服务器，Mysql的数据库，以及文件系统。

单机架构图如下：

单机架构图

应用服务器，数据库，文件系统全部放在一台物理服务器上面。

谁有胆量的把地址发到朋友圈，叫上你朋友圈里所有人，来访问你的手机，看看能不能像三星手机有种爆炸的效果.

2.4 多机架构-三分天下

单机已经被我们玩坏了，这个时候自然有人要出来解决问题了，如何解决呢

最容易想到的方法就是，把应用服务器、数据库、文件系统分开，把他们三，三分天下

于是，架构图就演化成下面这样：

多机架构图

这个很简单，是吧，把应用服务器、数据库、文件系统分别放到三台不同的物理机上，来分摊压力。

但是你不能小看中国妹纸们的力量，电商的爆发，让她们的购物的欲望得到了释放，

简单的多机架构已经撑不住了，也是妹纸们的欲望成就了我们，能让我们做出更好的架构。

2.5 集群架构-负载均衡

因为我们现在已经将应用服务器、文件系统、数据库分离到三个不同物理机上了，

我们可以针对每台物理机上面的系统做优化，访问量爆增以后，并发量大，最先撑不住的就是应用服务器了，

这个时候我们对应用服务器这部分做一个集群的架构，然后对这个集群做负载均衡，

简单来说，现在应用服务器是一台物理机，我们用多台物理机来对应用服务器做集群，然后访问量来了以后

利用负载均衡的技术将访问量分摊到不同的物理机上，这样访问量被分摊了，每台机承受的压力就小了，

并且这种架构还有很强的扩展性，如果碰到双11 访问量徒增，我们可以通过增加集群机器的方式来进行扩展。

这种集群架构的架构图如下：

集群架构图

2.6 分布式架构-Mysql分表分库分片

但是如果真的是双11 ，上面的架构就真的可以满足一天十几亿次的访问量吗，当然是不可能的，

这里先介绍一个木桶效应：

木桶效应

木桶是有很多竖着的板子围起来了的，整个木桶能装多少水并不是高的那块板决定的，而是由最短的那块板决定，

这就是木桶效应，而木桶效应同样的适用于架构设计

集群架构只是解决了整个系统中应用服务器这一块的性能，而瓶颈（短板）在数据库这一块，所以整个系统性能的提高

还得提高数据库这一块的性能。

但是数据库这一块可不可以像应用服务器那样做个集群，来提高性能呢，这个就要从应用服务器和数据库在整个系统中的定位来分析了，

应用服务器 只是对 用户的访问请求作处理

数据库是对业务的数据做存储、查询，还有事务处理等，涉及到数据的操作，会有多表查询，数据一致性的考虑。

所以从这方面来看，数据库这一块似乎要复杂很多，应用服务器的每个请求都是独立的，所以可以任意分布到集群的任何物理机上。

如果将数据也任意分布到数据库集群的任意物理机上，那么等你查询的时候，就完全不知道如何来查了。

这样，拿Mysql 为例，我们要他的性能作提升，就需要 利用一定的 分库分表策略 来进行，而这部分的工作就交由 Mysql数据库中间件Mycat  来做。

这种架构我们称之为分布式架构，如图：

分布式架构图

理解了Mycat 在整个系统中的定位 ，有利于接下来我们对他的学习， 学习Mycat之前，我们还将进行一些Mysql数据库的知识预备。

2.7 小张讲解

> 关于架构的衍生

用集群架构来说，如果用户访问量并发量刚刚上来，我们不用急于改变整体架构，因为这样重新架构一个正在生产的系统，代价是

非常大的，我们可以通过缓存的机制，来提高性能，提高整个系统性能的方法在于找到那个短板，影响性能的短板，然后进行优化，

系统的短板在于数据库，数据库的短板在于IO，所以通过缓存可以降低IO的读写，有利于系统性能的提升。

> Mysql 读写分离

在不使用分表分库，数据分片之前，我们还可以对 Mysql数据库进行 读写分离，具体如何在实际项目中来做，我们在后面会利用

阿里云来进行实战操作。

2.8 课后作业

1. 架构发展路线图

2. 如何优化系统性能的思路

3. 何为木桶效应

4.如何运用缓存技术提高系统性能

本文原创小张，转载请注明来源地址小张博客