DevOps成都站|架構與運維峰會,你可能錯過的乾貨(附PPT)

DevOps成都站|架構與運維峰會,你可能錯過的乾貨(附PPT)

5月15日,UCloud主辦的Devops Workshop架構與運維峰會於成都舉行,大會邀請到了UCloud DevOps Workshop系列活動成都站,UCloud 邀請到了KVM運維專家肖力、1號店技術部-架構部總監張立剛和UCloud綜合開發中心總監文天樂,分享他們在海量服務架構探索過程中的技術實踐。


到場的聽眾來自各大互聯網公司,包括文軒在線、長虹、京東、虹微、華為、tap4fun、四川移動、三零盛安、萬達飛凡、馬上消費金融、多點生活、任我行、數之聯、TestBird、Testin、Camera360 、咕咚、啟明星辰、神州數碼等,現場積極的提問更是突顯了聽眾對內容的關注。


圖:肖力,金山西山居系統運維經理

金山西山居系統運維經理肖力,他帶來了題為《我的虛擬化項目運維實踐》的分享,從項目評估開始,介紹如何將自己的業務遷移到虛擬化或者雲上,同時介紹如何做好監控、報警、災備,持續的運維。


圖:文天樂,UCloud綜合研發總監

UCloud綜合研發總監文天樂帶來的演講主題是《賬戶計費系統高可用架構設計與實踐》,為大家著重分享了UCloud賬戶計費系統架構設計與實踐,以及演化過程中積累的經驗,主要內容有:賬戶計費系統現狀與面臨的問題、深入賬戶計費系統架構演進、簡要介紹灰度切換方案、經驗總結。他認為架構沒有最好的,只有最合適當前業務發展的架構。

以下整理了金山西山居系統運維經理肖力和UCloud綜合研發總監文天樂分享的內容。

肖力:我的虛擬化項目運維實踐

嘉賓介紹

肖力,KVM運維專家。金山西山居系統運維經理,前盛大遊戲研究員。15年工作經驗,10年遊戲行業運維經驗,5年KVM虛擬化運維經驗維護有微信訂閱號:「KVM虛擬化實踐」著有《深度實踐KVM》一書。

本次分享主要有四個部分:非技術因素及業務壓力模型構建、技術及經驗分享、監控、災備、應急響應、案例和公有雲運維的一些經驗。

本文主要截取非技術因素、業務壓力模型構建、如何將業務遷移到虛擬化環境、軟硬體選型和災備方案方面進行整理。

一、非技術因素

2015年是雲計算大爆發的一年,對雲計算虛擬化的直觀感受是人才需求量越來越大、職業待遇逐步提高,雲計算招聘的微信群異常活躍。第二個感受是做雲計算的朋友在公司內部越來越受重視。

總體來說:

1.雲是更高級的資源利用的方式

2.雲使業務部署更高效便捷

3. 隨著這幾年的發展,雲真的成為基礎架構和生態系統,在大數據、視頻、教育、醫療等各個方面得到應用。

現在的問題,已從企業要不要上雲的問題,變成為如何上雲的問題。企業上雲可以選擇使用公有雲,可以選擇自建私有雲,也可以選擇使用混合雲,大部分使用雲的方式以後應該是混合雲。

雲計算對運維人帶來的影響最為明顯的是分工更專業、要求更高,比如原來你在一個公司的內部,可能是計算或業務方面的運維;在上雲后,可能會把系統、底層方面的運維工作都交到雲,從而將更多精力關注到業務,將業務做得更好、更專業。如果去做私有雲,也就是IaaS層的運維,包括數據中心、網路、安全等,只在大型企業存在,。此外,因為雲計算平台有眾多的API,如果你利用好這些API,可以實現從底層到上層的全面打通,運維方面的趨勢是更強調自動化


二、業務如何遷移到虛擬化環境

第一步,要說服老闆和同事支持做虛擬化。隨著雲計算虛擬化概念的普及,很多人對雲已然不再如開始般排斥,但是去做第一個項目時,一定要保證它的成功,樹立好榜樣。

第二步,如何選擇潛力股

