《大型网站技术架构核心原理与案例分析》读书笔记

1.大型网站架构演化

大型网站软件系统特点

  • 高并发,大流量
  • 高可用:7*24小时不间断服务
  • 海量数据:存储管理海量数据
  • 用户分布广泛,网络情况复杂
  • 安全环境恶劣
  • 需求快速变更、发布频繁
  • 渐进式发展

大型网站架构演化发展历程

  • 初始阶段网站:应用程序、数据库、文件都在一台服务器;
  • 应用服务和数据服务分离:应用服务器、数据库服务器、文件服务器;
  • 使用缓存改善网站性能:二八定律,80%的业务访问集中在20%的数据上。应用程序本地缓存(速度快、缓存数据量有限)和远程分布式缓存(集群方式、理论上无限容量);
  • 使用应用服务器集群改善网站的并发处理能力;
  • 数据库读写分离:写主库、主从复制、读从库。数据访问模块,使得读写分离透明;
  • 使用反向代理和CDN加速网站响应;
  • 使用分布式文件系统和分布式数据库系统;
  • 使用NoSQL和搜索引擎
  • 业务拆分:分而治之,多个独立应用独立部署;
  • 分布式服务:分布式服务调用共同业务服务完成具体业务操作;

2.大型网站架构模式

  • 分层
    将系统横向维度切分成几个部分,每个部分负责相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统;
    常用三层网站分层架构:
    应用层:负责具体业务和视图展示,可以在细分为视图层和业务逻辑层;
    服务层:为应用层提供服务支持,也可以细分为数据接口层和逻辑处理层;
    数据层:提供数据存储访问服务,如数据库、缓存文件、文件;

  • 分割
    分割是从纵向方面对软件进行切分,将不同的功能和服务分割开来,包装成高内聚低耦合的模块单元;

  • 分布式
    分层和分割的一个主要目的是为了切分后的模块便于分布式部署,将不同模块部署在不同的服务器上,通过远程调用协调工作。
    常用的分布式方案有以下几种:
    1). 分布式应用和服务:分层和分割后的应用和服务模块分布式部署;
    2). 分布式静态资源:JS、CSS、图片资源独立分布式部署,采用独立的域名,即动静分离;
    3). 分布式数据和存储
    4). 分布式计算
    5). 分布式配置
    6). 分布式锁
    7). 分布式文件系统

  • 集群
    多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务。
    集群化部署可以提供更好的并发特性,提供系统的可用性;

  • 缓存
    将数据存放在距离计算最近的位置以加快处理速度。
    CDN:内容分发网络,部署在距离终端用户最近的服务提供商,缓存网站的静态资源;
    反向代理:网站前端架构的一部分,用户请求到达网站的数据中心时,最先访问到反向代理服务器;
    本地缓存:应用服务器本地缓存热点数据在本机内存中;
    分布式缓存:单机缓存数据量有限,将数据缓存到专门的分布式缓存集群中;

  • 异步
    业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步执行进行协作。
    异步架构的典型下模式是生产者和消费者模式,优点是:提供系统可用性、加快网站响应速度,消息并发访问高峰;

  • 冗余
    保证部分服务器宕机的情况下,网站依然可以继续服务,不丢失数据,进行一定程度的服务器冗余,数据冗余备份;

  • 自动化
    自动化代码管理,自动化发布,自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源;

  • 安全
    网络通信加密,防止常见攻击,如XSS攻击、SQL注入、垃圾信息过滤;

3.大型网站核心架构要素

  • 性能
    性能优化:浏览器端、应用服务器端、异步、代码层面优化、数据库优化;
    性能指标:响应时间、TPS、系统性能计数器
  • 可用性
    网站高可用的主要手段是容易,应用部署在多台服务器上,通过负载均衡对外提供服务;
  • 伸缩性
    不断向集群中加入服务器来缓解不断上升的用户并发访问压力和不断增长的数据存储需求;
  • 扩展性
    事件驱动架构:通常利用消息队列实现;
    分布式服务:将业务和可复用的服务分离开来,通过分布式服务框架调用;
  • 安全性

4.网站的高性能架构

网站性能测试

  • 性能测试指标
    √ 响应时间:应用执行一个操作需要的时间,从发出请求开始到响应所需数据的时间;
    √ 并发数:系统能同时处理请求的数目,对于网站而言,并发数即网站并发用户数; 网站系统用户数 >> 网站在线用户 >> 网站并发用户数
    √ 吞吐量:单位时间内系统处理的请求数量,体现系统的整体处理能力。 TPS是每秒事务数,HPS是每秒HTTP请求数,QPS是每秒查询数;
    √ 性能计数器:包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O
  • 性能测试方法
    √ 性能测试
    √ 负载测试
    √ 压力测试
    √ 稳定性测试
  • 性能测试报告
  • 性能优化策略
    √ 性能分析
    √ 性能优化

