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

1、大型网站架构演化

一、大型网站特色

• 高并发，大流量
• 高可用
• 海量数据
• 用户分布普遍，网络状况复杂
• 安全环境恶劣
• 需求快速变动，发布频繁
• 渐进式发展

二、大型网站架构发展历程

• 文件服务器，数据库服务器，应用服务器分离
• 应用服务器增长本地缓存，本地缓存优先，增长分布式缓存服务器
• 使用应用程序服务器集群提升网站的并发，由负载均衡服务器统一调度分发
• 使用分布式文件系统和分布式数据库系统
• 使用CDN网络加速和反向代理服务器：基本原理都是缓存，CDN部署在网络提供商的机房，是用户在请求网络服务时，能够从距离本身最近的网络提供商机房获取数据。而反向代理是部署在中心机房，当用户的请求到达中心机房后，首先访问的是反向代理服务器，若是反向代理服务器中缓存这用户请求的资源，就将其直接返回给用户，目的都是尽早返回数据给用户，加快用户访问速度，减轻后端服务器的压力。
• 使用Nosql和搜索服务器
• 业务拆分，根据不一样的产品，不一样的业务，将一个网站拆分红不一样的应用，每一个应用独立部署维护，各个应用之间经过消息中间件或者访问同一个数据存储系统来构成一个相互关联的完整系统
• 分布式服务，将公用的业务提取出来，独立部署，为其余应用服务器提供可复用的共用业务服务（能够经过dubbo和zookeeper集群实现）

三、网站架构的价值观和设计误区

• 架构的选取随网站所需灵活应对
• 主要驱动力量是网站的业务发展
• 不可一味追随大公司的架构设计，照搬照抄
• 网站技术是为了业务存在的，不可为了技术而技术
• 不要企图使用技术解决一切问题。技术是用来解决业务问题的，一样业务问题也能够采用业务手段，经过修改业务架构来解决

2、大型网站架构模式

一、分层

将系统在横向纬度上分红几个部分，每一个部分负责单一职责，经过上层对下层的依赖和调用组成一个完整的系统。网络的7层通信协议，计算机硬件、操做系统、应用软件，都采用了分层的思想。将网站系统分为应用层、服务层、数据层，三层结构分别部署在不一样的服务器上

• 应用层：负责具体业务和视图展现
• 服务层：为应用层提供服务支持，如用户管理服务、购物车服务
• 数据层：提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等

二、分割

在纵向方面对系统进行划分，好比应用层，能够将不一样业务分割，将购物、论坛、搜索、广告分割成不一样的应用，由独立的团队负责。部署在不一样的服务器上。

三、分布式

分层和分割的目的就是为了切分后的模块便于分布式部署，将不一样的模块部署在不一样的服务器上。同时，分布式也带来了不少问题，

• 不一样服务器之间的通讯对网络依赖很大
• 保持数据一致性比较困难
• 网站依赖错综复杂，开发维护困难

    常见的分布式方案有如下几种

• 分布式应用和服务。
• 分布式静态资源
• 分布式数据和存储
• 分布式计算
• 分布式文件系统
• 分布式锁
• 分布式配置。支持网站线上服务配置实时更新

四、集群

虽然分布式已经将各个应用分开部署，可是对于用户集中访问的模块，还须要独立部署服务器集群化，即多台服务器部署相同应用构成一个集群，经过负载均衡设备共同对外提供服务。而且支持线性扩展，发生故障时的失效转移。即便是访问量很小的分布式应用和服务也至少要部署两台构成小的集群，提升系统的可用性

五、缓存

缓存是改善软件性能的第一手段。大型网站不少方面都使用了缓存设计：

• CDN，即内容分发网络。在这里缓存网站的一下静态资源（较少变化的数据），能够就近以最快速度返回给用户。如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN
• 反向代理。当用户的请求到达数据中心时，最早访问到的是反向代理服务器，这里缓存网站的静态资源，无需继续将请求转发给应用服务器，直接返回给用户
• 本地缓存。在应用服务器本地缓存这热点数据，应用程序能够在本地内存中直接访问，无需访问数据层
• 分布式缓存。将数据存储在专门的分布式缓存集群中，应用服务器经过网络通信访问缓存数据。

      缓存同时也存在着缓存击穿、缓存雪崩、缓存热点不集中的问题

六、异步

在单一服务器内部可经过多线程共享内存队列的方式实现异步，在分布式系统中，多个服务器集群经过分布式消息队列实现异步。异步架构是典型的生产者-消费者模式。使用异步消息队列可以带来以下好处：

