高可用网站架构-万无一失

高可用-万无一失

廉价的服务器硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够访问。
实现上述高可用方案的主要数据和服务的手段是冗余备份和失效转移。


应用层：应对高并发，负载均衡，心跳检测监控，不可用时候剔除。
服务层：通过集群方式实现高可用，被应用层通过分布式调用框架访问，分布式调用框架会在客户端程序中实现软件负载均衡、心跳检测。
数据层：同步复制，冗余备份。

高可用的应用

健身房小姐姐填表单的栗子。
无状态性！！！


可以直接通过负载均衡实现无状态服务的负载均衡。


应用服务器集群的 Session 管理
事实上，业务总是有状态的，在交易类的电商网站需要有购物车记录的购买信息，用户每次购买请求都是向购物车中增加商品；在社交类网站中，需要记录用户的当前登录状态、最新发布的消息和好友列表等，每次刷新页面都需要更新这些信息。

1. Session 复制

应用服务器开启 Web 容器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，每台服务器保存所有用户的 Session 信息。
当集群规模较大时候，大量的 Session 复制通信占用服务器的网络资源较大，甚至有内存不够存 Session 情况。

2. Session 绑定

Session 绑定可以利用负载均衡的源地址 Hash 算法实现，总是将同一个 IP 的请求分发到同一台服务器上，也可以根据 Cookie 信息将同一个用户的请求分发到同一台服务器上。这个负载均衡服务器必须工作在 HTTP 协议层上。这样就能保证这个用户的请求都在同一台服务器上，这种方法又被成为会话粘滞。
但是 Session 绑定的方案不符合高可用程序，某台服务器宕机后一些依赖此服务器的用户的服务就不可用了。

3. 利用 Cookie 记录 Session
   1. Cookie 大小限制，记录信息有限
   2. 每次响应都要传输 Cookie，影响性能
   3. 如果用户关闭 Cookie 功能，访问就会不正常
4. Session 分离

独立的 Session 服务器或者集群，基础服务平台。

高可用的服务

可复用的服务和应用一样，也是无状态的服务，此可以使用类似负载均衡的失效转移策略实现高可用服务。

1. 分级管理
   1. 核心应用和服务优先使用更好的硬件，运维响应时间也要迅速
2. 超时设置
   1. 超时后继续重试或者将请求失效转移到提供相同服务的其他服务器上
3. 异步调用
   1. 消息队列等异步调用的方式
4. 服务降级
   1. 拒绝服务？关闭服务？
   2. 拒绝服务：拒绝优先级低的应用调用，减少服务器的并发数，保证核心功能正常调用；或者随机拒绝部分请求调用，节约资源。
   3. 关闭服务：关闭不中哟的部分服务，或者服务内部关闭部分不重要的功能。
5. 幂等性设计
   1. 服务重复调用是无法避免的，应用层也不需要关心服务是否真的失效，只要没有得到调用成功的响应，就可以认为调用失效，并充实服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

高可用的数据

数据备份和失效转移机制。


为了保证数据的高可用，网站通常会牺牲另一个很重要的指标：数据一致性。
**
CAP 原理
数据持久性
数据可访问性
数据一致性

1. 数据强一致
2. 数据用户一致
3. 数据最终一致

数据备份

异步热备份、同步热备份

失效确认

访问转移

转移到存储的数据完全一样的服务器上（对等服务器）
如果服务不对等，就需要重新计算路由，选择存储服务器。

数据恢复

。。。

软件质量保证

网站发布

飞行中给飞机换个引擎。

自动化测试

全面的回归测试。

预发布验证

预发布机器。

代码控制

主干发布，分支开发。
主干开发，分支发布。
~~

自动化发布

灰度发布

第一天发布 0999 服务器，遇到故障回滚。
第二天发布 10001999 服务器，遇到故障回滚。
。。。

网站运行监控

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

监控数据采集

1. 用户行为日志收集
   1. 服务端日志手机
   2. 客户端浏览器日志收集
2. 服务器性能监控
3. 运行数据报告

监控管理

1. 系统报警
2. 失效转移
3. 自动优雅降级

EOF！

赏

谢谢你请我吃糖果

支付宝

微信