Web前端性能优化

  • 浏览器访问优化
    √ 减少http请求:http请求是无状态的,每次http请求都需要建立通信链路进行数据传输。主要手段有:合并CSS、合并JS、合同图片等资源
    √ 使用浏览器缓存
    √ 启用压缩
    √ CSS放在页面最上面、JS放在页面最下面
    √ 减少Cookie传输

  • CDN加速

  • 反向代理

应用服务器性能优化

主要手段有缓存、集群、异步等

  • 分布式缓存
    网站性能优化第一定律:优先考虑使用缓存优化性能。
    缓存的本质是Hash表,数据缓存以一对Key、Value的形势存储在内存Hash表中,Hash表数据读写时间复杂度是O(1)。
  • 使用异步操作
    使用消息队列讲调用异步化,可以改善网站的扩展性;
  • 使用集群
    网站高并发访问场景下,使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群,将并发访问的请求分发到多台服务器上处理,避免单一服务器因负载压力过大二响应缓慢。
  • 代码优化
    √ 多线程:最大限度的使用CPU资源
    最佳启动线程数和CPU内核数量成正比,和IO阻塞时间成反比;
    多线程编程要考虑线程安全的问题:将对象设计为无状态对象,使用局部对象,并发访问资源是使用锁;
    √ 资源复用:单例和对象池
    √ 数据结构
    √ 垃圾回收

存储性能优化

  • 机械硬盘VS固态硬盘
  • B+树 Vs LSM树
    B+树是一种转么针对磁盘存储优化的N叉排序树,以树节点为单位存储在磁盘中,从跟开始查找所需数据所在的节点编号和磁盘位置,将其加载到内存中继续查找;目前关系型数据库多采用两级索引的B+树;
    LSM树可以看做是一颗N阶合并树,数据写操作都在内存中进行,并且都会创建一个新的记录,这些数据在内存中仍然是一颗排序树。目前需要NoSQL产品采用LSM树做主要数据结构;
  • RAID VS HDFS
    目前服务器级别的计算机都支持插入多块磁盘,通过使用RAID技术,实现数据在多块磁盘上的并发读写和数据备份;
    HDFS(Hadoop分布式文件系统),系统在整个存储集群的多台服务器上进行数据并发读写和备份。

5.网站高可用架构

网站可用性度量与考核

  • 网站可用性度量
    网站不可用时间(故障时间) = 故障修复时间点 - 故障发现时间点
    网站年度可用性指标 = (1-网站不可以时间/年度总时间)* 100%
    2个9是基本可用,网站年度不可用时间小于88小时
    3个9是较高可用,网站年度不可用时间小于9小时
    4个9是具备自动恢复能力的高可用,网站年度不可以用时间小于53分钟
    5个9是极高可用性,网站年度不可用时间小于5分钟
  • 网站可用性考核
    故障分是指对网站故障进行分类加权计算故障责任的方法。
    故障分 = 故障时间(分钟) * 故障权重

高可用网站架构

典型的网站设计通常遵循三层分层架构模型:应用层、服务层、数据层;
实现高可用架构的主要手段是数据和服务的冗余备份和失效转移。

高可用的应用

应用的显著特点是无状态性

  • 通过负载均衡进行无状态服务的失效转移
  • 应用服务器集群的Session管理
    Session管理的主要手段有:Session复制、session绑定、利用Cookie记录Session、Session服务器

高可用的服务

  • 分级管理
  • 超时设置
  • 异步调用
  • 服务降级
  • 幂等性设计

高可用的数据

  • CAP原理:一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availbility)、分区耐受性(Patition Tolerance)这三个条件。
    大型网站通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),而在一定程度上放弃一致性(C)
    数据一致性又分为:数据强一致性、数据用户一致性、数据最终一致性
  • 数据备份:冷备和热备,热备又分为异步热备和同步热备;
  • 失效转移:失效确认、访问转移、数据恢复

高可用网站的软件质量保证

  • 网站发布: 使用发布脚本来发布,每次关闭服务器都是机器中的一小部分,并且发布完成后可以立即访问;
  • 自动化测试:Web自动化测试技术
  • 预发布验证:预发布服务器和线上正式服务器的唯一不同就是没有配置在负载均衡服务器上,外部用户无法访问;
  • 代码控制
  • 自动化发布
  • 灰度发布

网站运行监控

  • 监控数据采集:
    √ 用户行为日志收集:服务端日志收集、客户端浏览器日志收集
    √ 服务器性能监控
    √ 运行数据报告
  • 监控管理:系统报警、失效转移、自动优雅降级

6.网站伸缩性架构

网站架构的伸缩性设计

  • 不同功能进行物理分离实现伸缩
    纵向分离(分层后分离):将业务流程上的不同部分分离部署,实现系统伸缩性;
    横向分离(业务分割后分离):将不同的业务模块分离部署
  • 单一功能通过集群规模实现伸缩
    使用服务器集群,将相同服务部署在多台服务器上构成一个集群整体对外提供服务;

