大型网站技术架构笔记（5-6章）高可用网站的软件质量保证；网站的伸缩性架构

​第五章 万无一失：网站的高可用架构

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

        通常用多少个9来衡量网站可用性，qq是4个9qq服务99.99%可用，twitter 不足2个9

    5.2高可用的网站架构

        由于硬件故障是常态，那么网站高可用主要目的是保证硬件故障的情况下服务依旧可用，数据依然保存并能够被能够被访问主要手段就是数据和服务的冗余备份以及失效转移。

        一般网站架构都分为：

            应用层：处理业务逻辑； 

            服务层：提供可复用服务； 

            数据层：提供数据服务

        应用层为了应对高并发会通过集群，利用心跳检测剔除不用服务器，把请求转移到可用服务器。

        服务层和应用层类似。

        数据层写入时同步复制利用数据冗余。

    5.3高可用应用

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

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

            1.Session复制

            集群的所有服务器之间同步Session，适用小规模集群，大规模集群大量Session信息同步占去太多系统资源。

            2.Session绑定

            同一IP的用户请求发送到一台服务器上，这种方法也叫会话粘滞，但是这种Session管理不能很好支持网站高可用，某台绑定服务器意外宕机，Session丢失则将无法完成任务。

            3.利用Cookie记录Session

            4.Session服务器

            

 

 

    5.4高可用的服务

        1.分级管理

        服务器分级，核心业务优先使用更好的硬件；服务部署进行必要的隔离，避免连锁反应。

        2.超时设置

        在应用程序中设置服务调用超时，以便服务器宕机能及时转换到正常服务器

        3.异步调用

        应用对服务通过消息队列异步方式完成，避免一个服务失败导致整个请求失败；例如，新用户注册，可以将用户信息写入，发送注册邮件，开通权限分别到各自的消息队列，避免一个不成全部失败。当然也不是所有服务都可以用异步调用，对于获取用户信息则会延长响应所以不合适，需要立即确认的异步不合适。

        4.服务降级

        拒绝服务：拒绝低优先级或者随机拒绝，节约资源让一部分请求成功，避免导致所有都失败。

        关闭服务：关闭非核心业务，如淘宝双十一关闭确认收货以及退款服务

        5.幂等性设计

        必须在服务层保证重复调用不会影响结果，即服务具有幂等性。例如，设置性别为男，不管设置多少次都一样；转账则需要通过交易编号进行服务调用有效性校验。

    5.5高可用的数据

        数据是最有价值的

        5.5.1CAP原理

     C（Consistency）数据一致性；A（Availibility）数据可用性；P（Patition Tolerance）分区耐受性

        为了数据的高可用网站通常会舍弃另一个重要的标准：数据一致性

        高可用数据有如下几层的含义。

        数据持久性：既要持久性存储也要多副本存储

        数据可访问性：数据副本切换访问应很快完成

        数据一致性：

            数据强一致：副本数据在存储处总是一致，即操作响应更新失败，那么数据一定没有更新

            数据用户一致：副本存储处可能不一致，但是终端返回给用户时候通过校验和纠错保证返回到用户的是正确的

            数据最终一致：副本存储可能不一致，返回给用户的多次数据也不一致，通过短时间修复达到一致

        5.5.2数据备份

        冷备份：定时备份数据到存储介质

        廉价但是不能保证数据一致性以及数据不完整（从最近备份点到事故时间点之间的数据丢失）

        热备份：

        分为同步热备份：副本数据同步更新，应用程序收到失败响应那么可能会有部分副本已经成功的，不存在主从机。

        异步热备份：应用程序收到写成功响应时，只写成功一份，之后才会异步将其他副本进行数据同步但是这个过程可能会有数据或副本同步失败，存在主从机之分

        5.5.3失效转移

        数据服务一台服务器宕机，那么应用程序对这条服务器的所有操作都将重新路由到新的服务器，保证数据访问不会失败。

        过程包括：失效确认---访问转移---数据恢复

        1.失效确认

        心跳机制和应用程序访问失败报告

 

        2.访问转移

        重新路由到等同服务器，存储数据完全一样的称为等同服务器

        3.数据恢复

        将因宕机缺少的数据即使进行恢复

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

        5.6.1网站发布

 

        5.6.2自动化检测

        5.6.3预发布验证

            处理错误应该是快速失败原则，如果系统在启动时发现问题就立刻抛出异常，停止启动等待工程师解决 

        5.6.4代码控制   

            1.主干开发，分支发布

            2.分支开发，主干发布

        5.6.5自动化发布

        5.6.6灰度发布

    5.7网站运行监控

        不允许没有监控的系统上线

        5.7.1监控数据采集

        1.用户行为信息采集

            服务端日志收集

            客户浏览器日志收集

        2.服务性能收集

        3.运行数据收集

        5.7.2监控管理

            系统管理；失效转移；优雅自动降级

