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

2.1 从一个故事说起

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

2.1 从一个故事说起


穿越回过去,妹纸怎么活(分布式架构演化)_第1张图片

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

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

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

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

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

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


穿越回过去,妹纸怎么活(分布式架构演化)_第2张图片

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

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

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

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

知名品牌接连关店了。

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

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

亲爱的,洗洗睡了吧。。

2.2 访问量驱动架构


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

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

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

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

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

感谢大家了 :).

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

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


2.3 单机架构


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

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

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

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

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


穿越回过去,妹纸怎么活(分布式架构演化)_第3张图片
KSWEB

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

单机架构图如下:


穿越回过去,妹纸怎么活(分布式架构演化)_第4张图片
单机架构图

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

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


穿越回过去,妹纸怎么活(分布式架构演化)_第5张图片

2.4 多机架构-三分天下



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

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

于是,架构图就演化成下面这样:


穿越回过去,妹纸怎么活(分布式架构演化)_第6张图片
多机架构图

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

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

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

2.5 集群架构-负载均衡


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

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

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

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

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

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

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

穿越回过去,妹纸怎么活(分布式架构演化)_第7张图片
集群架构图


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


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

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


穿越回过去,妹纸怎么活(分布式架构演化)_第8张图片
木桶效应


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

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

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

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

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

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

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

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

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

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

这种架构我们称之为分布式架构,如图:


穿越回过去,妹纸怎么活(分布式架构演化)_第9张图片
分布式架构图

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


2.7 小张讲解


> 关于架构的衍生

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

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

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

> Mysql 读写分离

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

阿里云来进行实战操作。

2.8 课后作业

1. 架构发展路线图

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

3. 何为木桶效应

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


穿越回过去,妹纸怎么活(分布式架构演化)_第10张图片

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

你可能感兴趣的:(小张网校)