• 提升系统可用性
• 提升系统响应速度
• 消除并发访问高峰。消息队列可以把忽然增长的访问请求数据放入到队列中，等待消费者处理，不会对网站形成太大压力

七、冗余

为了提升系统的可用性，防止某些服务器宕机的状况下系统依然能够继续服务，须要必定的服务器冗余运行、数据冗余备份。数据库除了按期备份实现冷备份以外，还须要主从分离，实时同步实现热备份。为了抵御海啸、地震等不可抗力，还须要在全球范围内部署灾备数据中心。

八、自动化

发布过程自动化：自动化代码管理，自动化测试，自动化安全测试，自动化部署。系统运行过程当中还有：自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化资源分配。

九、架构模式在新浪微博的应用

新浪微博系统分为三层：

• 最下层是基础服务层，提供数据库、缓存、搜索、存储等基础服务
• 中间层是平台服务和应用服务层，微博的核心是微博、用户、关系，这些服务被分割成独立的模块，经过依赖调用和对共享基础服务构成微博的业务基础
• API层，是微博的业务层，包括网站、app、第三方应用，经过调用API集成到微博系统中，共同组成一个生态系统

微博的发布，早起使用同步推模式，用户发表微博后会当即将这条微博插入到数据库全部粉丝的订阅列表中，用户量比较大时，会引发大量的数据库写操做，超出负载，致使系统性能降低。后来改用异步推拉方式，用户发表微博以后马上写到消息队列中而后马上返回，消息队列消费者将微博推送给当前在线粉丝的订阅列表中，非在线用户等登陆后在根据关注列表拉取微博订阅列表

因为微博频繁刷新，微博使用多级缓存策略，热门微博和明星微博缓存在全部的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中

3、大型网站核心结构要素

一、性能。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  通常取平均响应时间

        QPS（TPS）= 并发数/平均响应时间

二、高可用

指的是网站能够保证大部分时间系统都是可用的，一些知名大型网站能够获得99.99%的时间都是可用的。高可用的设计目标是当有部分服务器宕机时，总体的服务或者应用依然可用。

• 保证网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供访问，数据存储在多个服务器上互相备份，任何一台服务器宕机都不会影响应用的总体可用。
• 网站的高可用还须要软件开发过程的质量保证，经过预发布验证、自动化测试、自动化发布、灰度发布等手段，减小将故障引入线上环境的可能。

三、伸缩性

衡量的主要指标就是是否能够用多台服务构架集群，是否容易向集群中添加新的服务器，加入的新的服务器是否能够提供和原来服务器无差异的服务，集群可容纳的总服务器数量是否有限制。

• 应用服务器，经过使用合适的负载均衡设备，就能够向集群中不断加入服务器
• 缓存服务器集群，加入新的服务器可能会致使缓存路由失效，若是对缓存的依赖严重，可能会致使系统崩溃。
• 关系数据库。虽然支持主从复制，主从热备，可是很难作到大规模集群的可伸缩性。所以关系型数据库的可伸缩性方案必须在数据库以外实现，经过路由分区等手段，将多个部署的数据库服务器集成一个集群。
• NoSql数据库。因为其先天就是为了海量数据而生的，所以对可伸缩性的支持很是好。

四、扩展性

衡量的主要标准就是网站增长新的业务产品时，是否会对现有产品产生影响，不须要改动或不多改动既有业务就能够上线新产品，不一样产品之间不多的耦合，一个产品改动对其余产品没有影响。

网站的可扩展架构的主要手段是事件驱动架构和分布式服务

• 事件驱动，一般利用消息队列实现，把消息的生产者和消费者分开，这样能够透明的增长新的生产者和消费者
• 分布式服务则是将业务和可复用服务拆分开，经过分布式服务调用可复用服务。可复用服务升级变动的时候，也能够经过提供多版本服务实现透明升级，不须要强制应用同步变动。

五、安全性

网站的安全架构须要保证网站不受恶意访问和攻击、保护网站的重要数据不被窃取。

 4、网站的高性能架构

一、网站性能测试

性能测试指标。主要指标有响应时间、并发数、吞吐量、性能计数器

        

二、Web前端性能优化

浏览器访问优化

