2.1 从一个故事说起2.2 访问量驱动架构
2.3 单机架构
2.4 多机架构-三分天下
2.5 集群架构-负载均衡
2.6 分布式架构-MySQL分表分库分片
2.7 小张讲解
2.8 课后作业
7月7日,晴,外面下起了小雨,屋里女朋友盯着手机,各种淘宝,各种衣服... 目不转睛的看着手机屏幕。
而我呢,盯着没有信号的电视发呆...思绪一下子就回到了好多年前。
2006年7月7日,路上,熙熙攘攘的人群,好多妹纸在逛街,女人天生就喜欢买衣服,你去到步行街的only, 优衣库的品牌店看看,
大把的妹纸好像等着你一样!
2009年7月7日,互联网一下子火爆起来,抢车位、偷菜这些社交游戏十分火爆,有的妹纸为了偷好友的菜,竟然晚上一直守到了
凌晨3点,除了买衣服还有什么事情可以让妹纸熬夜到这么晚呢。
2012年7月7日,随着社交游戏的褪去,妹纸们依旧是回到了购物买衣服这件事情上面来了,只是这次不是逛街,而是网上逛淘宝,想想那会
女朋友偶尔打开电脑开个把小时网页,看看衣服购物,因为当时物流还不是非常的发达,不是经常网上购物,很多时候还是会去步行街逛逛。
2016年7月7日,晃了一下神,整个人回到了现在,旁边,女朋友还在看着手机,逛着唯品会,雨也还在下着,可想而知,如今移动互联网的
发达,已经没有多少妹纸愿意去逛街了,东门步行街人少了,华强北没落了,波司登、利郎、百丽、佐丹奴、安踏、九牧王、七匹狼这些传统
知名品牌接连关店了。
这到底是好事还是坏事呢,互联网带给我们很多方便和快捷,但是似乎让我们少了很多购物的乐趣和面对面的沟通。
世界上最遥远的距离是我和你在一起,而你却在玩手机。
亲爱的,洗洗睡了吧。。
为什么说是访问量驱动架构的变革呢?
技术的发展离不开业务的需求,如果我们网站一天的访问量只有几百人,我们还需要做分布式架构吗,我肯定的说:不需要。
当用户访问量达到了几万或者几十万的PV访问,单机架构肯定是支撑不了的,这个时候就需要新的架构,但不一定是分布式,
这个就是 “量(访问量)变到质(架构)变”。一定的访问量以后,需要新的架构来支撑整套系统,不然系统就崩溃了。
为什么会有如今这么复杂的各种架构呢,得益于电商的发展,得益于中国劳动人民的人群基数,我代表。。额,代表我自己
感谢大家了 :).
架构是一直在发展的,除了分布式,现在比较流行的 微服务架构也正在快速的发展。
上一节通过不同时期的生活场景,让大家感受到互联网的发展,以及各个阶段所用的架构是怎么样的,下面就介绍各个时期所用的架构。
每个开发者都会经历一遍这个架构,现在来看,他实在是太简单了,让很多人都以为他不是一种架构,小张想说的就是,
这是最简单的单机架构,现在物资生活丰富了,大家一个人会有很多部手机,如果你有废弃的手机不妨拿来做个服务器,
手机做服务器,这也是单机架构的一种实践。
小张推荐一款Android 下面的APP ksweb ,下载安装十分简单,安装好了以后就可以启动一个网站服务器,通过
http://ip:8080 网页就可以访问了。
KSWEB
ksweb 里面包含 php应用服务器,Mysql的数据库,以及文件系统。
单机架构图如下:
单机架构图
应用服务器,数据库,文件系统全部放在一台物理服务器上面。
谁有胆量的把地址发到朋友圈,叫上你朋友圈里所有人,来访问你的手机,看看能不能像三星手机有种爆炸的效果.
单机已经被我们玩坏了,这个时候自然有人要出来解决问题了,如何解决呢
最容易想到的方法就是,把应用服务器、数据库、文件系统分开,把他们三,三分天下
于是,架构图就演化成下面这样:
多机架构图
这个很简单,是吧,把应用服务器、数据库、文件系统分别放到三台不同的物理机上,来分摊压力。
但是你不能小看中国妹纸们的力量,电商的爆发,让她们的购物的欲望得到了释放,
简单的多机架构已经撑不住了,也是妹纸们的欲望成就了我们,能让我们做出更好的架构。
因为我们现在已经将应用服务器、文件系统、数据库分离到三个不同物理机上了,
我们可以针对每台物理机上面的系统做优化,访问量爆增以后,并发量大,最先撑不住的就是应用服务器了,
这个时候我们对应用服务器这部分做一个集群的架构,然后对这个集群做负载均衡,
简单来说,现在应用服务器是一台物理机,我们用多台物理机来对应用服务器做集群,然后访问量来了以后
利用负载均衡的技术将访问量分摊到不同的物理机上,这样访问量被分摊了,每台机承受的压力就小了,
并且这种架构还有很强的扩展性,如果碰到双11 访问量徒增,我们可以通过增加集群机器的方式来进行扩展。
这种集群架构的架构图如下:
集群架构图
但是如果真的是双11 ,上面的架构就真的可以满足一天十几亿次的访问量吗,当然是不可能的,
这里先介绍一个木桶效应:
木桶效应
木桶是有很多竖着的板子围起来了的,整个木桶能装多少水并不是高的那块板决定的,而是由最短的那块板决定,
这就是木桶效应,而木桶效应同样的适用于架构设计
集群架构只是解决了整个系统中应用服务器这一块的性能,而瓶颈(短板)在数据库这一块,所以整个系统性能的提高
还得提高数据库这一块的性能。
但是数据库这一块可不可以像应用服务器那样做个集群,来提高性能呢,这个就要从应用服务器和数据库在整个系统中的定位来分析了,
应用服务器 只是对 用户的访问请求作处理
数据库是对业务的数据做存储、查询,还有事务处理等,涉及到数据的操作,会有多表查询,数据一致性的考虑。
所以从这方面来看,数据库这一块似乎要复杂很多,应用服务器的每个请求都是独立的,所以可以任意分布到集群的任何物理机上。
如果将数据也任意分布到数据库集群的任意物理机上,那么等你查询的时候,就完全不知道如何来查了。
这样,拿Mysql 为例,我们要他的性能作提升,就需要 利用一定的 分库分表策略 来进行,而这部分的工作就交由 Mysql数据库中间件Mycat 来做。
这种架构我们称之为分布式架构,如图:
分布式架构图
理解了Mycat 在整个系统中的定位 ,有利于接下来我们对他的学习, 学习Mycat之前,我们还将进行一些Mysql数据库的知识预备。
> 关于架构的衍生
用集群架构来说,如果用户访问量并发量刚刚上来,我们不用急于改变整体架构,因为这样重新架构一个正在生产的系统,代价是
非常大的,我们可以通过缓存的机制,来提高性能,提高整个系统性能的方法在于找到那个短板,影响性能的短板,然后进行优化,
系统的短板在于数据库,数据库的短板在于IO,所以通过缓存可以降低IO的读写,有利于系统性能的提升。
> Mysql 读写分离
在不使用分表分库,数据分片之前,我们还可以对 Mysql数据库进行 读写分离,具体如何在实际项目中来做,我们在后面会利用
阿里云来进行实战操作。
1. 架构发展路线图
2. 如何优化系统性能的思路
3. 何为木桶效应
4.如何运用缓存技术提高系统性能