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

Posted 2021-02-04 firsttry

现代的企业面临着一个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小时	高可用的入门阶段，属于基本可用
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在这其中起到的是基础平台的作用，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发布的最新现状研究报告，给予了更多权利，能够自主选择工具的团队能表现更好。所以在实践中我们让团队去能够使用他们熟悉的工具自定义自己的流水线进行持续集成和持续交付。从代码的提交，然后进行代码检查，自动化构建一极各种测试，使用同样一种机制进行部署，可定制的流水线使得这一切变得是可靠的安全的和快速的。

环境的一致性

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

项目	具体说明
开发环境一致性	保证一致性的开发环境，确保所有成员在一致性的环境中进行开发，避免因各种版本不合导致的Rework。
测试环境一致性	一致性的测试环境避免因环境的问题出现的非缺陷性确认和对应所需时间以及缺陷的延后出现的可能性。
生产环境一致性	确保准生产环境能够得到尽可能类似生产环境的测试要素，同时避免因软硬件变动导致的各种问题。

安全

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

可视化

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

弹性扩容

策略

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

马车	策略
微服务	容器化微服务为弹性扩容提供基础条件。在容器化的基础之上，对微服务进行优化解耦，尽量除去或者减少对横向扩容产生不利影响的要素比如有状态的服务设计。
DevOps	保障扩容的安全以及退路。强化业务和系统资源实时监控功能，以确保问题发生之前有可能的途径事先做出部分判断。保证运维操作的可回滚性，以保障问题发生之后可以迅速恢复服务的提供。
K8S	使用K8S对无状态服务可以进行非常容易地横向扩展，而有状态的方式也有类似Daemonset之类的方式进行支持。通过设定的扩容策略，在监控达到触发条件时，进行动态弹性扩容。

方式

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

步骤	详细
1	首先需要根据现状设定出系统和业务等的指标，在此基础之上定义扩容策略，比如每秒交易量达到多少笔或者资源情况达到多少时水平扩容。
2	然后采集业务日志以及系统日志
3	进行计算和监视，已确认自动水平扩容的触发时机,并生成扩容指令
4	根据扩容指令使用K8S进行横向扩容。

总结

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

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow