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

高可用架构的挑战

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

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

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

整体原则和策略

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

目标&指标

物有本末,事有终始,知所先后,则近道矣。了解设计的目标，以终为始很关键。良好的系统解耦，扩展性，可维护性等都很重要，但是服务的稳定性和连续性则更为重要。
衡量高可用性也有很多指标比如MTTF/MTTR/RPO/RTO，根据MTTR和MTTF可以计算出系统可以被正常使用的时间，除此之外还有，RTO和RPO分别从时间和数据两个角度分别能够验证高可用系统容灾备份在数据冗余和业务恢复方面的能力。

高可用性定义

MTBF = MTTF + MTTR

一般来说达到N个九的高可用性，具体含义如下：

系统可用性比率 = MTTF/MTBF

容灾标准

根据 GB20988-2007-T 信息安全技术信息系统灾难恢复规范 ， 根据其定义，RTO/RPO与灾难恢复能力等级的关系具体如下所示：

高可用行设计的策略

保证整体架构的高可用性，有很多策略和手段，比如

• 冗余
• 服务多重化
• 节点多重化
• 两地三中心
• …

K8S + 微服务 + DevOps

在具体的实践中，将目标聚焦到K8S/微服务/DevOps这三个角度，这三架马车各司其职，使得容器化的微服务落地更加顺畅。

高可用性的Kubernetes

Kubernetes在这其中起到的是基础平台的作用，Kubernetes提供基础平台的能力，对运行于其上的容器化的微服务提供服务自愈的能力，以及负载增大时的动态横向调整。同时使用消除单点的冗余策略保证ETCD和Master的高可用性。

微服务

运行在Kubernetes上的微服务在设计上进行解耦，功能简单化和独立化，与外部交流轻量化，尽量无状态以保证横向扩展方便，并可进行独立部署和回滚而不至于对其他服务照成太多影响。

DevOps

微服务在设计上和实践上所遵循的原则很多已经和DevOps实践有了重合，而设计良好的微服务以容器化的形式存在，结合自动化工具与持续集成和持续交付的最佳实践能使得架构从设计出来到交付到生产环境的整个过程变得更加快捷和流畅。

高可用的Kubernetes

高可用的Kubernetes平台应该能保障如下三种层次的高可用性：

• 应用层级
• Kubernetes自身
• 业务需求激增下的高可用性

层级的高可用行

容器化的微服务在kubernetes上运行，依靠着k8s的RC/deployment/DaemonSet等机制，保证服务的高可用性。
依靠这种机制，Kubernetes平台本身对运行在其上的服务来说，会监控运行在其上的应用的replication的数量，多了删，少了补。

Kubernetes自身的高可用性

依靠冗余策略来消除单点以保证ETCD和Master无论何时都始终可用，从而保证了平台自身的高可用。
ETCD是coreos的开源项目用于提供可靠的key/value的数据存储。而kubernetes用来保存数据。使用ETC集群提供稳定的服务保证Kubernetes的API Server能够正常访问到ETCD服务。
同样，Kubernetes的Master大家都很熟悉，通过APISERVER与ETCD进行交互，提供统一的API入口，使用Scheduler进行资源调度，Controller-Manager进行资源管理。
一旦Master不可用，则会造成较大的影响，所以可以采用多个备用状态的Master，一旦出错便可随时切换的机制则能降低或近似消除MASTER的单点故障的可能性，从而使得Kubernetes基础平台自身更加可靠。

业务需求激增下的高可用性

严格来说，横向扩展并不一定是一个高可用性架构的必须，但是考虑到动态变化对资源需求的变化以及资源的有效利用，不用说ROI，访问量的突然增大，而资源没有及时调整也会使得原本正常访问的网站也变得缓慢无比，而这个时候则需要横向扩容。
容器化的方式之下，横向扩展变得非常容易。而且kubernetes能够在整体的基础上进行资源的协调和分配从而达到横向扩展的目的。而达到按需扩容则需要结合监控。
实时可靠的监控对高可用系统非常重要，利用很多商用的软件或者很多开源的工具进行整合甚至自行开发可以对整体的业务状况以及系统状况进行把握。在监控中确认采集到指标是否达到了动态调整的阈值，从而进行横向扩展，当然这一切，则需要监控的功能是准确的基础之上的。