• 减小http请求。合并css、JavaScript、图片，将浏览器一次访问须要的资源合并成一个文件
• 使用浏览器缓存。经过设置http头部中的Cache-Control和Expires属性，设置浏览器缓存。将css、javascript、图片等静态资源经过浏览器缓存起来，若是须要静态资源及时应用到客户端浏览器，可经过改变文件名实现。
• 启用压缩。在服务端对文件进行压缩，在浏览器端对文件进行解压缩，有效减小通信传输的数据量，会对服务器和浏览器产生必定的压力，通讯宽带良好，服务器资源不足的状况下，不适合采用
• 减小cookie传输，cookie包含在每次请求和响应中，太大的cookie会影响数据传输。深刻了解，cookie和session的区别

CDN加速

CDN，内容分发网络，本质上也是缓存，并且将缓存在里用户最近的地方。部署在网络运行商的机房，CDN缓存的是一些静态资源

反向代理

• 反向代理服务器位于网站机房一侧，代理网站web服务器接受http请求。具备保护网站安全的做用
• 代理服务器能够经过配置缓存功能加速web请求，当用户第一次请求静态内容的时候，就被缓存在反向代理服务器上
• 也能够实现负载均衡的功能

三、应用服务器性能优化

分布式缓存

• 合理使用缓存，频繁修改的数据不适合缓存，读写比在2:1之上，缓存才有意义
• 没有热点访问的数据，不适合作缓存
• 数据不一致，数据库修改了数据并不会当即修改缓存，存在时间差
• 分布式缓存服务器，提升缓存的可用性
• 缓存预热，启动时就把热点数据放入缓存中。热点数据是利用LRU（最近最久未用算法）对不断访问的数据筛选淘汰出来的
• 缓存穿透，大量请求不存在的数据，绕过缓存直达数据库。一个简单的策略：将不存在的数据也缓存起来
• 分布式缓存架构：一种是须要同步更新的分布式缓存，规模较大时，缓存更新数据须要同步到全部缓存服务器，代价惊人。另外一种是以memcache为表明的互不通讯的分布式缓存架构，应用程序经过一致性hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通讯，集群规模能够很容易的扩容，具备良好的可伸缩性。

异步操做，能够晚点作的事情都应该晚点作

使用集群

代码优化

• 多线程充分利用多CPU和解决IO阻塞问题，利用多线程IO阻塞与执行充分利用CPU资源。同时须要解决线程安全问题，将对象设计成无状态对象，使用局部变量，在修改共同资源时加锁
• 资源复用。尽可能复用开销很大的资源，好比数据库链接、线程、复杂对象
• 优化数据结构，好比hash表，要尽可能减小hash冲突，hashcode越散列，冲突越少，读写性能也就越好，目前比较好的字符串Hash散列算法有Time33算法和指纹加密算法md5结合使用。先对字符串指纹加密，对加密后的字符串进行Time33。
• 垃圾回收，JVM调优，尽可能减小Full GC ，甚至从不进行Full GC

四、存储性能优化

SSD固态硬盘vs机械硬盘

• 机械硬盘，每次访问数据，都须要移动磁头臂，顺序访问和随机访问性能差异很大
• SSD固态硬盘，没有机械装置，数据存储在可持久记忆的硅晶体上，能够像内存同样随机访问

B+树vs LSM树

为了改善数据访问特性，文件系统和数据库系统会对数据排序后存储，加快数据检索速度，须要保证新的数据插入、更新、删除后依然有序。

• 传统关系型数据库一般采用B+树
• 目前许多NoSQL产品采用LSM树最为主要数据结构，能够看作是一个n阶合并树

5、网站的高可用架构

一、高可用的应用层服务

• 负载均衡服务器经过心跳检测机制发现故障服务器失去响应，就会把它从服务器列表中剔除，而将请求发送到其余服务器上。
• 服务器集群的session管理，分布式缓存服务器，负载均衡服务器经过hash算法老是未来源于同一ip的请求分发到同一台服务器上

二、高可用的基础公共服务

使用相似负载均衡的失效转移策略实现高可用的基础服务，此外，还有几点基于实践的高可用基础服务的策略：

• 分级管理。把基础服务分为核心服务和非核心服务，低级别的服务须要部署在不一样的虚拟机上进行隔离，高优先级的服务须要部署在不一样的物理机上进行隔离、而核心服务和数据甚至要部署在不一样地域的数据中心进行隔离
• 超时设置。
• 异步调用。应用对服务的调用经过消息队列等异步方式完成
• 服务降级。在网站访问的高峰期，系统压力增大，性能降低，严重会致使系统宕机。为了核心应用正常运转，须要对服务进行降级。有两种方式：1 是拒绝低优先级应用的调用或者随机拒绝部分请求调用。2 是关闭不重要的服务，好比双十一最繁忙时段关闭“评价、确认收货”等功能
• 幂等性设计。重复调用和调用一次产生的效果相同，即服务具备幂等性

