C++ 全栈知识体系

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

https://www.cnblogs.com/edisonchou/p/3773828.html

网站可用性的度量与考核

首先，不得不说：要保证一个网站永远完全可用几乎是一件不可能完成的任务（Mission Impossible，是不是有点碟中谍的感觉）。

如何度量网站可用性？

一个神奇的数字—9！你有几个9，就代表了你的可用性。例如QQ可用性达到了4个9：99.99%

  1. 2个9=基本可用
  2. 3个9=较高可用
  3. 4个9=具有自动恢复能力的高可用
  4. 5个9=极高可用->理想状态

那么，可用性的9又是怎么计算出来的呢?

网站不可用时间=故障修复时间点-故障发现时间点

网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%

如何考核网站可用性？

广泛采用故障分的，它是对网站故障进行分类加权计算故障责任的方法。一般会给每个分类的故障设置一个权重（例如，事故级故障权重为100，A类为20等）

其计算公式为：故障分=故障时间（分钟）*故障权重。

公司对技术团队的考核一般会参考故障分，例如，某团队今年发生了几个事故级故障，那么其绩效考核估计受到很大影响，年终奖什么的就悲剧了。😭

高可用的架构

目前，通常企业级应用系统（特别是政府部门和大企业的应用系统）一般会采用安规的软硬件设备，如IOE（IBM的小型机、Oracle数据、EMC存储设备）系列。而一般互联网公司更多地采用PC级服务器（x86），开源的数据库（MySQL）和操作系统（Linux）组建廉价且高容错（硬件故障是常态）的应用集群。

设计的目的 　　* 保证服务器硬件故障服务依然可用，数据依然保存并能够被访问。

主要的手段 　　* 数据和服务的冗余备份以及失效转移：

对于服务而言，一旦某个服务器宕机，就将服务切换到其他可用的服务器上；

对于数据而言，如果某个磁盘损坏，就从备份的磁盘（事先就做好了数据的同步复制）读取数据。

高可用的应用

应用层处理网站应用的业务逻辑，应用的一个最显著的特点是：应用的无状态性。

无状态特性: 指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

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

不保存状态的应用给高可用架构设计带来便利，对应故障的机器，可以利用负载均衡将对应请求转移到其他服务器上。

应用服务器集群的Session管理

Web应用中将这些多次请求修改的上下文对象称为会话（Session），单机情况下由部署在服务器上得Web容器（如IIS、Tomcat、JBoss等）管理。在使用了负载均衡的集群环境中，由于请求的分发是随机的，所以保证每次请求依然能够获得正确的Session比单机时要复杂得多。

在集群环境中，Session管理的几种常见手段。

  1. Session复制：该方案简单易行，集群中的几台服务器之间同步Session对象，任何一台服务器宕机都不会导致Session对象的丢失，服务器也只需要从本机获取即可。但是，该方案只适合集群规模较小的情况下。当规模较大时，大量的Session复制操作会占用服务器和网络的大量资源，系统不堪重负。

  2. Session绑定：利用负载均衡的源地址Hash算法，总是将源于同一IP地址的请求分发到同一台服务器上。这样的话，在整个会话期间，用户所有的请求都在同一台服务器上进行处理，即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。（这种方案又叫做会话粘滞）。

但是，这种方案不符合高可用的需求。因为一旦某台服务器宕机，那么该机器上得Session也就不复存在了，用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此，很少有网站采用此方案进行Session管理。

  1. 利用Cookie记录Session：利用浏览器支持的Cookie记录Session简单易行，可用性高，并且支持服务器的线性伸缩，因此，许多网站都或多或少地使用了Cookie来记录Session。但是Cookie记录Session有缺点：比如受Cookie大小限制、每次请求响应都要传输Cookie影响性能、用户关闭了Cookie会造成访问不正常等。

  2. Session服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。这种方案实际上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。

对于有状态的Session服务器，一种较简单的方法是利用分布式缓存（如Memcached、Redis）、数据库等，在这些产品的基础上进行封装，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的Session服务管理平台。

扩展: 单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。

单点登录的三种实现方式

  1. session广播机制

实现方式：用户在某个模块登录后，用户信息存在这个模块session中，然后在其他模块进行session复制

缺点：虽然可以实现SSO，但是假如项目有几十个模块，就要复制几十次session，极大的消耗资源资源。

  1. 用cookie + redis实现

  • cookie特点：是一种客户端技术，每次发送请求，带着cookie值进行发送

  • redis特点：基于key-value进行存储

实现方式：在项目中任何一个模块进行登录，登录之后，把数据放到两个地方：

  1. redis：在key：生成唯一随机值，在value：存放用户数据

  2. cookie：把redis里面生成的key值放到cookie里面

