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，數據治理，移動架構原創技術分享