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

四、网站的高性能架构

4.1.2 网站性能指标

1. 响应时间

3.吞吐量

TPS 每秒事务数

HPS 每秒HTTP请求数

QPS 每秒查询数

4.性能计数器

System load ：系统负载，指当前正在被CPU执行和等待被CPU执行的进程数目总和。

 

4.1.3 性能测试方法

性能测试是一个总称，具体分为性能测试、负载测试、压力测试、稳定性测试

4.1.4 性能测试报告

4.1.5 性能优化策略

分析影响性能的主要因素：内存、磁盘、网络、cpu、代码问题、架构设计不合理 或系统资源不足

性能优化分为：web前端优化、应用服务器性能优化、存储服务器性能优化

4.2 web前端优化

4.2.1 浏览器访问优化

1、减少http请求

合并css、js以及图片，如果图片有超链接，可用css偏移响应鼠标点击操作，构造不同的url

2、使用浏览器缓存

通过设置http头的 catch-control 和 expire的属性，可以设定浏览器缓存和缓存时间，如果需要更新，可以通过改名实现。

3、启用压缩

服务器端压缩，浏览器解压，文本压缩率可达80%，如果服务器通信良好，而资源不足的情况下权衡考虑。

4、css放在页面最上面，js放在页面最下面

先渲染后执行，如果页面渲染时要用到js适当调整

5、减少cookie的传输

4.2.2 CDN加速

CDN (Content Distribute Network 内容分发网络) 本质是一个缓存，且将数据缓存在离用户最近的地方，缓存内容一般是静态资源，如果图片、文件、css、js脚本和静态网页等；CDN部署在网络运营商的机房，这些运营商是终端用户的网络服务提供商

 

4.2.3 反向代理

传统代理服务器位于浏览器一侧，反向代理服务器位于网站机房一侧，代理网站web服务器接收http请求。

反向代理服务器具有保护网站安全的作用，也可配置缓存功能加速web请求，可以实现负载均衡的功能

4.3 应用服务器性能优化

优化手段：缓存、集群、异步等

4.3.1 分布式缓存

网站优化第一定律：优先考虑使用缓存优化性能

    1. 缓存的基本原理

        缓存卑职是一个内存hash表，网站应用中，数据缓存以一对Key、Value的形式存储在内存的hash表中。hash表的数据读写时间复杂度未O(1)

    2.合理使用缓存

        不恰当的使用缓存会成为系统的累赘：频繁修改的数据、没有热点的访问、

        数据不一致与脏读

        一般会对缓存设置失效时间，超时重新加载，因此应用要容忍一定时间的数据不一致。

        缓存可用性

        缓存雪崩：缓存服务崩溃，数据库因不能承受压力而宕机进而导致整个网站不可用。

        可通过缓存热备、分布式缓存服务器集群提供缓存可用性

        缓存预热

        缓存启动是把热点数据加载好

        缓存穿透

        缓存不在的数据(null),防止恶意攻击

    3. 分布式缓存架构

        分布式缓存架构方式有两种：一种是以jboss cache为代表的需要更新同步的分布式缓存，一种是以memcached为代表的不互相通信的分布式缓存

        Jboss cache 集群中所有服务器中保存相同的缓存数据，通常将应用程序和缓存部署在同一台服务器上

        memcached采用一种集中式缓存集群管理，缓存与应用分离部署，缓存服务器间互不通信

    4. Memcached

 

简单通信协议

Memcached使用Tcp协议通信，也支持UDP，其序列化协议则是一套基于文本的自定义协议。

高性能的网络通信

服务通信模块基于Libenent，一个支持事件触发的网络通信程序库

高效的内存管理

memcached使用了一个非常加单的办法-固定空间分配法。内存管理见下图：

存储数据时，根据数据大小，寻找一个大于size的最小chunk写入数据，避免的碎片问题，存在内存浪费。

互不通信的互联网集群架构

集群内服务互不通信使得集群几乎可以无限制的线性伸缩

4.3.2 异步操作

采用消息队列异步处理网站请求的数据库操作，提高网站系统的性能，同时很好的起到削峰的作用。

需要注意的是，由于数据写入消息队列后立即返回给用户，数据在后续的业务校验、写数据库等操作可能失败，因此在使用消息队列进行业务异步处理后，需要适当修改业务流程进行配合。

4.3.3　使用集群

4.3.4　代码优化

1.多线程

从资源利用的角度看，使用多线程的原因主要有两个：IO阻塞与多CPU。当前线程进行IO处理的时候，会被阻塞释放CPU以等待IO操作完成，由于IO操作(不管是磁盘IO还是网络IO)通常都需要较长的时间，这时CPU可以调度其他的线程进行处理。

