普通一个网站刚开端树立的时分，用户量是很少的，大约可能就几万或者几十万的用户量，每天活泼的用户可能就几百或者几千个。
这个时分普通网站架构都是采用单体架构来设计的，总共就部署3台效劳器，1台应用效劳器，1台数据库效劳器，1台图片效劳器。
数据库普通就部署在一台独立的效劳器上，寄存网站的全部中心数据。
然后在另外一台独立的效劳器上部署NFS作为图片效劳器，寄存网站的全部图片。应用效劳器上的代码会衔接以及操作数据库以及图片效劳器。
但是这种纯单块系统架构下，有高可用问题存在，最大的问题就是应用效劳器可能会毛病，或者是数据库可能会毛病
所以在这个时期，普通略微预算充足一点的公司，都会做一个初步的高可用架构出来。
关于数据库效劳器而言，此时普通也会运用主从架构，部署一台从库来从主库同步数据，这样一旦主库呈现问题，能够疾速运用从库继续提供数据库效劳，防止数据库毛病招致整个系统都彻底毛病不可用。
千万级用户量的压力预估
这个假定这个网站预估的用户数是1000万，那么依据28规律，每天会来访问这个网站的用户占到20%，也就是200万用户每天会过来访问。
通常假定均匀每个用户每次过来会有30次的点击，那么总共就有6000万的点击(PV)。
每天24小时，依据28规律，每天大局部用户最活泼的时间集中在(24小时 * 0.2)≈ 5小时内，而大局部用户指的是(6000万点击 * 0.8 ≈ 5000万点击)
也就是说，在5小时内会有5000万点击进来。
换算下来，在那5小时的活泼访问期内，大约每秒钟会有3000左右的恳求量，然后这5小时中可能又会呈现大量用户集中访问的顶峰时间段。
比方在集中半个小时内大量用户涌入构成顶峰访问。依据线上经历，普通顶峰访问是活泼访问的2~3倍。假定我们依照3倍来计算，那么5小时内可能有短暂的峰值会呈现每秒有10000左右的恳求。
(4)效劳器压力预估
大约晓得了顶峰期每秒钟可能会有1万左右的恳求量之后，来看一下系统中各个效劳器的压力预估。
普通来说一台虚拟机部署的应用效劳器，上面放一个Tomcat，也就支撑最多每秒几百的恳求。
按每秒支撑500的恳求来计算，那么支撑顶峰期的每秒1万访问量，需求部署20台应用效劳。
而且应用效劳器对数据库的访问量又是要翻几倍的，由于假定一秒钟应用效劳器接纳到1万个恳求，但是应用效劳器为了处置每个恳求可能要触及到均匀3~5次数据库的访问。
假如一切业务代码都混合在一同部署，会招致多人协作开发时难以维护。在网站到了千万级用户的时分，研发团队普通都有几十人以至上百人。
所以这时假如还是在一个单块系统里做开发，是一件十分痛苦的事情，此时需求做的就是停止业务的垂直拆分，把一个单块系统拆分为多个业务系统，然后一个小团队10个人左右就特地担任维护一个业务系统。
也就是说，每秒大约6000写恳求是进入主库，大约还有4000个读恳求是在从库上去读，这样就能够把1万读写恳求压力分摊到两台效劳器上去。
这么分摊过后，主库每秒最多6000写恳求，从库每秒最多4000读恳求，根本上能够勉强把压力给抗住。
