雲原生趨勢下的遷移與災備思考

語言: CN / TW / HK

由於成本的降低和業務的便捷性,越來越多的企業將自己的IT系統遷移到雲端,但在遷移的過程中,面對一個新的環境,從基礎設施的部署到雲平臺的挑戰都十分的具有挑戰性,如何保證雲遷移的安全?如何減少遷移風險?如何權衡線上穩定性和敏態交付?成為了企業IT管理者十分關注的問題。

今天為我們解答以上問題的嘉賓,是來自浙江移動的雲智慧平臺運維架構師史軍艇老師。希望通過彙集史軍艇老師的研究成果和實踐經驗,帶大家瞭解雲原生環境下存在的安全問題,規避雲上可能會遇到的問題,保障雲原生應用的執行穩定性。

史軍艇

浙江移動 雲智慧中心運維架構師

  • 8年應用優化及SRE經驗,2013年起從事應用運維、穩定性提升、架構優化等工作;專注於穩定性體系建設及分散式系統架構治理。樂於研究新解決方案及新技術。目前負責浙江移動線上系統應用架構治理和穩定性體系建設工作,並作為浙江移動混沌工程負責人,推動中國移動集團內演練方案實施。 

主要觀點

個人認為,要解決這些問題,需要從企業層面建設一套的穩定性體系,包括架構設計、上線變更、故障抵禦、線上治理,貫穿整個過程。而這其中表達的意思,穩定性不至於故障抵禦,更要往前看,從架構設計開端,去做高價值交付。實踐過程中,我們衍化出一些有效的工程,比如流量回放、灰度釋出、混沌工程、平面逃生等,保障了每一個過程的平穩連結,確保上雲風險降到最低。

Q1雲原生下,如何權衡線上穩定性和敏態交付?

穩態(穩定性)和敏態,就是我們說的雙態模式。我理解應該是敏態催生了雲原生,而後雲原生又推動了穩定性。正如我們所說,雲原生是從傳統“原子時代”跨越到“位元時代”的,它的具體表現形式是容器化支撐+微服務體系,配套而生的就是DevOps和持續交付,而這一切確實都是為了核心業務的快速迭代為出發點的。

因此,我們需要穩定性體系/SRE體系來給予運營端足夠的信心,浙江移動在穩定性方面確實也摸索了很多年,我們算是傳統行業中運維轉型走得比較早的。研發眼中是DevOps,我們眼中就是OpsDev,這兩者並不衝突。在整個穩定性體系中,除了基本的故障抵禦體系外,Ops必須要把步子往前邁,邁過上線釋出,邁到架構管控及設計,這樣和線上治理組合起來才是一整套交付護航體系。其中涉及到的工程實踐,就會用到灰度釋出、混沌工程、多可用區之上的自智網路能力等,用此去保證交付質量、上線質量和執行質量。

Q2雲環境下的災備如何進行設計?

我這裡主要聊一下應用服務的災備設計,相信資料庫的變化會相對小一點。對於應用架構,雲環境下會涉及到複雜的微服務呼叫,以及容器雲平臺的計算資源控制管控,另外還有公用依賴的一些公共元件。我們會建議企業做雙平面/雙可用區設計,這裡的平面縱深會比較深,從容器雲的管理(mesos、marathon、k8s),還是公共元件、配置中心、註冊中心、快取平臺等,當然還包括上層應用,都需要進行雙活雙平面改造。這樣才能在保證流量的前提下,可以在兩套不同的環境下精確倒換、逃生。

像資源相對富足的公司,或者說針對核心業務,願意再多投入一點點資源的,可以再適配一個10%-20%的小平面,用於形成更為完善的逃生能力、釋出能力、演練能力。

Q3相比於傳統災備架構,雲環境的災備架構規劃會有哪些異同點?

個人覺得傳統的災備主要考慮的是高可用,我們只要關注雙機房、例項冗餘負載等,相對簡單清晰。而如上個問題提到的,雲環境下的災備架構考慮的層次會更深,在傳統架構災備要求的前提下,需要貫通每一層的平面級拆分。另外,因為雲環境從例項呼叫層面的可閱讀性會大大降低,所以導致普通的高可用,可能在故障處置上會有一定劣勢。建議採用單元化的設計,從流量入口就具備排程能力,做好準確自動的平面逃生,當然該有的觀測性等配套要求也會更高。

Q4企業原先生產環境複雜,導致上雲遷移和業務重構難度大。對此,有什麼可參考的落地步驟和技術路線嗎?

研發和SRE兩條腿走路,並且要步調一致,一起走。因為大型系統的上雲其實是一個非常大的工程,或者是有較大風險的工程。從研發層面,原有的複雜呼叫,該拆就拆,從設計方案中,去考慮拆分的可行性,而這個時候, SRE 就需要一起參與,通過非功能的視角,去進行紙牌推演、沙盤推演,可以和研發互相pk。從工程保障角度,我們要確保割接方案的快速回退,老的環境並行儲存等注意事項。新環境在通過紙牌推演後,進入到上線前的實戰演練驗收,這個時候可以通過回放的流量去模擬驗證。在釋出工程中,用灰度的滾動釋出模式,確保平滑割接過渡。​