​访问项目中访问其他模块时，发送请求带着cookie进行发送，获取cookie值，到redis根据key进行查询，如果查询到数据就是 登录，查不到就没有登录。

  1. 使用token实现

token是什么：按照一定规则生成的字符串，字符串可以包含用户信息

实现方式：在项目某个模块进行登录，登录之后，按照规则生成字符串，把登录之后用户信息包含到生成的字符串里面，把字符串通过地址栏返回;把字符串通过cookie返回，再去访问其他模块时，在地址栏带着生成的字符串，在访问模块里面获取地址栏字符串，根据字符串获取用户信息，如果可以获取到就是登录。

高可用的服务

高可用的服务模块为业务产品提供基础公共服务，在大型站点中这些服务通常都独立分布式部署，被具体应用远程调用。

高可用的服务策略如下：

  1. 分级管理：核心应用和服务具有更高的优先级，比如用户及时付款比能否评价商品更重要；

  2. 超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试or请求转移到其他服务器上；

  3. 异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

  4. 服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。

降级有两种手段：一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；

  1. 幂等性设计：保证服务重复调用和调用一次产生的结果相同；（服务重复调用时无法避免的）

高可用的数据

对于大多数网站而言，数据是其最宝贵的物质资产。

CAP理论见 方法论

保证数据高可用的主要手段有两种：一是数据备份，二是失效转移机制；

  1. 数据备份：又分为冷备份和热备份，冷备份是定期复制，不能保证数据可用性。热备份又分为异步热备和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成。

  1. 失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都要重新路由到其他服务器，保证数据访问不会失败。

失效转移操作有三部分组成：失效确认、访问转移、数据恢复。

  1. 失效确认
    • 心跳检测和应用程序访问失败报告
  2. 访问转移
    • 通过路由机制，选择新的存储服务器
  3. 数据恢复
    • 恢复数据存储的副本数量，且数据进行复制

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

  1. 网站发布：在柔性的发布过程中，每次关闭的服务都是集群中的一小部分，并在发布完成后立即可以访问；

  1. 自动化测试：使用自动测试工具或脚本完成测试；

  2. 预发布验证：引入预发布服务器，与正式服务器几乎一致，只是没有配置在负载均衡服务器上，外部用户无法访问；

    • 网站工程师通过在自己的开发用计算机上配置hosts文件绑定域名IP关系直接使用IP地址访问预发布服务器

  1. 代码控制：目前广泛采用Git作为版本控制工具，存在两种发布策略

    • 主干开发、分支发布 ———— 实际上，主干可能会存在新的需求要合入，分支是针对特定商用场景拉出，已经具备相应的功能，只需要合入故障内容，新特性需求则不需要在分支进行合入。即永远保证主干分支内容是最全的，如果分支需要则进行反合，这个策略主要保证外发分支内容是可用的。
    • 分支开发、主干发布 ———— 其实也合理，分支开发不影响主干的功能，等分支上验证通过后，再反向合入主干，这个策略主要保证主干是可用的。

  2. 自动化发布

    • 一般选择在周四进行发布，这样一周前面有三天时间可用准备发布，后面有一天时间可用挽回错误。如果选择周五发布，那必须得是996了。:😓:

  3. 灰度发布

应用发布成功后，仍然可能发现因为软件问题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，使系统复原，消除故障。

PS: 大型公司正常软件升级，都会选择在凌晨，用户接入量少的时候，即使升级失败，也能通过快速回退，将影响降到最低。

同时，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕。

灰度发布也常用于用户测试，即在部分服务器上发布新版本，其余服务器上维持老版本，然后监控用户操作行为,收集用户体验报告，比较用户对两个版本的满意度，以确定最终发布的版本。这种手段也被称作AB测试。

补充知识：

A/B测试的作用

  • 消除客户体验（UX）设计中不同意见的纷争，根据实际效果确定最佳方案；
  • 通过对比试验，找到问题的真正原因，提高产品设计和运营水平；
  • 建立数据驱动、持续不断优化的闭环过程；
  • 通过A/B测试，降低新产品或新特性的发布风险，为产品创新提供保障。

A/B测试与一般工程测试的区别

A/B测试，用于验证用户体验、市场推广等是否正确，而一般的工程测试主要用于验证软硬件是否符合设计预期，因此AB测试与一般的工程测试分属于不同的领域。

网站运行监控

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

监控数据采集

  1. 用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具；
  2. 服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然；
  3. 运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；

监控管理

  1. 系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；
  2. 失效转移：监控系统在发现故障时，主动通知应用进行失效转移；
  3. 自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行；—>网站柔性架构的理想状态

文章来源

  • 作者：李智慧
  • 来源：《大型网站技术架构》

← 第6章：永无止境：网站的伸缩性架构 →