第六章 永无止境：网站的伸缩性架构

所谓网站伸缩性是指不需要改变网站的软硬设计，仅仅通过改变部署服务器数量就可以扩大或缩小网站的服务处理能力。

    6.1网站架构的伸缩性设计

    网站伸缩性可以分为两类，一类是根据功能进行物理分离；一类是单一功能根据集群实现伸缩，前者是不同服务器部署不同的服务，提供不同功能；后者是集群部署相同的服务，提供相同的功能。

        6.1.1不同功能实现物理分离

     

         纵向分离将不同业务模块分离部署

 

          横向分离力度可以很小，甚至可以一个关键页面部署一个独立服务

         6.1.2单一功能通过集群实现伸缩性

        随着访问量逐步增加，单个功能部署一台单独的服务器也是不能满足的，不得不多个服务器部署一个功能

        【一头牛拉不动车，不要首先找一头更强壮的牛，而是用两头牛】

    6.2应用服务器伸缩性设计

        负载均衡分为以下几种：

        6.2.1HTTP重定向负载均衡

 

        这种负载均衡方案优点是比较简单，缺点是浏览器需要两次请求服务器才能进行一次访问，性能差。

        6.2.2DNS域名解析负载均衡

        

 

        将负载均衡的工作交给了DNS，但是修改DNS记录生效时间较长，容易导致DNS域名解析到已经下线的服务器上。

       大型网站总使用DNS域名解析，利用域名解析作为第一级负载均衡手段，得动但是不是实际提供Web服务的服务器，然后在进行负载均衡，将请求发动到真正的服务器上。

        6.2.3反向代理负载均衡

 

        6.2.4IP负载均衡

 

 

        6.2.5数据链路层负载均衡

 

        三角传输模式的链路层负载均衡是目前大型网站使用最广的负载均衡手段。Linux平台最好的开源产品是LVS

        6.2.6负载均衡算法

        负载均衡服务器实现可以分为两部分：

            1.根据负载均衡算法和服务器列表的集群中其中一台服务器地址

            2.将请求数据发送到此地址服务器

        具体的负载均衡算法有:

            轮询：所有请求依次发送到每台应用服务器

            加权轮询：根据服务器性能，在轮询的基础上进行分发

            随机

            最少连接

           源地址散列：根据请求来源的的IP进行Hash值计算，得到应用服务器，这样一来相同IP的请求会在一台服务器进行处理

    6.3分布式缓存的伸缩性设计

        分布式缓存跟应用服务器缓存不太一样，不适合只用负载均衡就能解决的，应用用服务器上都是相同应用，而缓存服务器存储的是不同的数据，并且新上线的缓存服务器是没有数据的，下线的缓存服务器还有许多数据。这严重限制了分布式缓存的设计伸缩性。

         6.3.1Memcached分布式缓存集群的访问模型

 

        6.3.2Memcached分布式缓存伸缩性挑战 

        获取哪一台服务器，一般算法就是用服务器台数n除以存储数据key值的hash值的余数得到具体哪台服务器。

        但是问题是如果存储数据是三台服务器，假设3/hash值的余数为1，当读取缓存时服务器数量增加为4台，4/hash的余数就不一定是1啦，这就导致读取缓存失败就需要读取数据库，增加数量增加，失败率增加，数据库压力剧增。这是一一个问题。

        6.3.3分布式缓存一致性算法

        

 

 

        缓存数据key的hash值在hash环上顺时针寻找最近的node节点，这样即使添加新的节点也只会影响一小段。

 

       增加node3会影响node1的部分数据，但是node0和node2不受影响，那么四台服务器就会出现不是负载均衡的场景。

那么只需要将node节点用一组虚拟节点均匀分布进行代替，就能很大程度解决不均衡问题。

 

    6.4数据存储服务器的伸缩性设计

    数据存储服务器的集群相比缓存服务器集群有着更高的数据一致性和持久性

        6.4.1关系型数据库的伸缩性设计

         

【5-8章为本书核心，四章内容太多就分开记录啦】

长按关注，一起进步！