三、高可用的数据服务

保证数据高可用的主要手段是数据备份和失效转移机制。

• 经过强化CAP理论中的A（可用性）、P（分区容错性，跨网络分区的伸缩性），而在某种程度上放弃C（一致性）。根据BASE理论，保证最终一致性，和用户一致性。
• 数据备份分为冷备、异步热备、同步热备。异步热备下，存储服务器分为主和从，写入操做在主服务操做成功以后当即返回成功，而后经过异步线程同步到从服务。同步热备，等待全部存储服务写入成功以后，再通知应用程序写操做成功。
• 失效转移由三部分组成。失效确认、访问转移、数据恢复。失效确认经过心跳检测或应用程序失败报告完成

四、高可用的软件质量保障

• 网站发布，发布过程当中每次关闭的都是集群中的一小部分，并保证发布完成后当即能够访问。具体过程：先关闭负载均衡服务器上的一下部分服务器路由，关闭这些服务器，部署新的代码，启动这些服务，打开负载均衡的路由，重复操做直到集群中全部的机器发布完成。
• 自动化测试，自动化测试工具ThoughtWorks开发的Selenium，运行在浏览器中，模拟用户操做进行测试。
• 预发布验证，预发布机器是位于负载均衡路由以外的机器。一旦启动时发现错误，马上失败抛出异常，中止启动让工程师介入排查错误，而不是启动后执行错误的操做。须要快速失败机制
• 代码版本控制。
• 自动化发布。火车发布模型来实现自动化发布
• 灰度发布。天天只上线一小部分服务器，一旦发现有问题，回滚一小部分服务便可，不须要回滚全部服务

五、网站运行监控

监控数据采集

• 用户行为日志采集，分为服务端日志采集和客户端浏览器日志采集
• 服务器性能监控，开源性能监控工具Ganglia，支持大规模服务器集群，支持以图形的方式在浏览器展现实时的性能曲线
• 运行数据报告

监控管理

• 系统报警
• 失效转移
• 自动优雅降级

6、网站的伸缩性架构

 一、网站的伸缩性设计经过如下两种方式实现

• 根据功能从横向和纵向进行物理分离实现伸缩
• 分离以后的单一功能经过集群实现伸缩，集群内多台服务器部署相同应用，提供相同的功能

二、应用服务器的伸缩性设计

• 负载均衡服务器实现http请求的分发
• http重定向负载均衡，这种方式比较简单，可是一次用户请求须要请求两次服务器，重定向服务器自身的处理能力可能成为瓶颈，实践中这种方案不经常使用
• DNS域名解析负载均衡，控制权在域名服务商那里，没法提供更强大的管理。DNS是多级解析，修改以后较长时间才能生效。实践中，利用域名解析做为第一级负载均衡手段，即域名解析获得的是一组负载均衡服务器的ip地址
• 反向代理负载均衡，反向代理服务器转发请求在http协议层面，叫作应用层负载均衡，方向代理服务器的性能有可能会成为瓶颈
• 数据链路层负载均衡，指在通信协议的数据链路层修改修改mac地址进行负载均衡。分发过程当中不修改ip地址，只修改目的mac地址，经过配置真实物理机集群全部机器虚拟ip和负载均衡服务器ip相同，真实处理用户请求的服务器可直接将数据返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。目前linux平台最好的数据链路层负载均衡产品是LVS（Linux  Virtual Server）
• 负载均衡算法。轮询（Round Robin）、加权轮询、随机（Random）、最少链接（Least Connections）、原地址散列（Source Hashing）

三、分布式缓存的伸缩性设计

Memcached分布式缓存集群，一致性hash算法来保证新缓存服务器加入集群后不会影响集群的稳定性

四、数据存储服务器的负载均衡

• 关系型数据库的伸缩性设计。经过数据复制主从分离，根据不一样的业务分割数据分库，若是及时这样单张表仍是很大，就须要进行单表分片。目前支持数据分片的关系型数据库产品主要有Amoeba和Cobar
• Cobar服务器集群的伸缩：是无状态的服务器，能够经过简单的负载均衡的手段实现
• Mysql服务器集群的伸缩：集群中添加新服务器，须要利用一致性hash算法，进行尽可能少的数据移动来保证扩容后数据一致，Mysql数据同步以Schema为单位，使用Mysql的同步机制。不支持join操做
• Nosql数据库的伸缩性设计。应用最普遍的Apache的Hbase