如何保證第一個項目成功虛擬化呢?一定要選擇潛力股,找到一個比較好做成功的虛擬化項目,它有很多特徵:

  • 單進程,現在CPU都是多核的,單進程可以非常容易去做;

  • 其次是利用率不高的業務,比如常年那些利用率只有20~30%的業務,可通過將幾個業務合併到一個宿主機上,從而提高它的利用率;

  • 頻繁變動的業務,通常非常喜歡做虛擬化,因為虛擬化快速部署的提點,解決了業務頻繁變動這樣的痛點;

  • 非核心業務,如果一開始就著手核心業務做虛擬化,一旦出現問題,將面臨著很大的壓力,甚而會影響到整個公司對於虛擬化的信心,所以第一個虛擬化項目從非核心業務開始。

另外,不是所有業務時候做虛擬化,在物理機上壓力已經非常高的業務,就很難通過虛擬化來做整合。

第三步,虛擬化項目實施周期。實施虛擬化一般應該遵循以下樣的流程:業務性能需求評估、根據壓力模型設計一個虛擬化方案、搭建測試環境、系統綜合測試、業務測試、小規模部署、全面部署、全面部署好最終的虛擬化運維。

第四步,解決實施中的問題。在實施過程中有一些問題需要注意,首要關注虛擬化層的穩定性,然後虛擬機快速自動管理維護,接著解決與業務更緊密的結合,最重要的是需要擁有一套監控、健康、報警、應急習響應預案。

三、業務壓力模型分析


構建業務壓力模型的時候,如何具體地做。首先要對業務架構熟悉,它的邏輯角色類型是怎樣的,最好畫一個圖出來做到心中有數,明確角色間的關係

然後進行性能數據收集與分析,有兩種方法:

  • 一是收集每個項目的伺服器數量和角色,看長期的監控數據、CPU內存等壓力情況,一般觀察兩個月;

  • 二是通過腳本收集現有伺服器性能,這個主要為了收集更細的數據;

  • 通過收集的壓力數據,得出壓力模型,根據壓力模型,確定虛擬化比例

 

四、軟硬體選型

 軟體方面,對於生產環境我們一般肯定要選擇穩定版本。但是,在穩定版本的基礎上,內存版本越高越好,為什麼?這裡有一個數據,數據時間比較長,同樣配置情況下CentOS 6.1和 CentOS 5.6的CPU計算能力的對比,CentOS 6.1要比CentOS 5.6好9%,就是內核版本越高,它的CPU中斷和上下文切換優化得越好,同時網路IO、磁碟IO也優化得越好。

硬體方面,盡量一開始配置要稍微好一點,因為配置得越強悍,你可以虛擬的虛擬機越多,你最終肯定節省成本;另外,內存也要稍微大一點,因為你的宿主機跑上一段時間以後,往往你會發現內存不夠,到時候又要加內存。最後,盡量選擇主流品牌。


五、災備方案

虛擬機災備策略—應用層備份(在線遷移不是災備手段)

災備有兩種思路:

  • 應用層災備,基本上跟原來物理機上一樣,你在物理機上怎麼做災備,在虛擬機上用同樣的方法做災備;

  • 虛擬化災備,做快照,做多份的鏡像複製。

一般建議在應用層次做災備,因為在應用層做災備消耗的資源要少很多。注意的是,災備要定期演練,一方面讓大家熟悉過程,再來驗證一下災備這個機制到底是不是生效,可總結為兩點:

  • 所有的虛擬機xml描述文件應定時交叉備份;

  •   XML 描述文件與IP 地址信息需要同時備份;

  • 定期演練,我們自己要熟悉過程,相關的業務也需要讓他們去演練一下,出現問題的時候我們可以很快的恢復。


總結

第一個上雲是趨勢,虛擬化是第一步;然後在生產環境,我們盡量選成熟的技術、完善的預案,因為對生產環境要有定位;虛擬化是基本的IT技能,不管原來做哪方面的運維,可能或多或少用到虛擬化的運維。此外,我們在企業內部推薦虛擬化的時候,口碑也是非常重要的,一旦有問題就會影響我們口碑去推需虛擬化。

文天樂:賬戶計費系統高可用架構實踐

嘉賓介紹

文天樂,UCloud綜合開發中心總監全面負責UCloud經營數據分析、賬戶計費系統、網路、多賬號平台研發項目。擁有7年以上互聯網及 IT 研發相關經驗,曾就職于商派、盛大在線、盛大雲,歷任高級研發工程師,盛大雲監控及計費產品的開發負責人。