专注于业务开发的微服务

自动化流水线

有了Kubernetes提供的基础平台服务，比如服务的多重控制都可以通过kubernetes来实现，而微服务则可以专注于业务价值的实现。
微服务的方式跟传统的SOA非常的类似，抛开概念之争，让我们重新思考一下传统企业那种超重的单一应用会有那些问题：经年累月之后，这种本来就很庞大的系统最终会形成一个谁也不敢轻易去动的多米诺骨牌： 修改成本巨大，扩展困难。在大型的项目中很多人都有过修改一行代码，判断影响要查几天的通过经历，这其实主要还是源于系统过于复杂，如果是边界清晰的小型规模的模块或者服务，到底应该怎样改会容易判断地多。
而微服务，通过尽可能对功能进行简单化/小型化，划定明确的功能边界，降低和其他模块的耦合度，通过规范化的轻量的RestAPI进行交互，服务的部署独立可置换使得对整体的影响较小，即使出问题也能限定影响范围，这种方式其实在传统的SOA方式的架构设计中我们也会经常考虑，只是在DevOps运动推行之前，部署的独立化这些要素没有覆盖，另外与微服务的微相比，显得更大更重一些而已。
目前也有很多开源的框架可以使得微服务落地时更加快捷，比如使用Spring Cloud提供的很多开箱即用的功能，服务注册，API网关，负载均衡，配置中心等等拿来即用，而我们只需要专注于业务功能的实现即可，而这些大大提高了效率。

桥梁和纽带作用的DevOps

微服务带来的有清晰的边界和可控的影响范围，但微服务也会带来一些新的问题。比如接触过的一个项目说他们推行了微服务，最大的好处就是以前部署一个包一次结束的事情现在需要做二十次。虽然是句玩笑，但是也说明了一个事实。微服务在设计上将业务功能解耦拆解成了可独立部署小型单元，但是随着服务的增多，这些在部署上会带来很多影响。
根据2017年DORA发布的最新现状研究报告，给予了更多权利，能够自主选择工具的团队能表现更好。所以在实践中我们让团队去能够使用他们熟悉的工具自定义自己的流水线进行持续集成和持续交付。从代码的提交，然后进行代码检查，自动化构建一极各种测试，使用同样一种机制进行部署，可定制的流水线使得这一切变得是可靠的安全的和快速的。

环境的一致性

环境的一致性，我们指的是整体环境的一致性：开发环境/测试环境/生产环境的一致性。

安全

我们一直都非常强调安全的重要性，尤其是高可用性架构，所以我们在保证环境一致性的同时都会保证很多，比如镜像的安全性。早在2015年的一次调查中，研究者就曾发现取样的Dockerhub上有30%-40%的镜像存在安全性的问题。安全性对任何产品来说都非常重要，比如著名的HeartBleed就曾经给很多忽视安全问题的企业带来了很大的影响，如果你所有的架构都是高可用的，但是你的镜像安全忽视了，万一镜像中想HeartBleed那样的脆弱性的CVE没有对应，有可能会带来非常之大的影响，所以尽早的将安全引入高可用性架构的设计和开发中，有问题早发现早治疗。比如Anchore或者CoreOS的Clair都能很容易的对镜像进行扫描。

可视化

通过对软件开发全生命周期的KPI进行管理和可视化管控。从构建到测试，从开发到部署到运维的监控, 从构建频度到成功率，更加有效的掌握整体情况，在实际的DevOps落地实践中通过有效的可视化打通那堵看不见的”墙”。
这些可视的KPI不仅使流程更加透明，运维监控更是直接为按需横向扩展需求下的高可用性的设计提供非常比较的触发判断机制。

弹性扩容

策略

DevOps实践中通过可视化的监控为扩容提供了条件，可以更加清楚的了解到什么时候扩容应该被触发，整体的策略如下：

方式

整体的策略确定之后，动态实施的方式就会非常的简单了。

总结

容器化的微服务如何利用kubernetes平台提供的基础能力，从而使得微服务能够专注于业务开发，而DevOps利用定制化的流水线的落地，则能保证微服务的交付更加快速和安全; 同时结合DevOps的可视化和透明化实践的落地，则能保障动态弹性扩容机制的实现，整体使得基于容器化的微服务的架构具有更高的可用性。