启动线程数=[任务执行时间/(任务执行时间×IO等待时间)]×CPU内核数

解决线程安全的主要手段有如下几点：

1. 将对象设计为无状态对象
2. 使用局部对象
3. 并发访问资源时使用锁

2.资源复用

资源复用主要有两种模式：单例(Singleton)和对象池(Object Pool)

3.数据结构

 Hash表的读写性能在很大程度上依赖Hash Code的随机性，即Hash Code越随机散列，Hash表的冲突就越少，读写性能也就越高，目前Hash表的读写性能在很大程度上依赖Hash Code的随机性，即Hash Code越随机散列，Hash表的冲突就越少，读写性能也就越高

有可能相似字符串的Hash Code也比较接近，一个可行的方案是对字符串取信息指纹，再对信息指纹求Hash Code，由于字符串微小的变化就可以引起信息指纹的巨大不同，因此可以获得较好的随机散列

4.垃圾回收

    JVM为例，其内存主要可划分为堆(heap)和堆栈(stack)。堆栈用于存储线程上下文信息，堆则是存储对象的内存空间。JV M分代垃圾回收，其基本原理如图：

4.4　存储性能优化

4.4.1　机械硬盘vs. 固态硬盘

机械硬盘：目前最常用的一种硬盘，通过马达驱动磁头臂，带动磁头到指定的磁盘位置访问数据，由于每次访问数据都需要移动磁头臂

固态硬盘：又称作SSD或Flash硬盘，这种硬盘没有机械装置，数据存储在可持久记忆的硅晶体上，因此可以像内存一样快速随机访问。而且SSD具有更小的功耗和更少的磁盘震动与噪声

4.4.2　B+树vs. LSM树

 

4.4.3　RAID vs. HDFS

HDFS以块(Block)为单位管理文件内容，一个文件被分割成若干个Block，当应用程序写文件时，每写完一个Block， HDFS就将其自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台服务器宕机，数据依然可以访问，相当于实现了RAID 1的数据复制功能。

HDFS架构

在HDFS中有两种重要的服务器角色：NameNode(名字服务节点)和D ataNode(数据存储节点)。N ameNode在整个HDFS中只部署一个实例，提供元数据服务，相当于操作系统中的文件分配表(FAT)，管理文件名Block的分配，维护整个文件系统的目录树结构。DataNode则部署在HDFS集群中其他所有服务器上，提供真正的数据存储服务。

HDFS 数据库默认大小为64M

 

五、 万无一失：网站的高可用架构

网站的可用性(Availability)描述网站可有效访问的特性。

5.1　网站可用性的度量与考核

        网站的页面能完整呈现在最终用户面前，需要经过很多个环节，任何一个环节出了问题，都可能导致网站页面不可访问。DNS会被劫持、CDN服务可能会挂掉、网站服务器可能会宕机、网络交换机可能会失效、硬盘会损坏、网卡会松掉、甚至机房会停电、空调会失灵、程序会有B ug、黑客会攻击、促销会引来大量访问、第三方合作伙伴的服务会不可用……要保证一个网站永远完全可用几乎是一件不可能完成的使命。

5.1.1　网站可用性度量

        对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。

5.1.2　网站可用性考核

        可用性指标是网站架构设计的重要指标，对外是服务承诺，对内是考核指标。从管理层面，可用性指标是网站或者产品的整体考核指标，具体到每个工程师的考核，更多的是使用故障分。

5.2　高可用的网站架构

        高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。

        典型的分层模型是三层，即应用层、服务层、数据层；各层之间具有相对独立性；在复杂的大型网站架构中，划分的粒度会更小、更详细，结构更加复杂，服务器规模更加庞大，但通常还是能够把这些服务器划分到这三层中。

        不同的业务产品会部署在不同的服务器集群上，这些产品又会依赖一些共同的复用业务，这些可复用的业务服务也各自部署在独立的服务器集群上。

        位于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，使整个集群保持可用，从而实现应用高可用。

 

5.3　高可用的应用

5.3.1　通过负载均衡进行无状态服务的失效转移

在网站应用中，当集群中的服务是无状态对等时，负载均衡可以起到事实上高可用的作用。

5.3.2　应用服务器集群的Session管理

1. Session复制

        在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息，这样任何一台机器宕机都不会导致Session数据的丢失，而服务器使用Session时，也只需要在本机获取即可。

大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，不适用这种方案。

2. Session绑定

        Session绑定利用负载均衡的源地址实现，总是将来源于同一IP的请求分发到同一台服务器上。这种方法又被称作会话黏滞。一旦某台服务器宕机，那么该机器上的Session也就不复存在了，所以很少有网站利用这个算法进行Session管理。

很少有网站利用这个算法进行Session管理

3.利用Cookie记录Session

        早起的CS架构是将session保存在客户端，网站没有客户端可以利用浏览器支持的Cookie记录Session，缺点：受C ookie大小限制，能记录的信息有限；每次请求响应都需要传输C ookie，影响性能；如果用户关闭C ookie，访问就会不正常；优点：C ookie的简单易用，可用性高，支持应用服务器的线性伸缩

4. Session服务器

        利用独立部署的Session服务器(集群)统一管理S ession，应用服务器每次读写Session时，都访问Session服务器，

        这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。一种比较简单的实现方法是利用分布式缓存、数据库等。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录(SSO)、用户服务等功能，则需要开发专门的Session服务管理平台。

5.4　高可用的服务

1.分级管理

2.超时设置

3.异步调用

4.服务降级

5.幂等性设计

        服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性

5.5　高可用的数据

        保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。

5.5.1　CAP原理

高可用的数据有如下几个层面的含义：

数据持久性

数据可访问性

数据一致性

        CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Patition Tolerance，系统具有跨网络分区的伸缩性)这三个条件，

数据一致性又可分为如下几点：

数据强一致

数据用户一致

数据最终一致

5.5.2　数据备份

        数据热备可分为两种：异步热备方式和同步热备方式。

        在异步写入方式下，存储服务器分为主存储服务器(M aster)和从存储服务器(Slave)，应用程序正常情况下只连接主存储服务器。

          同步方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。

        关系数据库热备机制就是通常所说的M aster-S lave同步机制。M aster-S lave机制不但解决了数据备份问题，还改善了数据库系统的性能，实践中，通常使用读写分离的方法访问S lave和M aster数据库，写操作只访问M aster数据库，读操作只访问S lave数据库。

5.5.3　失效转移

        若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫作失效转移。失效转移操作由三部分组成：失效确认、访问转移、数据恢复。

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

        在网站运维实践中，除了网络、服务器等硬件故障导致的系统可用性风险外，还有来自软件系统本身的风险。

5.6.1　网站发布

        每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。

5.6.2　自动化测试

        代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但为了保证系统没有引入未预料的Bug，网站测试还是需要对整个网站功能进行全面的回归测试。

        目前大部分网站都采用Web自动化测试技术，使用自动测试工具或脚本完成测试。比较流行的Web自动化测试工具是ThoughtWorks开发的Selenium。Selenium运行在浏览器中，模拟用户操作进行测试。

5.6.3　预发布验证

         在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。

5.6.4　代码控制

        目前大部分网站使用的源代码版本控制工具是SVN， SVN代码控制和版本发布方式一般有以下两种：

1.主干开发、分支发布

2.分支开发，主干发布

        这两种方式各有优缺点。主干开发、分支发布方式，主干代码反应目前整个应用的状态，一目了然，便于管理和控制，也利于持续集成。分支开发，主干发布方式，各个分支独立进行，互不干扰，可以使不同发布周期的开发在同一应用中进行。

目前网站应用开发中主要使用的是分支开发、主干发布的方式，如图

        如果使用主干开发、分支发布，那么在同一个应用上，对于不同开发周期，不同发布时间的项目，有可能A项目发布的时候，B项目只开发了一半，这时候的主干代码是半成品，根本不能发布。

        目前在开源技术社区，Git作为版本控制工具，正逐步取代SVN的地位。G it对分布式开发，分支开发等有更好的支持，也更容易在各个开发分支上及时反映主干的最新更新，避免SVN在最后提交分支代码时发现和主干代码差别太大难以merge成功。

5.6.5　自动化发布

        火车发布模型：将每个应用的发布过程看作一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，剩下的项目继续坐着火车旅行，直到火车到达终点(应用发布成功)。

5.6.6　灰度发布

        将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。

5.7　网站运行监控

5.7.1　监控数据采集

        采集数据包括网站用户行为日志、业务运行数据，以及供运维工程师和开发工程师使用的系统性能数据等。

1.用户行为日志收集

具体用户行为日志收集手段有两种：服务器端日志收集、客户端浏览器日志收集。

2.服务器性能监控

        收集服务器性能指标，如系统Load、内存占用、磁盘IO、网络IO等对尽早做出故障预警，及时判断应用状况，防患于未然。

        目前网站使用比较广泛的开源性能监控工具是Ganglia

3.运行数据报告

5.7.2　监控管理

        根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。