《大型网站技术架构》读书笔记(一)

《大型网站技术架构》

大型互联网应用有以下特点:

  • 高并发,大流量:日均访问量数以亿计
  • 高可用:24小时不间断服务
  • 海量数据:存储,管理海量数据
  • 用户分布广泛,网络情况复杂
  • 安全环境恶劣:容易被攻击
  • 需求快速变更,发布频繁
  • 渐进式发展:从小型网站慢慢发展成大型网站

演化过程

1 初始阶段

初始阶段.png

所有的业务集中在一起,网站,数据库和文件都放在一个服务器中,典型的LAMP架构
2 应用服务和数据服务分离
随着业务的发展,网站用户越来越多,一台服务器逐渐不能应对需求(存储空间越来越少,性能越来越差);此时需要将应用和数据分离分别放在3台服务器上:

应用数据分离.png

三者分工不同,对相应的数据库性能要求也不一样:应用程序服务器处理大量业务逻辑,它对CPU的性能要求较高;数据库服务器要快速检索数据和数据缓存,因而对内存和硬盘要求较高;文件服务器要存储大量文件(用户上传的图片等),要求更大的硬盘容量。

三个服务器各司其职,暂时解决了第一阶段的存储容量问题,也提高了并发处理能力。
3 缓存
随着用户的增加,数据库的压力越来越大,用户的每一次登录都要访问数据库,导致响应缓慢,影响用户体验,我们分析发现:

网站访问特点和现实世界的财富分配一样遵循二八定律:80%的业务访问集中在20%的业务上

我们只需将这20%的业务做一下缓存就可以缓解数据库压力大的问题。
网站使用的缓存有两种:1.放在应用服务器上的本地缓存(速度快但是会占用应用程序的内存);2.放在专门的分布式缓存服务器上的远程缓存(可以用多台服务器做集群,实现大内存容量的缓存服务)。

缓存.png

4 应用服务起集群
此时的应用程序服务器只有一个,它能处理的请求连接有限,在网站访问高峰期应用程序服务器的压力会很大,导致访问排队,响应等待时间长。于是我们要对应用服务器做集群,通过负载均衡调度服务器分发请求给应用程序服务器,多个服务器来处理请求,每一个应用程序服务器的压力都不会太大。

应用服务器集群.png

5 数据库读写分离
现状是加完缓存,大部分数据访问可以不通过数据库,但还有少量的数据读取(未作缓存的数据,缓存过期和缓存未命中的数据)以及全部的数据写入都要访问数据库。随着用户量的增长,数据库的压力越来越明显,逐渐成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。

数据库读写分离.png

应用程序的写操作访问主数据库服务器,将数据写入;为保证数据一致性,主数据库通过主从复制机制将数据更新同步到从数据库服务器;应用程序的读取数据访问从数据库服务器就可以获取。

为了便于应用程序访问读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,是数据库读写分离对应用透明。

6 反向代理和CDN
为了让网络环境不是很好的区域的用户也能很好的访问我们的网站,网站需要加速网站的访问速度,此时就会用到反向代理和CDN。

CDN和反向代理.png

CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务是,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存这用户请求的资源,就将其直接返回给用户。

这一阶段的目的就是尽快将数据返回给用户,此时的架构一方面加快了用户的访问速度,另一方面也缓解了后端服务器的负载压力。
7 分布式文件系统和分布式数据库
当业务发展到一定程度,数据量十分庞大的时候,两台数据库服务器已经无法满足需求,此时要做分布式数据库和分布式文件系统。
将数据库按照业务进行拆分,将不同业务的数据库部署在不同的物理服务器上。

分布式数据库&分布式文件系统.png

8 NoSql和搜索引擎
随着业务越来越复杂,对数据的存储和检索的需求也变得复杂起来,此时需要使用非关系数据技术(如NoSql)和非数据库查询技术(如搜索引擎)来帮忙。

NoSql和搜索引擎.png

NoSql和搜索引擎都是源自互联网的 技术手段,对可伸缩的分布式特性具有更好的支持。

9 业务拆分
为应对日益复杂的业务场景,将网站以业务为模块进行拆分然后交给不同的业务团队负责管理,达到分治的目的。
具体来说就是将应用服务依业务拆分成一个个小系统(包括商品管理系统,支付系统,订单系统等),然后每个系统独立部署维护。各系统之间通过超链接建立联系,也可以通过消息队列进行数据分发。但都会访问同一个数据存储系统来构成一个完整的网站系统。

业务拆分.png

10 分布式服务
上一阶段每个业务系统都访问数据库资源,随着业务发展必然会导致数据库资源不足,系统的维护也更加困难。分析发现有很多公共业务(如 用户管理,商品管理等),将其提取出来做成公共服务,可以有效缓解上一阶段造成的问题。

分布式服务.png

此时的网站总体架构:

网站架构.png

网站架构演化的价值观

  • 大型网站架构技术的核心价值是随网站所需灵活应对(LAMP技术开发小 网站足够,随着业务逐步发展演化)
  • 驱动大型网站技术发展的主要力量是业务发展(高并发,多用户驱动集群和分布式)

网站架构设计误区

  • 一味追随大公司的解决方案(可以学习借鉴,但不要盲从)
  • 为了技术而技术(业务为主,技术为辅)
  • 企图用技术解决所有问题(业务问题要从业务的调整来解决)
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,527评论 5 470
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,314评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,535评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,006评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,961评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,220评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,664评论 3 392
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,351评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,481评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,397评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,443评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,123评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,713评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,801评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,010评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,494评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,075评论 2 341

推荐阅读更多精彩内容