7、网站的可扩展架构

一、用分布式消息队列下降系统耦合性

二、利用分布式服务打造可复用的业务平台。分布式服务架构须要支持以下特色：

• 负载均衡。对于热门服务，须要部署在一个集群上，负载均衡
• 失效转移
• 高效的远程通讯
• 整合异构系统，整合不一样的语言，不一样的平台
• 版本管理，须要支持服务多版本发布，服务发布者先升级接口发布新版本的服务，同时提供旧版本服务供请求者调用
• 实时监控

三、分布式服务架构框架设计。经常使用的Dubbo，他的远程通讯模块支持多种通信协议和数据序列化协议，使用NIO通信框架，具备较高的网络通信性能。

四、可扩展的数据结构

传统的关系型数据库设计之初，须要指定表的字段、数据类型等，比较僵硬，不利于之后的扩展。虽然能够经过预设冗余字段来解决，可是也是一种较糟糕的设计。

许多Nosql数据库使用的ColoumFamily（列族）设计就是一个解决方案，无需指定字段，能够在数据写入时再指定，经过这种方式，数据表能够包括数百万的字段

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

8、网站的安全架构

一、攻击与防护

• xss攻击，跨站点脚本攻击，经过篡改网页，注入恶意的html脚本，在用户浏览网页时，控制用户浏览器进行恶意操做的一种攻击行为。XSS攻击者通常都是经过在请求中嵌入恶意脚本达到攻击的目的，须要对请求进行过滤和消毒处理。
• sql注入攻击，经过在http请求中嵌入恶意sql命令，经过正则匹配对请求参数进行消毒处理

二、信息加密技术

• 单向散列加密，md五、sha等。经过对明文和salt利用单向散列加密算法得出密文，数据库中存储加密以后的密文。输入的微小变化都会致使输出的彻底不一样
• 对称加密。加密和解密使用同一个秘钥，使用场合有通讯加密、cookie加密。经常使用算法有DES算法、RC算法
• 非对称加密。加密和解密使用的不是用一个秘钥，一个是公钥，一个是私钥。使用场合有信息安全传输、数字签名等场合。经常使用算法有RSA算法，https传输中浏览器使用的数字证书实质上就是非对称加密公钥。

9、10、十一皆为案例分析，此处略

12、秒杀系统架构设计

一、应对策略

• 秒杀系统独立部署
• 秒杀商品页面静态化
• 租借秒杀活动网络宽带

二、秒杀系统架构设计

控制秒杀按钮的点亮

十3、大型网站典型故障案例分析，内容略

十4、架构师领导艺术

一、关注人而不是产品

必定要坚信：一群优秀的人作一件他们热爱的事，必定能取得成功。

领导的真谛：寻找一个值得共同奋斗的目标，营造一个让你们都能最大限度发挥自我价值的工做氛围。

没有懒惰的员工，只有没被激发出来的激情。全部强迫员工加班的管理者都应该为本身的无能感到羞愧。

二、发掘人的优秀

是事情成就了人，而不是人成就了事。

发掘人的优秀比发掘优秀的人更有意义。

三、共享美好蓝图

架构师要和项目组全体成员共同描绘一个蓝图，这个蓝图是真个团队可以认同的，是团队共同奋斗的目标。这个蓝图应该是表述清楚的、形象的、简单的。

四、共同参与架构

不要只有架构师一人拥有架构，让其余人参与架构的设计和维护

五、学会妥协

不要企图在项目中证实本身是正确的，必定要记住，你是来作软件的，不是来作老大的。架构师越早被项目组遗忘，越表示架构很是成功；项目组越离不开架构师，越表示架构还有不少缺陷。

六、成就他人

想要成就本身，先要成就他人

十5、网站架构师职场攻略

一、发现问题，寻找突破

所谓问题，就是体验不能知足指望，就会以为出了问题。消除问题有两个方法：下降指望、改善体验

二、提出问题，寻求支持

• 把“个人问题”变成“咱们的问题”
• 给上司提封闭式问题，给下属提开放式问题
• 指出问题，而不是批评人
• 用赞同的方式提出问题

三、解决问题，达成绩效