网站Web业务架构从小到大演变

有一天,我突发奇想创建了一个站点,基于 LNMP 架构,起初只有我自己访问,后来因为我点儿正,访问量越来越大,所以最终导致下面的架构演变。

1、单台机器

单台机器因为只是一个小站,访问量一天也没有多少uv(100以内),所以用一台1核1g的机器足够了。机器上安装的是 CentOS 系统,然后搭建了 nginx+php-fpm+mysql 的环境。

2、一台变两台

访问量越来越大,日uv突破5000,单台机器不够了,本可以增加机器配置编程4核8G,但是考虑到还要换机器,所以直接添置一台 DB 服务器单独跑 MySQL服务。原来的服务器只需要跑 nginx+php-fpm,新加服务器跑 MySQL 服务。 在这里,往往会遇到一个问题,就是如何在多台机器上编译安装 LAMP 环境,在单台机器上编译都没有问题,PHP 放在最后,因为它依赖 MySQL,但我们这里需要把 MySQL 放到另一台机器,所以编译肯定会报错。解决这个问题,其实很简单,即使 WEB 上不需要 MySQL,我们也要安装一下,因为编译 PHP 的时候依赖它。

3、增加memcached

访问量持续增加,uv上w了,DB 服务器和 WEB 服务器压力越来越大,这时候我们需要加一个缓存来缓解 DB 服务器的压力。同样是两台机器,只不过 WEB机器配置需要升级了,原来的1核1g不够用了,不仅要加 cpu 还要加内存,因为在 WEB 上我们需要运行 memcached 服务,同时 php 也需要安装memcache 扩展。

4、增加WEB并做MySQL主从

访问量又扩大了,uv到了5w,数据库服务器因为一开始配置就挺高,所以没有压力,但是 WEB 服务器负载有点高了,在高峰期可以感觉到网站访问变慢。所以,这时候不得不考虑要加一台 WEB 服务器。另外,数据库是单点,如果磁盘损坏,可能会带来意想不到的后果,所以我们有必要加一台从 DB 服务器,作为数据的备份。

在这里,两台 WEB 服务器我们并没有做负载均衡,因为为了节省资源,暂时先不去购买服务器做负载均衡,我们使用 DNS 轮询的方法来把用户的请求发到两台机器上,但这种该架构有个问题,一旦一台 WEB 机器宕机,将会有一半的用户访问不到业务。还有一个问题,我们也需要考虑到,如何保证 WEB 服务器上的数据一致,比如用户可能会上传图片到 WEB 服务器上,假如他上传到了 WEB1 上,那 WEB2 是不存在这个图片的。所以我们需要做一个共享存储让 WEB1 和 WEB2 同时可以访问,所以在这里我把 WEB1 的一个目录使用 NFS 共享出来,让 WEB2 去挂载。还有一个问题就是memcached服务如何分配,在这里,我是把 memcaced 服务分别安装到两台 WEB 上的,自己用自己的 memcached 服务。

5、MySQL读写分离

访问量持续上升,uv 已经到了数十万。网站在高峰期总是会卡顿那么一段时间。经排查,发现在 MySQL 服务器上有很多慢查询,经过各种调优依然没有太明显效果,最后决定做读写分离。

做读写分离有两种方案,第一可以借助程序来实现,把所有的写操作指向到主 MySQL ,所有的读操作指向到从 MySQL。对于这种方案,机器数量和环境不用做任何调整,唯一要做的是程序代码要改一下。第二可以借助 mysql-proxy 来实现,不用修改代码,节省开发成本,但需要增加一个角色。架构是这样的。

6、避免单点引入负载均衡

两台 WEB 服务器因为有一台比较老,所以在高峰期时,终究是没有能扛住而挂掉。结果影响了一半的用户访问不到网站了。经过此次事故,我不得不修改架构,尽量避免单点,于是在 WEB 前端设置了负载均衡器,并且做了高可用。

在这里我拿 nginx 做了负载均衡器,并没有使用 lvs,因为我觉得 nginx 更容易操作,更好控制。为了节省成本,我并没有单独把 mysql-proxy 摘出来作为独立服务器,因为那样的话,也得为它考虑单点问题。在这个架构中,其实还有一个缺陷,就是 NFS 服务端也是有风险的,更加保险的做法是单独搞一台服务器做NFS服务。

7、继续扩充

