大型网站技术架构02 网站的高性能架构、网站的可用性架构

大型网站核心架构要素

1. 性能

2. 可用性

3. 伸缩性

4. 扩展性

5. 安全性

 

瞬时响应：网站的高性能架构

1. 网站性能测试：

    1). 不一样视角下的网站性能

         a. 用户视角的网站性能：用户计算机，网站服务器通讯时间，网站服务器处理时间，用户浏览器解析时间等。

         b. 开发人员视角的网站性能：

         c. 运维人员视角的网站性能：优化主干网，利用虚拟化技术优化资源利用等

    2). 性能测试指标

          a. 响应时间：单个请求时间很差计算，能够经过重复执行一万次，测试一万次执行须要的总响应时间之和，而后除以一万，获得单次请求的响应时间。

          b. 并发数：指系统同时处理请求的数目，这个数字也反映了系统的负载特性。测试程序经过多线程模拟并发用户的办法来测试系统的并发能力，为了模拟真实用户行为，测试程序并非启动多线程而后不停

                         地发送请求，而是在两次之间加入一个随机等待时间，这个时间被称为思考时间。

          c. 吞吐量：单位时间内系统处理的请求数量，体现系统的总体处理能力。

          d. 性能计数器：描述服务器或操做系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络IO等指标。这些指标也是系统监控的重要参数，对这些指标设置报警阈值，

                               当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常。

    3). 性能测试方法：

         a. 性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到系能逾期。

         b. 负载测试：对系统不断地增长并发请求以增长系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提升，反而降低。

         c. 压力测试：超过安全负载的状况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此得到系统最大压力承受能力。

         e. 稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统加载必定业务压力，是系统运行一段较长时间，以此检测系统是否稳定。稳定性测试硬不均匀地对系统施加压力。

         f. 经过测试得出：网站平常运行区间，系统的最大负载点，系统的崩溃点

    4). 性能测试报告：应包括：并发数，响应时间，TPS(每秒事务数)，错误率(%)，Load，内存(GB)，备注

    5). 性能优化策略

         a. 性能分析：检查请求处理的各个环节的日志，分析哪一个环节响应时间不合理、超过预期；而后检查监控数据，分析影响能力的主要因素是内存、磁盘、网络、仍是CPU，是代码问题仍是架构设计不合理，或

                           系统资源不足。

         b. 性能优化

2. Web前端性能优化

    1). 浏览器访问优化：

         a. 减小http请求：合并CSS，合并JS将浏览器须要的JS，CSS合并成一个文件。图片由多张合成一张。

         b. 使用浏览器缓存：缓存静态资源。在某些时候，静态资源变换须要及时应用到客户端浏览器，能够经过修改文件名实现。静态资源多的时候，考虑逐量更新。

         c. 启用压缩

         d. CSS放在页面最上面、JavaScript放在页面最下面：若是页面解析时就须要用到JS，这时放在底部就不合适了。

         e. 减小Cookie传输

    2). CDN加速：即内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求老是先到达他的网络服务器商那里，在这里缓存网站的一些静态资源(较少变化的数据)。能够就近以最快的速度返回给用户，

                        如视频网站和门户网站会将用户访问量最大的热点内容缓存在CDN。

    3). 反向代理：反向带来属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最早访问到的就是反向代理服务器，这里缓存网站的静态资源。无需将请求继续转发给应用服务器就能

                       返回给用户。来自互联网的请求必须通过代理服务器，至关于在Web服务器和可能的网络攻击之间创建了一个屏障，起到保护做用。

3. 应用服务器性能优化：

    1). 分布式缓存：网站性能优化的第必定律：优先考虑使用缓存优化性能。

         a. 缓存的基本原理：缓存指将数据存储在相对较高访问速度的存储介质中，以供系统处理。一方面缓存访问速度快，能够减小数据访问时间，另外一方面若是缓存的数据是通过计算处理获得的，那么被缓存的数据

                                     无需重复计算便可直接使用，所以缓存还起到减小计算时间的做用。

                                     缓存的本质是一个内存Hash表，网站数据访问一般遵循二八定律。

         b. 合理使用缓存：频繁修改的数据(不适合)，没有热点的访问(不适合)，数据不一致与脏读(注意)，缓存可用性(缓存崩溃后，数据库直面访问可否承受)，缓存预热(提早将缓存数据加载出来)，

                                  缓存穿透(一个简单的对应策略是敬爱给你不存在的数据也缓存起来(其值为null))

                                  通常来讲，数据的读写比在2:1以上，即写入一次缓存，在数据更新前至少读取两次，缓存在有意义

         c. 分布式缓存架构：一种是以JBoss Cache为表明的须要更新同步的分布式缓存，一种是以Memcached为表明的不互相通讯的分布式缓存。

         d. memcached : 简单的通讯协议，丰富的客户端程序，高性能的网络通讯，高效的内存管理，互不通讯的服务器集群架构

    2). 异步操做：使用消息队列将调用异步化，可改善网站的扩展性。事实上使用消息队列还可改善网站系统的性能。消息队列具备很好的削峰做用。

                       注意，因为数据写入消息队列后马上返回给用户，数据在后续的业务校验、写数据库等操做可能失败，所以在使用消息队列进行业务异步处理后，须要适当修改业务流程进行配合。如订单提交后，订单

                       数据写入消息队列，不能当即返回用户订单提交成功。须要在消息队列的订单消费者进程真正处理完该订单，甚至商品出库后，再经过电子邮件或SMS消息通知用户订单成功，以避免交易纠纷。

                       任何能够晚点作的事情都应该晚点再作。

    3). 使用集群

    4). 代码优化：

         a. 多线程：从资源利用的角度角度看，使用多线程的缘由主要有两个：IO阻塞与多CPU。启用线程数 = [任务执行时间/(任务执行时间-IO等待时间)]*CPU内核数

                        解决线程安全主要手段有以下几点：将对象设计成无状态对象，使用局部变量，并发访问资源时使用锁。

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

         c. 数据结构：hash等

         d. 垃圾回收

4. 存储性能优化：

    1). 机械硬盘  VS  固态硬盘

    2). B+树  VS LSM树

    3). RAID  VS HDFS

         a. RAID(廉价磁盘冗余阵列)技术主要是为了改善磁盘的访问延迟，加强磁盘的可用性和容错能力。目前服务器级别的计算机都支持插入多块磁盘(8块或者更多)，经过使用RAID技术，实现数据在多块磁盘上的

             并发读写和数据备份。

             RAID0：根据磁盘数量将数据分红N分，同时并发写入N块磁盘，使得数据总体写入速度是一块磁盘的N倍。读取时也同样，但只要有一块损坏，数据完整性就被破坏。

             RAID1：数据在写入磁盘时，将一份数据同时写入两块磁盘，这样任何一块磁盘损坏都不会致使数据丢失，插入一块新磁盘就能够经过复制的方式自动修复，具备极高的可靠性。

             RAID10：结合RAID0和RAID1两种方案，将全部磁盘平均分红两份，数据同时在两份磁盘写入，至关于RAID1，可是在每一份磁盘里面的N/2块磁盘上，利用RAID0技术并发访问。既提升可靠性又改善性能，

                           不过RAID10磁盘复用率较低。

             RAID3：分N块，数据写入N-1块，校验数据写入到第N块。

             RAID5：相似RAID3但校验数据螺旋式地写入全部磁盘中。避免磁盘频繁修改被写坏。

             RAID6：数据写入N-2块，并螺旋式地在两块磁盘中写入校验信息。

         b. 在HDFS(Hadoop 分布式文件系统)中，系统在整个存储集群的多台服务器上进行数据并发读写和备份，能够看做在服务器集群规模上实现相似RAID的功能，所以不须要磁盘RAID。

             HDFS以块(Block)为单位管理文件内容，一个文件被分割成若干个Block，当应用程序写文件时，每写完一个Block，HDFS就将其复制到另外两台机器上，保证每一个Block有三个副本，及时有两台服务器宕机，数据

             依然能够被访问，至关于RAID1的数据复制功能。

             对文件进行处理计算时，经过MapReduce并发计算任务框架，能够启动多个计算子任务，同时读取文件的多个Block，并发处理，至关于实现RAID0的并发访问。

5. 网站性能对用户而言是一种主观感觉，性能优化的最终目的是改善用户的体验，是他们感受网站很快。离开这个目的，追求技术上的所谓高性能，是舍本逐末，

    没有多大意义。而用户体验的快或慢，能够经过技术手段改善，也能够经过优化交互体验改善。

 

万无一失：网站的可用性架构

1. 网站可用性的度量与考核：

    1). 网站可用性度量：网站不可用也被称做网站故障，业界一般用多少个9来衡量网站的可用性。

    2). 网站可用性考核：

