<大型网站技术架构核心原理与案例分析>要点总结

 <大型网站技术架构核心原理与案例分析>要点总结

前段时间阅读了《大型网站技术架构核心原理与案例分析》这本书,感觉还不错,对常见的服务器架构有了全面了解,对性能测试分析和调优有很大的帮助,以下是该书的核心要点:

大型网站软件系统特点:
1.高并发,大流量
2.高可用性(7x24)
3.海量数据
4.用户分布广泛,网络情况复杂
4.安全环境恶劣
5.需求开速变更,发布频繁
6.渐进式发展

网站加速网站访问速度的主要手段

  • 反向代理

反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。此时代理服务器对外就表现为一个Web服务器,外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于,这个服务器没有保存任何网页的真实数据,所有的静态网页或者CGI程序,都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏,这样就增强了Web服务器的安全性。

  • CDN

CDN的全称是Content Delivery Network,即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。通过在网络各处放置反向代理节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上

大型网站架构模式

  • 分层(横向切割)

网络七层协议是一种分层结构,计算机硬件,OS,APP也是一种分层结构,网站系统一般分为(逻辑层)

 - 应用层:业务逻辑层,业务和视图的展示,如文库,贴吧,知道,百科
 - 服务层:提供可复用的服务,为应用层提供服务支持,如账户服务,Session服务,登录服务
 - 数据层:提供数据存储访问,如数据库,缓存,文件,搜索引擎等
  • 分割(纵向切割)

:将不同的功能和服务分割开来,包装成高内聚低耦合的模块单元,有助于软件的开发维护,也便于不同模块的分布式部署,提高网站的并发处理和功能扩展能力;网站系统的每一层都可以继续分割成不同的模块。

  • 分布式:

分层和分割的目的就是为了切分后的模块便于分布式部署到不同的服务器上,通过远程调用协同工作;分布式意味着更多的技术安吉完成同样的功能

 - 缺点: 一台服务器宕机导致很多应用不能访问,网站可用性降低分布式环境中的数据一致性非常困难 网站依耐性错综复杂
   常见分布式方案:分布式应用和服务,分布式静态资源,分布式数据和存储,分布式计算
  • 集群:

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

  • 缓存:

主要手段有CDN,反向代理,本地缓存,分布式缓存
网站性能优化第一定律:优先考虑使用缓存优化性能

 - 缓存好处:1.缓存访问速度快,可以减少数据库访问时间
   2.如果缓存的数据是经过处理的,那么缓存的数据无需经过重复计算即可直接使用,减少了计算时间

 - 缓存简述:
   缓存的本质是一个内存Hash表,数据以一对Key,Value的形式存储在内存Hash表中;计算KV对中Key的HashCode对应的Hash表索引,可以快速访问Hash表中的数据
   计算Hash表的索引下标最简单的是余数法: HashCode除以Hash表数组长度,余数就是Hash表索引下标

 - 缓存预热:缓存存放的是热点数据,热点数据是利用LRU算法筛选淘汰出来的,这个过程需要较长时间;新启动的缓存系统如果没有任何数据,重建缓存数据对系统和数据库性能都不太好,最好在缓存系统启动时就把热点数据加载好,这个缓存预加载手段叫缓存预热

 - 缓存穿透:如果不恰当的业务或者恶意攻击持续高并发地请求某个不存在的数据,由于缓存没有保存该数据,所有的请求就会落到数据库上,对数据库造成很大的压力,甚至崩溃。一个简单的方法就是将不存在的数据也缓存起来(其Value值为null)
   缓存使用前提条件  数据热点访问不均衡,某些数据会被更频繁的访问,这些数据就该放在缓存中
   数据在某个时间段内有效,不会很快过期,否则会导致数据因失效而产生脏读,影响数据的有效性
  • 异步:

业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步执行进行协作
异步架构师典型的生产者消费者模式,两者不存在直接调用,互不影响

 - 特点:加快网站响应速度,提供系统的可用性(消费者服务器故障不会督导制生产者服务器继续执行),消除并发访问高峰
   举例如新浪微博的异步推送模式:用户发表微博后,系统会家庭这条微博插入到数据库所有的粉丝的订阅列表中,用户量大的时候数据库会超出负载,性能下降,从而采用异步推拉结合模式:
   用户发表微博后系统将微博写入消息队列后立即返回,用户响应迅速 消息队列消费者任务将微博推送给所用在线粉丝的订阅列表中
   非在线用户登录后再根据关注列表拉取微博哦订阅列表
  • 冗余:

服务器宕机的情况下网站依然可以继续服务,不丢失数据,就需要一定程度的服务器冗余运行,数据冗余备份

 - 数据库备份方式:冷备份(拷贝重要文件到其他存储介质上,如光盘),热备份(同步,主从分离),灾难数据中心(抵抗地震,海啸等,全球范围内部署的)
  • 自动化:

主要包括网站发布自动化,自动化监控,自动化报警,自动化恢复等等

  • 安全:

对用户数据进行加密处理,防止机器人程序滥用网络资源攻击网站,使用验证码识别,过滤垃圾,敏感信息等等

优化性能的主要方式

  • web前端访问优化:
    减少浏览器请求,浏览器缓存,页面压缩,CSS放页面最上面,Javascript放在页面对下面,减少cookie传输,CDN,反向代理等等
  • 应用服务器端:
    服务器本地缓存,分布式缓存,异步操作(消息队列),集群
  • 代码层面:
    使用多线程,改善内存管理等手段优化性能 使用多线程原因:IO阻塞与多CPU
    (当前线程进行I/O处理时,会被阻塞释放CPU以等待I/O完成,利用多线程I/O阻塞与执行交替进行,最大限度的利用CPU资源)

一台服务器上启动多少线程为最优:
启动线程数=【任务执行时间/(任务执行时间-IO等待时间)】x CPU内核数
如果IO等待时间为0,最优线程数=CPU内核数
如果任务是CPU计算型任务,线程数最多不超过CPU内核数,因为启动再多的线程,CPU也来不及调度
如果任务是需要等待磁盘操作及网络响应,那么多启动线程有助于提高任务并发度,提高系统吞吐能力,改善性能 (Daniel:CPU在等待IO或网络的同时,可以被其他线程调度使用,最大限度的利用了CPU)

连接池:
对于数据库连接对象,每次创建,数据库服务端都需要创建专门的资源以应对,因此频繁创建关闭数据库连接,对数据库是灾难性的,而使用连接池方式:数据库每次连接对象创建好后,将连接对象放入对象池容器中,使用时获取一个空闲的连接,使用完毕后再归还即可,不需要重新创建新的连接
系统崩溃前的一些现象:
每次垃圾回收的时间越来越长,由之前的10ms延长到50ms左右,FullGC的时间也有之前的0.5s延长到4、5s
(根据内存模型和垃圾回收算法,垃圾回收分两部分:内存标记、清除(复制),标记部分只要内存大小固定时间是不变的,变的是复制部分,
因为每次垃圾回收都有一些回收不掉的内存,所以增加了复制量,导致时间延长。所以,垃圾回收的时间也可以作为判断内存泄漏的依据)
FullGC的次数越来越多,最频繁时隔不到1分钟就进行一次FullGC
(因此内存的积累,逐渐耗尽了年老代的内存,导致新对象分配没有更多的空间,从而导致频繁的垃圾回收)
年老代的内存越来越大并且每次FullGC后年老代没有内存被释放
(因为年轻代的内存无法被回收,越来越多地被Copy到年老代)

数据库服务器端:
索引,缓存,SQL优化,NoSQL(优化数据模型,存储结构,伸缩性)

  • 可用性:

假设系统中任何一台或者多台服务器宕机时,系统是否依然可用
伸缩性:(增加服务器面向同一功能模块)指通过不断向服务器集群中加入服务器的手段来缓解不断上升的并发访问压力不不断增长的数据存储需求

  • 扩展性:

(增加服务器面向新的功能模块)网站增加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线的新产品

  • 安全性
  • 其他

性能测试曲线:c点位系统最大负载点;d点位系统崩溃点;以下为性能测试,负载测试,压力测试区别
这里写图片描述

网站不可用也被称为网站故障,业界通常用多少个9来衡量网站的可用性,如QQ的可用性是4个9,即QQ服务器99.99%可用

  • 2个9:基本可用,网站年度不可用时间小于88小时
    3个9:较高可用,…………………………………………..9小时
    4个9:具有自动恢复能力的高可用………………53分钟
    5个9:极高可用………………………………………………..5分钟

  • Session:

在计算机中,尤其是在网络应用中,称为“会话控制”。Session 对象存储特定用户会话所需的信息。这样,当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。

  • CAP原则

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼
一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。(系统中有部分服务或模块挂掉或失效的时候,不影响系统正常服务)

大型网站典型故障

  • 日志故障

log输出level全局配置为Debug,导致服务器磁盘报警,甚至宕机
Log输出级别分为三种:SEVERE,WARNING、INFO和DEBUG,SEVERE是导出服务器的严重报错日志,WARNING 输出执行报表时的错误或警告信息,INFO则是导出所有报错信息,DEBUG是指在INFO的基础上不输出SQL语句执行语句的信息,只有在DEBUG的 状态下才输入SQL执行语句信息

  • 高并发访问数据库引起的故障

故障现象:数据库Load居高不下,持续报警
原因分析:某条简单的SQL查询语句执行频率非常高导致的,应该将该语句或其数据放到缓存服务器中,避免访问数据库

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值