网站的高可用架构
网站的可用性Availability描述网站可有效访问的特性。
网站可用性度量
- 业界通常用多少个9来衡量网站的可用性
网站不可用时间(故障时间)=故障修复时间点-故障发现/报告时间点
网站年度可用性指标=(1-网站不可用时间/年度总时间)*100%
2个9,99%是基本可用,网站年度不可用时间小于88小时;
3个9,99.9%是较高可用,网站年度不可用时间小于9小时;
4个9,99.99%是具有自动恢复能力的高可用,网站年度不可用时间小于53分钟;
5个9,99.999%是极高可用性,网站年度不可用时间小于5分钟。
网站可用性考核
- 故障分=故障时间(分钟)*故障权重
网站故障分类权重表示例
分类 | 描述 | 权重 |
---|---|---|
事故级故障 | 严重故障,网站整体不可用 | 100 |
A类故障 | 网站访问不顺畅或核心功能不可用 | 20 |
B类故障 | 非核心功能不可用,或核心功能少数用户不可用 | 5 |
C类故障 | 其他故障 | 1 |
高可用的网站架构
- 主要目的:保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问
- 主要手段:数据和服务的冗余备份及失效转移
一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘读取数据 - 典型的网站设计-基础分层架构模型:三层,应用层、服务层、数据层,各层之间具有相对独立性
应用层主要负责具体业务逻辑处理
服务层主要提供可复用的服务
数据层负责数据的存储与访问 - 中小型网站在具体部署时,通常将应用层和服务层部署在一起,而数据层则另外部署
应用服务器(应用层&服务层)、数据库服务器(数据层) - 大型网站架构,不同业务产品会部署在各自独立的服务器集群上,互不相干;
这些产品会依赖一些共同的复用业务,如注册登陆服务、Session管理服务、账号管理服务等,这些可复用的业务服务也各自部署在独立的服务器集群上
位于服务层的服务器是被应用层通过分布式服务调用框架访问 - 网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机,还要考虑网站升级发布引起的宕机
应用层
- 应用层主要处理网站应用的业务逻辑,也可称作业务逻辑层
- 应用的一个显著特点是应用的无状态性
- 无状态应用:指应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行相应的业务逻辑处理,请求提交到任意服务器,处理结果都司完全一样的
- 通过负载均衡进行无状态服务的失效转移
- 负载均衡:将流量和数据分摊到一个集群组成的多台服务器上,以提高整体的负载处理能力
- 目前,不论是开源免费的负载均衡软件还是昂贵的负载均衡硬件,都提供失效转移功能
- 会话Session:web应用中多次请求修改使用的上下文对象
- 集群环境下,Session管理手段:Session复制、Session绑定、利用Cookie记录Session、Session服务器
服务层
- 可复用的服务模块为业务产品提供基础公共服务
- 大型网站中这些服务通常都独立分布式部署,被具体应用远程调用
- 可复用的服务和应用一样,也是无状态的服务,可以使用类似负载均衡的失效转移策略实现高可用的服务
- 高可用的服务策略:分级管理、超时设置、异步调用、服务降级(拒绝服务或关闭服务)、幂等性设计
- 服务降级:拒绝服务或关闭服务
- 幂等性设计:在服务层保证服务重复调用和调用一次产生的结果一样
数据层
- 保证数据存储高可用的手段主要是数据备份和失效转移机制
- 高可用数据的含义:数据持久性、数据可访问性、数据一致性
- CAP原理:一个提供数据服务的存储系统无法同时满足数据一致性Consistency、数据可用性Aailibility、分区耐受性Patition Tolerance(系统具有跨网络分区的伸缩性)这三个条件
- 数据备份:数据冷备、数据热备
- 数据热备:异步热备方式、同步热备方式
- 失效转移:若数据服务器集群中任何一台服务器宕机,那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器,保证数据访问不会失败
- 失效转移三步骤:失效确认、访问转移、数据恢复
高可用网站的软件质量保证
- 网站发布:发布过程中,每次关闭的服务器都是集群中的一小部分,并在发布完成后立即可以访问,因此整个发布过程不影响用户使用
- 自动化测试:对整个网站功能进行全面的回归测试,测试各种浏览器的兼容性
- web自动化测试技术:使用自动测试工具或脚本完成测试,比较流行的web自动化测试工具是Selenium
- Selenium:可以同时完成web功能测试和浏览器兼容测试
- 预发布验证:在网站发布时,把测试通过的代码包先发布到预发布机器上,开发工程师和测试工程师在预发布服务器上进行预发布验证,执行一些典型的业务流程,确认系统没有问题后才正式发布。
- 预发布服务器:它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上,外部用户无法访问
- 网站应用中一个处理错误的理念:快速失败fast failed,如果系统在启动时发现问题就立刻抛出异常,停止启动让工程师介入排查错误,而不是启动后执行错误的操作
- 代码控制:既能保证代码发布版本的稳定正确,同时又能保证不同团队的开发互不影响。
源代码版本控制工具:git - 自动化发布: 人的干预越少,自动化程度越高,引入故障的可能性就越小
- Jenkins是一个集构建、发布、部署为一体的综合性工具,DevOps中常提到的CI/CD(自动化构建、部署)
- 灰度发布:将集群服务器分成若干部分,每天只发布一部分服务器,观察运行稳定没有故障,第二天继续发布一部分服务器,持续几天才把整个集群全部发布完毕,期间如果发现问题,只需要回滚已发布的一部分服务器即可
灰度发布,也常用作AB测试
网站运行监控
- 网站项目上线评审:不允许没有监控的系统上线
- 监控数据采集:广义上的网站监控涵盖所有非直接业务行为的数据采集与管理
数据分析师和产品设计师使用的网站用户行为日志、业务运行数据
运维工程师和开发工程师使用的系统性能数据 - 用户行为日志收集:服务器端日志收集(开启web服务器的日志记录功能即可)、客户端浏览器日志收集(利用页面嵌入专门的javascript脚本收集用户真实的操作行为)
- 服务器性能监控:如系统Load、内存占用、磁盘IO、网络IO等对尽早做出故障预警,及时判断应用状况
目前网站使用比较广泛的开源性能监控工具是Ganglia,支持大规模服务器集群,并支持以图形的方式在浏览器展示实时性能曲线 - 运行数据报告:一些与具体业务场景相关的技术和业务指标,例如平均响应延迟时间、待处理的任务总数等
应用程序需要在代码中处理运行数据采集的逻辑 - 监控管理:网站监控数据作用:系统性能评估、集群规模伸缩性预测,根据实时监控数据进行风险预警,并对服务器进行失效转移,自动负载调整,最大化利用集群所有机器的资源
- 系统报警:监控管理系统可以配置报警阈值和值守人员的联系方式
- 失效转移:应用程序访问失败时进行失效转移,监控系统在发现故障的情况下主动通知应用,进行失效转移
- 自动优雅降级:应付突然爆发的访问高峰,主动关闭部分功能,释放部分系统资源,保证网站核心功能正常访问