转载本文需注明出处：EAWorld，违者必究。
引言：
以往部署的应用或服务基本都是自成体系不会被其他影响。而在DevOps下这种部署方式也正在发生改变。因为应用或服务本身所涉及的组件越来越多。DevOps串联着应用或服务以及应用和服务所涉及的组件，以保证所有应用和服务的正常运行。
目录：
一、传统高可用
二、DevOps 简述
三、传统高可用架构模式
四、DevOps 带来的改变
一、传统高可用
传统生产模式下，如应用、中间件以及数据库等服务都需要有高可用。以避免业务服务出现宕机的问题。
常见的部署方法，有服务主备、服务集群，还有两地三中心的高可用方案。
高可用常见的指标，以及服务宕机时间。
https://en.wikipedia.org/wiki/Mean\_time\_between\_failures
MTBF = MTTF + MTTR
365*24*(1-0.99)=87.6,在实际情况下当然故障时间越短越好
系统可用性比率 = MTTF/MTBF
二、DevOps简述
1?DevOps带来的变化就是整个部署过程是自动化的、部署的周期变短了。开发和运维所关注的焦点也发生了变化。开发人员从提交代码，到看到本次修改的内容可以在很短的时间内完成。
2?在实际的接触的过程中，由于DevOps串连了多重的应用服务，因此许多人会提出对于DevOps所串联的组件都必须是高可用。因此问题就出现了，使得原本简单清晰的架构发生了很大的变化。
3?DevOps带来的变化与传统的高可用是有区别的。
三、传统高可用架构模式
说明: 简单的将Gitlab服务做成主备，或者主主的方法。这样的Gitlab服务已经从单点变成的了稍微复杂的架构。
这样我们的harbor也已经变成高可用了，当通过程devops串联后，运维变得复杂起来。当然DevOps还可以串联更多的组件，这里只是举了两个例子。
四、DevOps带来的改变
进入DevOps时代，DevOps在串联组件高可用时，对于组件的要求也发生了变化。由于DevOps起到了串联的功能，因些希望所有的组件即可以高可用也可以是分布式的，希望所有服务都是可解耦的。
从图上可以看到，APP这一层就是一个简单的分布式。这也许是我们经常部署的一种典型的架构。简单的将APP这层进行了分布式的设计。而其他的组件还是沿用传统集群的部署模式，但在这种架构的部署模式下，增加了运维的难度。
复杂的分布式在图中看起来比简单分布式要简单。但在实践中会发现这个会很难。因为APP、Cache、DB、Storage等等都是分布式的，这样复杂对于架构上提出了很高的要求，同时对于运维也增加了难度。图上画的比较少，但实际上复杂的分布式比这要多的多。
也许集群就是分布式。也许集群只是解决高可用的，而分布式是解决高并发、高性能的问题，也许集群是分布式的一部分。每个人都有自己的理解，理解你的自己的业务、需求等等。
其实还有一种技术可以来帮助我们实现分布式部署，就是容器技术。通过kubernetes来实现自己所需求应用的高可用以及应用的分部式。
当随着微服务和devops的到来，容器化的微服务和devops更好的落地实现。高可用的kubernetes为我们提供了基础的容器平台和容器的调度能力。Kubernetes本身就具备容错能力。
也许你会说横向扩展并不是高可用的架构。但如果你考虑到业务对资源需求变化时，你会发现kubernetes的部署对你非常用利。当访问量突增时，就可以利用kubernetes的横向扩展能力。而不是像以往在从零开始。
同时Kubernetes本身时可靠的监控对高可用系统非常重要，利用很多商用的软件或者很多开源的工具进行整合甚至自行开发可以对整体的业务状况以及系统状况进行把握。也可以使用额外的开源软件promethus等来对业务状况的监控。
作者观点：适合自己的才是最合适自己的。
并不是所有服务都适合容器部署
高可用的选择需要适合自己的体系
由于DevOps串联了整个周期，同时需要我们做出改变。
关于作者：严伟，现任普元基础设施架构师，网络专家。传统企业突破内部局域网，公有云化之路上的幕后英雄 。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享
