# 高可用架构的探索与实现 (opens new window)
现代的企业面临着一个VUCA (opens new window)时代，高可用系统架构面对着诸多不确定性带来的影响和挑战。
# 高可用架构的挑战
- 应用程序的异常退出
- 操作系统的突然宕机
- 服务器的意外断电
- 运维人员人为操作失误
- 地震等不可抵抗因素
- 业务量的突然增大
- 高可用架构的复杂性
# 目标&指标
衡量高可用性也有很多指标比如MTTF/MTTR/RPO/RTO，根据MTTR和MTTF可以计算出系统可以被正常使用的时间，除此之外还有，RTO和RPO分别从时间和数据两个角度分别能够验证高可用系统容灾备份在数据冗余和业务恢复方面的能力。
# 高可用性指标
| 指标 | 说明 | 含义 | 备注 |
|---|---|---|---|
| MTBF | Mean Time Between Failure | 平均无故障工作时间 | 越长越好 |
| MTTR | Mean Time To Repair | 平均修复时间 | 越短越好 |
| MTTF | Mean Time To Failure | 失效前的平均时间 | 越长越好 |
备注: MTBF = MTTF + MTTR
达到N个九的高可用性:
| 级别 | 系统可用性比率 | 最大可能服务不可用时间 | 备注说明 |
|---|---|---|---|
| 2个九 | 99% | 87.6小时 | 高可用的入门阶段，属于基本可用 |
| 3个九 | 99.9% | 8.76小时 | 较高的可用性 |
| 4个九 | 99.99% | 52.56分 | 具有自动恢复能力的高可用性 |
| 5个九 | 99.999% | 5.256分 | 极高可用性 |
| 6个九 | 99.9999% | 31.536秒 | 超高可用性 |
系统可用性比率 = MTTF/MTBF
| 指标 | 详细 | 备注 |
|---|---|---|
| RTO | Recovery Time Objective | 业务恢复指标，理想值为0 |
| RPO | Recovery Point Obejective | 数据恢复指标，理想值为0 |
# 容灾标准
根据 GB20988-2007-T 信息安全技术信息系统灾难恢复规范, 根据其定义, RTO/RPO与灾难恢复能力等级的关系具体如下所示：
| 灾难恢复能力等级 | RTO | RPO |
|---|---|---|
| 1 | 2天以上 | 1天至7天 |
| 2 | 24小时以上 | 1天至7天 |
| 3 | 12小时以上 | 数小时至1天 |
| 4 | 数小时至2天 | 数小时至1天 |
| 5 | 数分钟至2天 | 0至30分钟 |
| 6 | 数分钟 | 0 |
# 高可用性设计的策略
- 冗余
- 服务多重化
- 节点多重化
- 两地三中心
# k8s + 微服务 + DevOps
结合K8S/微服务/DevOps这三个角度，在实践中可让容器化的微服务落地更加顺畅。
# 高可用性的Kubernetes
Kubernetes提供基础平台的能力,对运行于其上的容器化的微服务提供服务自愈的能力，以及负载增大时的动态横向调整。同时使用消除单点的冗余策略保证ETCD和Master的高可用性。
# 微服务
运行在Kubernetes上的微服务在设计上进行解耦，功能简单化和独立化，与外部交流轻量化，尽量无状态以保证横向扩展方便，并可进行独立部署和回滚而不至于对其他服务照成太多影响。
# DevOps
微服务在设计上和实践上所遵循的原则很多已经和DevOps实践有了重合，而设计良好的微服务以容器化的形式存在，结合自动化工具与持续集成和持续交付的最佳实践能使得架构从设计出来到交付到生产环境的整个过程变得更加快捷和流畅。
# Kubernetes的高可用性
应用层级的高可用
容器化的微服务在kubernetes上运行，依靠着k8s的RC/deployment/DaemonSet等机制，保证服务的高可用性。
依靠这种机制，Kubernetes平台本身对运行在其上的服务来说，会监控运行在其上的应用的replication的数量，多了删，少了补。Kubernetes自身的高可用
依靠冗余策略来消除单点以保证ETCD和Master无论何时都始终可用，从而保证了平台自身的高可用。 ETCD是coreos的开源项目用于提供可靠的key/value的数据存储。而kubernetes用来保存数据。 使用ETC集群提供稳定的服务保证Kubernetes的API Server能够正常访问到ETCD服务。 Kubernetes的Master通过API SERVER与ETCD进行交互，提供统一的API入口，使用Scheduler进行资源调度，Controller-Manager进行资源管理。 一旦Master不可用，则会造成较大的影响，所以可以采用多个备用状态的Master，一旦出错便可随时切换的机制则能降低或近似消除MASTER的单点故障的可能性，从而使得Kubernetes基础平台自身更加可靠。
业务需求激增下的高可用性
考虑到动态变化对资源需求的变化以及资源的有效利用，访问量的突然增大，而资源没有及时调整会使得原本正常访问的网站也变得缓慢无比，此时则需要横向扩容。 容器化的方式之下，横向扩展变得非常容易。而且kubernetes能够在整体的基础上进行资源的协调和分配从而达到横向扩展的目的。而达到按需扩容则需要结合监控。 实时可靠的监控对高可用系统非常重要，利用很多商用的软件或者很多开源的工具进行整合甚至自行开发可以对整体的业务状况以及系统状况进行把握。在监控中确认采集到指标是否达到了动态调整的阈值，从而进行横向扩展，当然这一切，则需要监控的功能是准确的基础之上的。
# 桥梁和纽带作用的DevOps
# 环境的一致性
| 项目 | 具体说明 |
|---|---|
| 开发环境一致性 | 保证一致性的开发环境，确保所有成员在一致性的环境中进行开发，避免因各种版本不合导致的Rework。 |
| 测试环境一致性 | 一致性的测试环境避免因环境的问题出现的非缺陷性确认和对应所需时间以及缺陷的延后出现的可能性。 |
| 生产环境一致性 | 确保准生产环境能够得到尽可能类似生产环境的测试要素，同时避免因软硬件变动导致的各种问题。 |
# 安全
安全性对任何产品来说都非常重要，应尽早的将安全引入高可用性架构的设计和开发中，有问题早发现早治疗。比如Anchore或者CoreOS的Clair都能很容易的对镜像进行扫描。
# 可视化
通过对软件开发全生命周期的KPI进行管理和可视化管控。
# 弹性扩容
# 策略
DevOps实践中通过可视化的监控为扩容提供了条件，可以更加清楚的了解到什么时候扩容应该被触发，整体的策略如下：
| 马车 | 策略 |
|---|---|
| 微服务 | 容器化微服务为弹性扩容提供基础条件。在容器化的基础之上，对微服务进行优化解耦，尽量除去或者减少对横向扩容产生不利影响的要素比如有状态的服务设计。 |
| DevOps | 保障扩容的安全以及退路。强化业务和系统资源实时监控功能，以确保问题发生之前有可能的途径事先做出部分判断。保证运维操作的可回滚性，以保障问题发生之后可以迅速恢复服务的提供。 |
| K8S | 使用K8S对无状态服务可以进行非常容易地横向扩展，而有状态的方式也有类似Daemonset之类的方式进行支持。通过设定的扩容策略，在监控达到触发条件时，进行动态弹性扩容。 |
# 方式
| 步骤 | 详细 |
|---|---|
| 1 | 首先需要根据现状设定出系统和业务等的指标，在此基础之上定义扩容策略，比如每秒交易量达到多少笔或者资源情况达到多少时水平扩容。 |
| 2 | 然后采集业务日志以及系统日志 |
| 3 | 进行计算和监视，已确认自动水平扩容的触发时机,并生成扩容指令 |
| 4 | 根据扩容指令使用K8S进行横向扩容。 |