基于DevOps、微服务以及k8s的高可用架构探索与实现

现代的企业面临着一个VUCA的时代，高可用系统架构面对着诸多不确定性带来的影响和挑战，如何才能能够突破困境，使得复杂的系统仍然能保持业务的连续性。业务的弹性扩容也同时会对高可用性的架构造成影响，在实践中，我们结合微服务/K8S/DevOps这三架马车进行了微服务的容器化的实践之路。

高可用架构的挑战

在现实的复杂而又不确定性的环境下，高可用架构面临诸多挑战，都可能对系统带来巨大影响，比如：

• 应用程序的异常退出
• 操作系统的突然宕机
• 服务器的意外断电
• 运维人员人为操作失误
• 地震等不可抵抗因素
• 业务量的突然增大
• …

天灾和人为操作失误等不确定因素之外，从整体的角度来说，
现在企业级的高可用架构已经变得越来越复杂，我们往往需要在多种OS并存，各种软硬件的结合，多种开发语言并用，新旧系统共存存的条件下进行高可用行设计，
加之无时不在的变更，动态横向的需求不断提高，速度和稳定同时需要被满足，这些都使得高可用的架构变得越来越困难。

整体原则和策略

企业级高可用性架构面临着的这些的挑战，，如何才能能够突破困境，使得复杂的系统仍然能保持业务的连续性,同时如何实践微服务和容器化等技术的实践，这里将会列出整体的原则和策略。

目标&指标

物有本末,事有终始,知所先后,则近道矣。了解设计的目标，以终为始很关键。良好的系统解耦，扩展性，可维护性等都很重要，但是服务的稳定性和连续性则更为重要。
衡量高可用性也有很多指标比如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个九的高可用性，具体含义如下：

级别	系统可用性比率	MAX最大可能服务不可用时间	备注说明
2个九	99%	87.6小时