uv上升到100w,两台 WEB 服务器明显不够用了,而瓶颈并不在 MySQL 上。所以,只增加 WEB,同时把 NFS 服务器单独摘出来,并做一个备用 NFS 服务器。

8、引入NoSQL

uv近1000w,三台 WEB 服务器也早已不够,增加到5台,而 MySQL 服务器压力逐渐变大,针对 MySQL 的慢查询,发现压力主要体现在个别 SQL 语句上,该优化的已经优化到极致,对于这几个查询,其实是可以使用 NoSQL 的。于是,我找懂php开发的朋友帮我修改了程序,把一些访问量大的数据存储到redis,从而减少了对 MySQL 服务器的压力。 而 Redis 为了防止单点也做了主从。

9、MySQL架构演变

http://www.cnblogs.com/liwei0526vip/p/6424605.html

时间: 2024-10-08 18:03:19

网站Web业务架构从小到大演变的相关文章

linux 网站架构的演变

上一节,我们学习了linux下文件服务器NFS的搭建,了解了他的基本原理.可以说也是很简单的一个服务.今天我们学习影响互联网最重要服务web服务(应用服务).什么是web服务呢?就是我们平常在浏览器输入一个网站的地址,然后能给我们提供服务的就是web服务器.Web服务器的发展历史我就不多说了,我直接说下现在流行的搭建这种服务的常用软件.在Linux下比较常用的有三种分别是apache软件,tomcat软件,nginx软件.这三款是我在工作都接触过的,当然还有别的,其原理都是一样的,在这里我就不多

Mysql在大型网站的应用架构演变

原创文章,转载请注明: 转载自http://www.cnblogs.com/Creator/本文链接地址: Mysql在大型网站的应用架构演变 写在最前: 本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变 可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种Scale-up :  纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力Scale-out : 横向扩展,  通过加节

Mysql在大型网站的应用架构演变(转)

原文: Mysql在大型网站的应用架构演变 本文已经被多处转载,包括CSDN推荐以及码农周刊等等,阅读数超过5w+,回流到我博客流量的还是比较少,不过这不重要, 后续会分享更多技术,尽量试图把自己理解的东西描述出来(很多时候自己的理解是90分,可是描述出来就只有60分了) CSDN的转载 :http://www.csdn.net/article/2014-06-10/2820160 伯乐在线的转载: http://blog.jobbole.com/70844/ 当然还有大量转载没有写明出处的..

京东B2B业务架构演变

京东 B2B 业务的定位是让各类型的企业都可以在京东的 B 平台上进行采购.建立采购关系. 京东 B2B 的用户群体主要分为 2 类,一类是大 B 用户.另一类是小 B 用户.比如联通.移动公司跟京东建立的采购关系,就是 B 平台的大 B 用户:如果有一家小超市需要在京东 B 平台上进行采购,那么它就是 B 平台的小 B 用户. 京东 B 平台需要支持各类型的用户群,因此必须要有自己的业务系统做支撑,比如订单.商品.价格.用户.权限.审核等系统. 京东 B 平台的发展分为3个阶段: 1)第一阶段

分布式Web服务器架构

最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么

数据库架构的演变

 如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 最近看了很多公司架构的演变的文章,发现其中的基本思路和架构演变都很类似,这里也总结一下数据库架构的演变以及演变背后的思路. 单主机 最开始网站一般都是由典型的LAMP架构演变而来的,一般都是一台linux主机,一台apache服务器,php执行环境以及mysql服务器,一般情况下,这些都在一台虚拟主机上,简称单主机模式. 单主机模式缺点: 1 web服务器和mysql服务器公用一台主机

转Web开发的发展史---Web开发技术的演变

转自:http://blog.csdn.net/zzzkk2009/article/details/9849431 在接下来的几个月时间里,我打算写一系列关于完整web开发的文章.这第一篇文章虽然有所粗略,但也能够充分概括了在之前15年或者更久的时间里web应用程序如何进行演变.并且最后我会囊括下这段时间内所写的相关技术. 在过去的美好日子里,我们使用的是简单的web页面(包括动态gif图片!).作为精美设计的典范,苹果有着这样的一个网站: 在那时,Web开发还比较简单,开发者经常会去操作web

千万pv大型web系统架构,学习从点滴开始

架构,刚开始的解释是我从知乎上看到的.什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像.更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见. 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力.这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中

web 服务器架构 分布式

最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么