如何理解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組件高可用的思路，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。