2. 高可用的网站架构：网站高可用性架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并可以被访问。实现高可用性的主要手段是数据和服务的冗余备份以及失效转移。磁盘损坏，则从备份的磁盘读取数据。

3. 高可用的应用：

    1). 经过负载均衡进行无状态服务的失效转移：对于应用服务器集群，实现这种服务可用状态实时监测、自动转移失败任务的机制是负载均衡。负载均衡服务器经过心跳监测机制判断服务器是否可用。

    2). 应用服务器集群的Session管理：集群环境下，Session管理主要有如下几种手段：

         a. Session复制：大型网站不适合

         b. Session绑定：能够利用负载均衡在源地址Hash算法实现，负载均衡服务器老是未来源于同一IP的请求分发到同一台服务器上。但这种方式不符合对系统高可用性的要求，由于一旦服务器宕机，Session就不存在了。不多被采用。

         c. 利用Cookie记录Session：将Session记录在客户端，每次请求服务器的时候，经Session放在请求中发送给服务器，服务器处理完请求后再修改Session响应客户端。缺点：受cookie大小限制，影响性能，若浏览器关闭cookie，

            没法使用等。

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

             这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，而后针对这两种服务器的不一样特性分别设计其架构。

             对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合Session的存储和访问要求。若是业务场景对Session管理有比较高的要求，好比利用Session服务集成

             单点登陆(SSO)、用户服务等功能，则须要开发专门的Session服务管理平台。

4. 高可用的服务：可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务一般都独立分布式部署，被具体应用远程调用。可复用的服务和应用同样，也是无状态的服务，所以可使用相似负载均衡的失效转义策略实现

    高可用服务。除此以外，具体实践中，还有如下几点高可用的服务策略：

    1). 分级管理：运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。同时在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务经过启动不一样的线程或者部署在不一样的

         虚拟机上，核心服务和数据甚至要部署在不一样的地址数据中心。

    2). 超时设置：因为服务宕机、线程死锁等缘由，可能致使应用程序对服务端的调用失去响应，进而致使用户请求长时间得不到响应，同时还占用应用程序资源，不利于及时将请求转移到正常的服务器上。

         在应用程序中设置服务调用超时时间，一旦超时，通讯框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或者将请求转移到提供相同服务的其余服务器上。

    3). 异步调用：应用对服务的调用经过消息队列等异步方式完成。固然并非全部服务调用均可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务器调用成功才能进行下一步

         的操做也不适合异步调用。

    4). 服务降级：在网站访问高峰期，为了保证核心应用和功能的正常运行，须要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。

         拒绝服务：拒绝低优先级应用的调用，减小服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节省资源，让另外一部分请求得以成功，避免要死你们一块儿死的惨剧。

         关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节省系统开销，为重要的服务和功能让出资源。

    5). 幂等性设计：保证服务重复调用的和调用一次产生的结果相同，即服务具备幂等性。

5. 高可用的数据：保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本，任意副本的失效都不会致使数据的永久丢失，从而实现数据彻底的持久化。而失效转移机制则保证当前一个数据副本不可

    访问时，能够快速切换访问数据的其余副本，保证系统可用。

    缓存服务的高可用性：扩大缓存服务器集群规模的一个简单手段就是整个网站共享一个分布式缓存集群，单独的应用和产品再也不部署本身的缓存服务器，只须要向共享缓存集群申请资源便可。

    1). CAP原理：CAP原理认为，一个提供数据服务的存储系统没法同时知足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Partition Tolerance，系统具备跨网络分区的伸缩性)这三个条件。

         高可用的数据有以下几层含义：数据持久性，数据可访问性，数据一致性

         大型网站中，一般会选择强化分布式存储系统的可用性(A)和伸缩性(P)，而在某种程度上放弃一致性。具体来讲，数据一致性有分为以下几点：

         数据强一致：各个副本的数据在物理存储中老是一致的

         数据用户一致：各个副本可能不一致，但返回给用户的经过纠错机制等，返回给用户一个正确的数据。

         数据最终一致：通过一段时间之后，数据最终会达到一致

    2). 数据备份：

         冷备份：优势是简单和廉价，成本和技术难度都比较低。缺点是不能保证数据最终一致性。同时因为数据落后，也不能保证数据可用性。

         热备份：异步热备份和同步热备份

         a. 异步热备份：指多份数据副本的写入操做异步完成，即应用程序收到数据服系统的写操做成功响应时，只写成功一份，存储系统会异步地写入其余副本。

         b. 同步热备份：指多份数据副本的写入操做同步完成，即应用程序收到数据服务系统写入成功响应时，多份数据都已经写操做成功。

    3). 失效转移：

         a. 失效确认：两种方式，心跳检测和应用程序访问失败报告。对于应用程序的访问失败报告，控制中心还须要在一次发送心跳检测进行确认。

         b. 访问转移：确认某台存储服务器宕机后，须要将数据读写访问从新路由到其余服务器上。

         c. 数据恢复：必须将副本的数目恢复到系统设定值，防止再有服务器宕机。从健康的服务器复制数据，将数据副本数目恢复到设定值。

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

    1). 网站发布：一般经过发布脚本来完成发布。发布过程当中，每次关闭的服务器都是集群中的一小部分，并在发布完成后当即能够访问，所以整个发布过程不影响用户使用。

    2). 自动化测试：自动化测试工具能够一键完成系统部署，测试数据生成、测试执行、测试报告生成等所有测试过程 

    3). 预发布验证：沙箱测试，与真实线上环境尽可能保持一致。

    4). 代码控制：

          a. 主干开发，分支发布：代码修改都在主干上进行，须要发布的时候，从主干拉一个分支发布，该分支即成为一个发布版本，若是该版本有bug，继续在分支上修改发布，将修改合并(merge)回主干，直到下次主干发布。

          b. 分支开发，主干发布：任何修改都不能在主干上直接运行，须要开发一份新功能或者修复一个bug时，从主干拉一份分支进行开发，开发完成且经过测试后，合并回主干，而后从主干进行发布，主干上的代码永远是最新

                                          发布的版本。

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

          在同一应用中进行。

    5). 自动化发布：人干预越少，自动化程度越高，引入故障的可能性就越小，火车准点到达，你们按时下班的可能性就越大。

    6). 灰度发布：应用发布成功后，仍然可能会发现由于软件问题而引入的故障，这时候就须要作发布回滚，即卸载刚刚发布的软件，将上一个版本恢复。为应对这种局面，大型网站会使用灰度发布模式，将集群服务器分若干部分，

          天天只发布一部分。

          灰度发布，也经常使用于用户测试，即在部分服务器上发布新版本，而后监控用户操做行为，收集用户体验报告。比较用户对两种版本的满意度，以肯定最终发布的版本。这种手段称为AB测试。

7. 网站运行监控：不容许没有监控的系统上线。

    1). 监控数据采集

         a. 用户行为日志收集：用户行为日志指用户在浏览器上所作的全部操做以及所在的操做系统环境，包括：用户操做系统与浏览器版本，IP地址、页面访问路径、页面停留时间等。这些数据对统计网站的PV/UV指标、分析用户行为、

             优化网站设计、个性化营销与推荐等很是重要。

             用户行为日志收集手段有两种：

             a1. 服务器端日志收集

             a2. 客户端浏览器日志收集：利用页面嵌入JS脚本收集用户真实的操做行为，所以比服务器日志收集更加准确。缺点是比较麻烦。

             此外，大型网站的用户日志数量惊人，数据存储和计算压力大，目前许多网络逐步开发基于实时计算框架Storm的日志统计与分析工具。

         b. 服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO、网络IO等尽早做出故障预警，及时判断应用情况，防患于未然，将故障扼杀在萌芽时期很是重要。

             目前网站使用比较普遍的开源性能监控工具是Ganglia，它支持大规模服务器集群，并支持以图形的方式在浏览器展现实时性能曲线。

         c. 运行数据报告：网站还须要监控一些与具体业务场景相关的技术与业务指标，好比缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。

    2). 监控管理：监控数据采集后，除了用做系统性能评估、集群规模伸缩性预测等，还能够根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群全部机器的资源。

          a. 系统报警：监控管理系统能够配置报警阈值和制售人员的联系方式，报警方式除了邮件，即时通讯工具，还能够配置手机短信，语音报警，系统报警时，工程师即便在千里以外，夜里睡觉也能被及时通知，迅速响应。

          b. 失效转移：除了应用程序访问失败时进行失效转移，监控系统还能够在发现故障的状况下主动通知应用，进行失效转移

          c. 自动优雅降级：优雅降级是指网站为了应付忽然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问的一个手段。