本文主要截取賬戶計費系統架構演進過程的六個階段進行整理。


服務架構的演進過程


UCloud服務架構的演進主要經歷了以下六個階段:

  • 單體模式;

  • 具有灰度發布能力;

  • 前後端分離;

  • 服務化改造;

  • 按SET部署;

分機房按SET部署,按SET進行跨機房熱備容災


1. 單體模式架構上線業務系統

UCloud服務初期上線時的架構主要分三部分:

  • PHP Web Conosle,負責所有前端展現交互、後台服務間邏輯組裝;

  • 平台類服務,賬戶、計費、監控、名字服務等公共服務;

  • 各業務系統分數據中心後台服務的接入層。

PHP Web Console、業務系統分數據中心的服務、平台類服務組合上線,Web Console 通過Protobuf與所有後端服務進行通信。


2. 具備灰度發布能力

要解決前面面臨的問題,我們首先需要支持Web層灰度發布包含以下的灰度方式:

  • 無用戶態特性按照 單IP -> IP段(地區) -> 到IP取模逐步灰度控制影響範圍;

  • 有用戶態特性按照 單內部用戶(開發賬號) -> 內部測試賬號 -> 用戶分級逐步灰度發布控制影響範圍。


3. 前後端分離

  • 開發API Gateway 層用來管理後端 API 註冊和管理、許可權驗證管理、流量控制;

  • 開發API層,解決前台交互層,需要整合跨系統邏輯調用問題,前端只專註產品交互和用戶體驗;

  • 開發統一的單點登陸Token,系統方便前端實現跨域API調用讓前端代碼可以完全靜態化。

在此階段,完成前端展現可以獨立控制發布,徹底實現了前後端解耦,API協議保證向前兼容,Web端可以隨意重構交互優化前端架構,實現了跨域獨立部署,獨立的灰度策略互相之間不受影響,極大的提高了前端團隊開發效率和穩定性。


4. 服務化改造

 對業務端API開發效率優化:

  • 按照業務模塊化,所有業務API由後台產品研發部門獨立部署發布上線;

  • 抽象通用平台類特性例如:子賬號特性,許可權體系,計費等特性抽象公共能力讓業務端在API中組裝。

總體目標:讓業務API開發效率提升並單獨部署維護,提高產品特性的研發迭代效率並提高穩定性。


5. 按SET部署

基礎架構優化完畢,各個業務系統單獨部署發布,開始對系統進行容量和容災方面的考慮,從部分平台類系統開始考慮按SET部署架構測底解決容量和容災問題,每個SET只服務一部分用戶,保證遇到物理伺服器宕機等故障情況下隻影響部分用戶或業務。

例如圖上所示, SET 1 服務1 ~ 服務50000000 用戶,SET 2 服務50000001 ~ 100000000 的用戶,一個SET 出現問題隻影響一個部分用戶,不同的業務根據自身情況進行SET切分,規模大小也視情況而定,按SET部署后合理的劃分方式下不同SET之間數據還可以互相遷移,來平衡搞負載或高容量的SET,極大的提高了可運維性。


6. 分機房部署SET

按SET部署架構改造完畢后還沒有達到最理想的狀態,如果所有服務部署在單機房還是可能會出現問題,機房整體出現斷電、斷網等故障還是會出現大面積影響。

  • 對SET架構進行分機房部署,讓不同的用戶運行在不同的機房中,這依賴一些基礎設施比如跨機房光線專線。

  • 跨地域SET在相鄰節點部署熱備,以便出現機房故障時能具備異地快速恢復服務的能力。

總體介紹了UCloud在不同的階段架構演進的一些過程和經驗,架構沒有最好的,只有最合適當前業務發展的架構。



點擊閱讀原文,下載PPT資料,開門口令:kqjr

優刻得雲計算(ucloud2012)


---
資料來源:DevOps成都站|架構與運維峰會,你可能錯過的乾貨(附PPT)
如果內容有不適當或對出處有疑慮,請立即通知客服中心
Facebook留言板
您可能有興趣
客服信箱 客服信箱
一則未讀訊息
聯絡線上客服