应用服务器集群的伸缩性设计

  • HTTP重定向负载均衡
    优点是简单,缺点是浏览器需要两次请求服务器才能完成一次访问,性能较差;
  • DNS域名解析负载均衡
    每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回,这样A记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。
  • 反向代理负载均衡
    优点是部署简单,缺点是反向代理服务器是所有请求和响应的中转站,其性能可能成为瓶颈;请求在HTTP协议层面,也叫作应用层负载均衡。
  • IP负载均衡
    在网络层通过修改请求目标地址进行负载均衡;
  • 数据链路层负载均衡
    在通信协议的数据链路层修改mac地址进行负载均衡;Linux平台式最好的链路层负载均衡开源产品是LVS(Linux Visual Server)
  • 负载均衡算法
    √ 轮询(Round Robin,RR)
    √ 加权轮询(Weighted Round Robin,WRR)
    √ 随机(Random)
    √ 最少连接(Least Conections)
    √ 源地址散列(Source Hashing)

7.网站的可扩展架构

利用分布式消息队列降低系统耦合性

  • 事件驱动架构
    通过低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完成模块间的合作。
  • 分布式消息队列
    队列是一致先进先出的数据结构,分布式消息队列可以看做将这种数据结构部署到独立的服务器上,应用程序可以通过远程访问接口使用分布式消息队列,进行消息的存取操作,进而实现分布式的异步调用。

利用分布式服务打造可复用的业务平台

分布式消息队列通过消息对象分解系统的耦合性,不同子系统处理同一个消息;分布式服务则通过接口分解系统的耦合性,不同子系统通过相同的接口描述进行服务调用。
  • Web Service与企业级分布式服务
    优点是成熟的技术规范和产品实现,缺点是臃肿的服务注册于发现机制,低效的XML序列化收到,开销较高的HTTP通信机制;
  • 大型网站分布式服务的需求与特点
    √ 负载均衡
    √ 失效转移
    √ 高效的远程通信
    √ 整合异构系统
    √ 对应用最少侵入
    √ 版本管理
    √ 实时监控
  • 分布式服务框架设计
    Dubbo
    Thrift

可扩展的数据结构

无需修改表结构就可以新增字段的数据库,NoSQL产品

利用开放平台建设网站生态圈

开放网站内部服务,封装成一些调用接口开放出去,供外部的第三方开发者使用。

8.网站的安全性架构

网站应用的攻击与防御

 XSS攻击
XSS攻击即跨站点脚本攻击,值黑客通过篡改网页,并注入恶意的HTML脚本,在用户浏览网页时,控制用户浏览器进行恶意操作的一种攻击方式。
常见的XSS攻击类型有两种:反射型和持久型;
消毒:进行过滤和消毒处理,对html脚本中的危险字符转义;
HttpOnly:浏览器紧张页面JS访问带有HttpOnly属性的Cookie。

  • 注入攻击
    SQL注入攻击和OS注入攻击
    消毒:过滤请求中可能注入的SQL
    参数绑定:使用预编译授权,绑定参数是最好的防SQL注入方法;
  • CSRF攻击
    跨站点请求伪造,攻击者通过跨站请求,以合法的用户身份进行非法操作,核心是利用了浏览器Cookie或服务器Session策略;
    防御手段:表单Token、验证码、Referer check
  • 其他攻击和漏洞
    √ Error Code:故意制造非法输入,使系统运行出错,获得异常信息,从而寻找系统漏洞进行攻击;
    √ HTML注释:应避免HTML语法注释
    √ 路径遍历
  • Web应用防火墙
    使用开源的或者商用的网站防火墙
  • 网站安全漏洞扫描
    不定期对网站服务器进行扫描,查漏补缺;

信息加密技术及秘钥管理

  • 单向散列加密
    对不同输入长度的信息进行散列技术,得到固定长度的输出,散列计算过程是单向不可逆的;常见的单向散列算法有MD5、SHA
  • 对称加密
    加解密秘钥是同一个,通常用于需要安全交换或存储的场合,如Cookie加密,通信加密等;
    优点:算法简单、加解密效率高,缺点是秘钥泄露就不安全了;
    常见的对称加密算法有:DES加密,RC加密
  • 非对称加密
    非对称加密和解密的秘钥不是同一个,其中一个对外界公开称为公钥,另外一个只有所有者指定,称为私钥;
    场景:信息安全传输、数字签名
    常见算法:RSA算法
  • 密钥安全管理
    密钥和算法放在一个独立的服务器上,甚至做成一个专用的硬件设施;
    加解密算法放在应用系统,秘钥放在独立服务器上;

信息过滤与反垃圾

常用的信息过滤与反垃圾手段有以下几种:

  • 文本匹配:主要是解决敏感词问题;
  • 分类算法:简单实用的贝叶斯分类算法
  • 黑名单:被报告的垃圾邮箱放入黑名单

电子商务风险控制

  • 风险:账户风险、卖家风险、买家风险、交易风险
  • 风控:规则引擎、统计模型
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容