程序的高可用相关知识

含义

系统高可用，或者说系统的可用性，在计算机领域是一个相当久远并且重要的概念。小到CPU芯片、内存、硬盘等硬件组件，大到支付宝、微信等日常互联网服务，在设计、开发、维护的时候，都离不开对它的考量。

• 可用性度量和考核
    所谓业务可用性(availability)也即系统正常运行时间的百分比，架构组最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于我们提供的服务（web，api）来说，更倾向用 N 个9 来量化可用性， 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。
  可用性的高低是使用不可用时间占总时间的比例来衡量。不可用时间是从故障发生到故障恢复的时间。比如，可用性 4 个 9 的系统（99.99%），它一年宕机时间不能超过53分钟。做到高可用系统，需要尽可能的降低故障发生的次数和减少故障持续的时间。

描述	可用性级别	年度停机时间
极高可用性	99.999%	5分钟
具有故障自动恢复能里的可用性	99.99%	53分钟
较高可用性	99.9%	8.8小时
基本可用性	99%	87.6小时

故障时间=故障修复时间点-故障发现（报告）时间点
服务年度可用时间%=（1-故障时间/年度时间）× 100%。
可用性KPI：以99.99%为例→53m=365*24*60*(1-0.9999)

• 服务可用性的级别划分
    如果是一个分布式架构设计，系统由很多微服务组成，所有的服务可用性不可能都是统一的标准。如果所有服务都实现高等级可用性的话，那么成本就会增加，所以要根据服务的重要程度来进行可用性级别区分。
    为了提高我们服务可用性，我们需要对服务进行分类管理并明确每个服务级别的可用性要求。

类别	可用性最低要求	描述
一级__核心服务	99.999%（全年5分钟不可用）	系统引擎部分：一旦出现故障，整个系统瘫痪
二级__重要服务	99.99%（全年53分钟不可用）	如外卖系统中的门店基础数据服务
三级__一般服务	99.9%（全年8.8小时不可用）	如外卖系统中的智能推荐
四级__工具服务	99%	非业务功能：比如后台管理系统、运维工具

ps:

平均无故障时间（MTTF）
MTTF（mean time to failure），指模块处在正常服务状态的平均时间。
平均修复时间（MTTR）
MTTR（mean time to repair），指模块处在服务中断状态的平均时间。

---

典型架构分层设计及各层实现高可用的原则

典型架构分层设计如下：按照功能处理顺序划分应用，这是面向业务深度的划分。架构分层图如下：

• 接入层：主要流量入口

• 应用层：直接对外提供产品功能，例如网站、API接口等。接入层不包含复杂的业务逻辑，只做呈现和转换。

• 服务层：根据业务领域每个子域单独一个服务。

• 数据层：数据库和NoSQL，文件存储、缓存等。

接入层高可用设计

接入层可能出现的问题：

• dns被劫持：域名是否使用https。
• 黑客攻击：是否有弱密，服务器权限，数据库权限
• ddos攻击：是否有必要使用高防IP接入流量。
• CC攻击：免费和收费版域名分开，网关是否有限流和防刷措施。

高可用设计方案:

1. 域名规范解析和规范化管理，应该制定《域名规范管理说明》，例如根据产品重要等级，制定使用高防ip的策略。
2. 规范API管理。
3. 明确各个API限流和防刷策略。

接入层高可用架构设计模式：

应用层高可用设计

接入层可能出现的问题：

• 应用服务器宕机。
• 应用服务bug。
• 第三方服务不可用。

应用层设计主要原则:

1. 可以水平扩展：通过接入层的负载均衡，实现故障自动转移。

2. 无状态设计：无状态的系统更利于水平扩展，更利于做负载均衡。

   状态是系统的吞吐量、易用性、可用性、性能和可扩展性的大敌，要尽最大可能避免。

3. 回滚设计 ：确保系统可以向后兼容，如果应用服务上线后出现bug，可以紧急回滚。

4. 灰度发布：结合接入层设计A/B 功能，实现灰度发布，比如按ip，请求参数等分发流量。

服务层高可用设计

服务层可能出现的问题：

• 服务不可