DevOps组件高可用的思路

转载本文需注明出处：EAWorld，违者必究。

引言：

以往部署的应用或服务基本都是自成体系不会被其余影响。而在DevOps下这种部署方式也正在发生改变。由于应用或服务自己所涉及的组件愈来愈多。DevOps串联着应用或服务以及应用和服务所涉及的组件，以保证全部应用和服务的正常运行。

目录：

1、传统高可用

2、DevOps 简述

3、传统高可用架构模式

4、DevOps 带来的改变


1、传统高可用

传统生产模式下，如应用、中间件以及数据库等服务都须要有高可用。以免业务服务出现宕机的问题。



常见的部署方法，有服务主备、服务集群，还有两地三中心的高可用方案。



高可用常见的指标，以及服务宕机时间。

 

https://en.wikipedia.org/wiki/Mean_time_between_failures
MTBF = MTTF + MTTR

365*24*(1-0.99)=87.6,在实际状况下固然故障时间越短越好

系统可用性比率 = MTTF/MTBF

2、DevOps简述



1?DevOps带来的变化就是整个部署过程是自动化的、部署的周期变短了。开发和运维所关注的焦点也发生了变化。开发人员从提交代码，到看到本次修改的内容能够在很短的时间内完成。

2?在实际的接触的过程当中，因为DevOps串连了多重的应用服务，所以许多人会提出对于DevOps所串联的组件都必须是高可用。所以问题就出现了，使得本来简单清晰的架构发生了很大的变化。

3?DevOps带来的变化与传统的高可用是有区别的。

3、传统高可用架构模式



说明: 简单的将Gitlab服务作成主备，或者主主的方法。这样的Gitlab服务已经从单点变成的了稍微复杂的架构。



这样咱们的harbor也已经变成高可用了，当经过程devops串联后，运维变得复杂起来。固然DevOps还能够串联更多的组件，这里只是举了两个例子。

4、DevOps带来的改变



进入DevOps时代，DevOps在串联组件高可用时，对于组件的要求也发生了变化。因为DevOps起到了串联的功能，因些但愿全部的组件便可以高可用也能够是分布式的，但愿全部服务都是可解耦的。



从图上能够看到，APP这一层就是一个简单的分布式。这也许是咱们常常部署的一种典型的架构。简单的将APP这层进行了分布式的设计。而其余的组件仍是沿用传统集群的部署模式，但在这种架构的部署模式下，增长了运维的难度。


复杂的分布式在图中看起来比简单分布式要简单。但在实践中会发现这个会很难。由于APP、Cache、DB、Storage等等都是分布式的，这样复杂对于架构上提出了很高的要求，同时对于运维也增长了难度。图上画的比较少，但实际上复杂的分布式比这要多的多。

也许集群就是分布式。也许集群只是解决高可用的，而分布式是解决高并发、高性能的问题，也许集群是分布式的一部分。每一个人都有本身的理解，理解你的本身的业务、需求等等。

其实还有一种技术能够来帮助咱们实现分布式部署，就是容器技术。经过kubernetes来实现本身所需求应用的高可用以及应用的分部式。



当随着微服务和devops的到来，容器化的微服务和devops更好的落地实现。高可用的kubernetes为咱们提供了基础的容器平台和容器的调度能力。Kubernetes自己就具有容错能力。

也许你会说横向扩展并非高可用的架构。但若是你考虑到业务对资源需求变化时，你会发现kubernetes的部署对你很是用利。当访问量突增时，就能够利用kubernetes的横向扩展能力。而不是像以往在从零开始。

同时Kubernetes自己时可靠的监控对高可用系统很是重要，利用不少商用的软件或者不少开源的工具进行整合甚至自行开发能够对总体的业务情况以及系统情况进行把握。也可使用额外的开源软件promethus等来对业务情况的监控。

做者观点：适合本身的才是最合适本身的。

并非全部服务都适合容器部署

高可用的选择须要适合本身的体系
 

因为DevOps串联了整个周期，同时须要咱们作出改变。

 

关于做者：严伟，现任普元基础设施架构师，网络专家。传统企业突破内部局域网，公有云化之路上的幕后英雄 。


 

 

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享