《[YY互娛]基于 DevOps 理念的私有 PaaS 平臺實踐》要點：
本文介紹了[YY互娛]基于 DevOps 理念的私有 PaaS 平臺實踐，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

劉亞丹 ? YY 互動娛樂事業部運維經理

負責YY互娛事業部的基礎運維平臺建設管理工作,8年互聯網運維從業經驗、經歷服務器從數百到數千的規模,走過從手工運維到自動化平臺化運維方式轉變,積極擁抱云計算大潮,推行 Web 類業務邁向虛擬化云化的基礎設施,致力于 PaaS運維平臺的 ITIL理念與 DevOps 理念融合、對云形態下的互聯網企業運維平臺建設管理有較深理解和實戰經驗.

前言

云計算從2006年 AWS 推出 EC2開始,至今已經10年,從最開始多數人不清楚云計算為何物,到如今,大到 BAT等互聯網公司,傳統金融、證券、制造業企業,小到初創企業,都在積極推進云計算戰略,以此加快業務交付效率,降低成本、提升競爭力.云計算的首要目的是將底層硬件抽象化,向上提供計算資源,存儲資源,網絡資源.

其關鍵核心是提高了IT業務交付效率,使企業花費更少的錢,辦更多的事情,同時滿足質量,安全的需求.在云計算大潮下,企業內IT部門,需結合自身的業務特點,思考提供怎樣的云計算基礎設施服務(IaaS),以及基于 IaaS又提供怎樣的 PaaS ,才能滿足企業對于質量,效率,成本,安全四元組合的最佳要求,是擺在每一個運維從業者面前的問題.

YY 互娛基于 DevOps 理念,并結合 ITIL 最佳實踐理念,從13年開始推出自己的IaaS,基于自身條件,推出一套符合企業內部要求的私有 PaaS 運維平臺,并在實踐中不斷的改進完善IaaS,PaaS.本文將系統的從4個方面,分享YY互娛運維團隊對于 PaaS 運維平臺實踐經驗及未來展望,希望對大家有一些參考意義.

一、 運維價值體系

說到運維,還得從運維的價值體系說起.運維的價值體系,從四個維度來概括,即質量,效率,成本,安全.這體現的是一個經濟問題,是運維部門總結工作時,公司高層能聽得懂的語言.我們從事一切運維工作,大到公司運維平臺體系構建,小到某項具體運維工作,最終將從這4個維度的數據來衡量,因此,運維工作應該以提高業務的質量,效率為出發點,在成本和安全中尋求最佳平衡點.在云計算的形式下,應當以自動化,服務化等技術手段為依托,數據化,可視化體現運維的價值輸出.

二、 運維平臺化方式

縱觀整個運維技術的發展歷程,運維平臺化體系建設,我們認為主要有以下3種形式.

1. 面向流程

提供獨立的工具子系統,再將工具 API 化,向上提供整合能力.

上面這種運維平臺模式,是典型的以 ITIL 最佳實踐為參考的運維體系建設.我們從一個常見的業務上線場景說起,來看看這種模式的特點.

假如一個 Web 業務需要上線,需要服務器資源,需求人(開發或者業務運維)需要到 CMDB 查看是否有空閑資源,若有,則到“服務器申請”流程里面提一個工單,經過一個審批流程(至少3個審批節點),拿到服務器.

同樣,業務上線還需要數據庫,需要緩存,需要 DNS 解析,需要開通權限,需要添加監控等等,需求人都必須到相應的系統提單,才能完成需求.這樣的流程體系下,對于需求的管理方是比較好的,各類需求,資源都可以較好的記錄以及控制.

但對于核心的業務上線,變更、即面向用戶的價值交付,效率很低,業務上線周期長,人力成本高.

ITIL 最佳實踐中總共包括六大操作流程五大服務支持流程,流程都包括五大要點：流程目標、基本概念、主要活動、好處與風險,以及關鍵績效指標與報表.以流程為導向建設運維體系,在互聯網時代本身變化極快,不斷試錯,追求敏捷高效的目標沖突越來越大.

ITIL 面向流程的運維體系亟需改進,而改進的方向,即面向業務的服務化方向改進.

2. 面向服務

基礎組件API 化(IaaS化),向上提供整合能力,再做面向運維的集中信息管理,配置管理,變更管理等.

如上圖所示,我們仍舊以一個 Web 業務上線的場景,來進行說明.

面向服務的運維平臺,首先需要構建底層資源的 IaaS 化,API 化.有了 IaaS化,我們就具備了提供一個一站式的運維平臺的基礎能力.在這樣的運維平臺上,業務上線需要數據庫資源,平臺提供對應的實例配置套餐,一鍵創建并返回給用戶.

同樣,制定一套標準的發布規范,實現自動化部署,業務在發布的時候,從 IaaS 資源池自動分配服務器.其他的資源,如 CDN,域名解析等,同樣可以在平臺上自助完成.

這樣,業務上線的流程,全部以自動化,自助的方式完成.再往前,平臺與持續集成,自動化測試平臺進行對接,即可完成自動化測試,并根據自動化測試結果來決定是否進行發布.

這里面主要是以 DevOps 的理念來構建運維平臺,這個方式也是我們的實踐方式,后續內容將詳細描述.

3. “拿來主義”

1. 公有云平臺公有云平臺提供了完備的基礎資源和強大的功能特性,且具體完善的 API,一般創業公司完全可以基于公有云平臺進行運維平臺化管理,無需自己再去開發一套運維管理平臺,也沒有能力去開發.不過一旦公司做大,考慮到單一供應商的風險,勢必考慮至少兩家云平臺的資源,甚至可能還存在自有數據中心,這樣就面臨著混合云管理需求.
2. ITSM 商業軟件
   在云計算和 DevOps 驅動下,當前也有商業的ITSM 管理軟件,提供一站式運維管理平臺軟件或者服務,而不是提供離散的 ITSM 管理套件.這類軟件,在互聯網+的時代,對于傳統行業的 IT 部門轉型升級會非常有幫助.

三、 YY互娛 – PaaS 運維平臺理念和實踐

業務場景

YY 互娛在這幾年處于高速發展的過程,即要穩固拓展 PC 端的市場,又需要在移動端尋求突破,業務場景：

1. 快速試錯

互聯網時代競爭激烈,特別是移動互聯網時代,誰能快速推出產品,快速迭代,誰就能在市場上占得先機.快速試錯是一種常見的競爭手段.PaaS 平臺的業務交付運行模式,最大特點就是效率高,成本低,可以很好的滿足快速試錯的業務需求.

2. 人力不足

長期以來,互聯網企業在運維方面的人力投入是不夠的,很多時候是扮演的救火員的角色,PaaS 在平臺層面提供一站式運維服務,高可用架構質量保障,減少業務上線對運維人員的依賴,在不需要運維人員介入,開發人員自己就可以上線業務,并持續迭代.

基于 IaaS 的 PaaS 平臺,將硬件環境與軟件環境進行了解耦,也降低了硬件故障對線上業務的影響,釋放了運維自身的壓力.

3. 成本壓力

業務上線需求多,如果按傳統的方式提供物理資源,對資源的需求量極大,而業務的訪問量,生命周期不可預測,造成硬件資源利用率低.很多時候通過混合部署業務,提高硬件資源利用率,造成后期維護成本非常高.

平臺理念

基于上面的業務場景,以及云計算的大背景,YY 互娛技術團隊基于 OpenStack ,推出自己的 IaaS平臺,主要面向游戲業務的云計算平臺.基于 IaaS能力,逐步構建自己的PaaS平臺.

我們的平臺理念是：運維技術服務化,轉化為生產力.平臺提供高可用高性能高質量的基礎架構服務,滿足業務的快速交付.平臺提供一系列的工具,組件,來支撐開發人員自助式運維.

開發人員只要使用平臺,無需找到運維人員,就能應用運維的能力,如高可用,彈性伸縮,配置管理,容災備份等能力,達到 NoOps 的目的,減少開發、運維不必要的溝通成本,使開發人員專注于業務開發.

執行 DeoOps 理念,平臺將開發、測試,運維流程自動化打通,將持續集成,自動化測試的能力以服務化的方式輸出到平臺.最終,將業務價值交付涉及的各種能力,通過平臺輸出到業務,達到技術服務轉化為生產力的目標.

實踐歷程

1. 整體架構

PaaS運維平臺的整體架構：

兩種顏色代表兩個視圖,藍色部分代表從業務維度的視圖,即從PaaS平臺用戶的維度看到的架構.灰色部分代表從運維自身的視圖,即運維全局的視圖.

從業務維度的視圖,大概分為4層,從下而上,面向服務,包括硬件層,IaaS,PaaS和業務層.

從運維自身的視圖,包括全局資源中心,監控中心,數據源中心,報表中心,安全體系等.

接下來的篇幅,主要把面向業務的各個核心組件及實踐做介紹.

2. 標準化

標準化是運維自動化的基礎,PaaS 平臺的標準將以系統化,自動化的方式落地.
標準化主要包括這些規范：

• 基礎應用軟件規范(Nginx,Resin,Tomcat等)
• 應用程序打包規范(Java,PHP)
• 應用程序部署規范
• 監控規范
• 其他

以上規范,全部落地到PaaS 平臺的各個子系統,由子系統自動化完成.比如對VM 環境的標準化,通過 VM 鏡像方式交付.

3. IaaS

我們的 IaaS 層提供了以下服務,來滿足我們的應用上線.

• 計算虛擬化
  計算虛擬化部分,我們這里使用 VM,將 VM 作為我們容器計算的最小單元.當前使用 OpenStack 開源實現方案,使用 KVM 做 hypervisor.提供各類 VM 套餐滿足不同業務場景.計算能力擴展我們采取的 VM 的橫向擴展,即 ScalingOut,后面章節會介紹.
• 存儲虛擬化
  考慮到性能問題,我們VM使用了本地存儲.沒有使用 Ceph分布式存儲.
  對象存儲上,對接了公司提供的基礎服務.
• 網絡虛擬化
  網絡部分,采用了Neutron Provider Network,未實現 VPC 網絡隔離.
• 數據源
  • 數據源我們提供了3類數據源,Mysql,Redis,Memcached.這3類資源是平臺上使用最頻繁的組件.我們以單物理機多實例的方式運行,未主動采用 cgroup 進行資源隔離.這些插件在被創建的時候會自動添加監控,用戶可以在平臺查看相關監控狀態信息.
  • 插件平臺.上述基礎組件以插件方式與平臺整合,類似于 Heroku 的 Addons服務.

具體業務流程描述如下：

• 插件注冊：插件開發者將自己開發的插件接入插件平臺.
• 獲取插件：PaaS 平臺的項目用戶請求插件平臺,獲取插件授權信息.
• 返回授權：插件平臺將來自 PaaS 平臺的請求轉發到具體的插件,獲取具體插件的地址,授權等信息,并將信息存儲在插件平臺然后返回給PaaS 平臺.比如 Mysql 實例,返回域名,端口,賬號,密碼.
• 插件注入容器： 項目模塊發布的時候,由CloudRouter 從 PaaS 平臺上獲取插件信息并將相關信息注冊到業務容器環境變量.關于 CloudRouter 的功能,后續會詳細描述.
• 容器訪問插件：業務容器從環境變量中獲取到的插件信息,直接請求具體的插件.插件平臺的引入,增強了PaaS平臺的開放性和靈活性,項目所需的所有基礎組件,不需要 PaaS 平臺自己提供,可以由公司其他開發同事提供.插件平臺面向公司內部所有開發人員,設置了一定的運營策略,如貢獻率,引用量,收獲贊等,并與公司的績效積分,技術職級評定做一定關聯.
• 
• 其他資源
  其他基礎服務,我們同時提供了 CDN,消息隊列等.
  CDN 是使用第三方廠商基礎服務,通過 API對接,實現一鍵創建 CDN 服務.消息隊列服務底層采用了 RabbitMQ集群.
  同樣,這些資源也以插件方式整合到平臺.

4. 持續交付

基于上面的 IaaS 層,我們有了構建 PaaS 的基礎能力,來解決持續交付的問題.我們從以下幾個方面來描述

• 交付模型

交付模型,指在我們的 PaaS 平臺上的業務,構建一個業務的模型.這個模型也是基于我們的應用程序打包規范來做的.這里再簡單描述下：

• PaaS 平臺業務交付的對象包括：人, 項目,模塊.
• 人即項目管理員,一個人可以管理多個項目,一個項目也可能是多個人管理.

項目對應的是一個業務,一個項目又分多個模塊,每個模塊就是一個獨立的部署單元；模塊一般是按功能進行劃分,比如最常見,一個項目有 admin 模塊,user 模塊.我們的PaaS平臺的部署操作最小單元是項目的模塊.以 Java 應用為例,模塊的類型有 War和Jar.不同類型對應不同的部署動作.

• 項目管理

項目的管理包括項目的新建,以及用戶權限管理,屬性管理.需要的基礎信息包括：項目 代碼庫地址,項目成員等等.
項目管理中涉及的信息

• 持續集成
  以Java 項目為列,我們約定在 pom.xml 根據模塊名稱打包成對應類型的包.并自動創建對應的項目模塊,打好的程序包上傳到分布式文件系統(DFS).實現只要將代碼提交到版本庫,即可一鍵打包發布.在我們的現實情況中,并沒有對每一個項目要求持續集成,而是選擇性的,其中的原因是：
  • 大部分項目都是小型項目,不涉及多人協同開發,這樣的場景下不涉及到復雜的持續集成場景.
  • 小步快跑.本身項目的迭代速度比較快,集成頻率比較高,一般不會出現持續集成不通過導致需要花費大量精力解決集成失敗的問題.

• 持續測試
  PaaS 平臺與自動化測試平臺進行對接,在基礎信息上同步共享,包括項目名稱,項目成員,版本庫地址等.持續測試的實踐經驗是：
  • 業務分級.對核心項目進行嚴格的持續測試,包括單元測試,QA 自動化測試.對非核心項目,默認不進行測試.是否測試的權限交給項目管理員,項目管理員一般都是開發團隊的 Leader.
  • 風險控制.在實際的運作中,測試能發現的問題是有限的,需要考慮一旦出現問題的補救措施.因此,對于核心的業務系統,引入風險監控,降低 bug 的影響范圍.
• 持續部署
  持續部署中,涉及到如下幾個問題,我們的解決方案是：
  • 數據源.項目所需的數據源(Mysql,Redis)實例,用戶在平臺上一鍵創建,然后通過環境變量的方式注入到業務容器.具體流程見前面章節“插件平臺”所描述.
  • 配置管理.包括運行環境的管理,JVM 參數定制,Nginx 參數定制,域名配置,證書配置等,這類配置全部在平臺,由用戶自助或系統自動化完成.
  • 發布.涉及“包版本”發布審批,服務器資源自動分配,“配置管理“中涉及的各項配置應用到相關組件.
  • 回滾.平臺支持包版本快速回滾.
• 持續反饋
  • 基礎資源監控及監控數據展示
  • 運行維護
  • 業務可用性監控和數據展示上述三點在后面的章節詳細說明

5. 高可用架構

平臺架構高可用設計,從最上層的攻擊防御,到數據持久化層,全部提供高可用方案.業務只要接入平臺,就具備全部的能力..

• 云防DDOS,接入公司層安全中心的DDOS 防火墻,保障業務安全.
• GSLB,平臺提供多機房,多鏈路接入的能力.項目域名自動解析到多個機房,提供就近接入的能力.
• OSPF-LVS,四層負載均衡采用OSPF-LVS 架構,具備平滑的水平擴展的能力.

• AppRouter 應用路由層,Nginx提供七層的路由轉發,同樣具備平滑的水平擴展能力.
• Container,應用邏輯層.這一層是項目級別的配置.提供 Nginx+容器(Tomcat,Resin,PHP-FPM)環境.這一層引入 Nginx,是考慮到部分七層業務邏輯控制,交由項目級別的控制,不至于每次項目級別的變更,而影響上一層AppRouter 全局層面的變更.這一層具備彈性伸縮的能力,后續章節具體講解彈性能力實現方式.
• Cache 層,提供純 Cache 和數據型 Cache.這一層我們主要是使用的 Redis,以域名和端口的方式對外暴露,通過域名切換,具備故障切換的能力.
• DB數據持久化.這一層目前對于所有業務實例,默認提供帶主從的實例對,業務發生故障時,需要根據業務場景對數據一致性要求情況,進行故障切換.這一層當前未引入開源類似 MHA,MMM 等架構,而是通過域名切換的方式來實現,這里面參考了 AWS 的實現方法.我們的架構一般都是 MM 架構,當主節點發生 Down 機后,域名切換到從實例,Master 恢復后,只要修復主從關系即可.對于高并發訪問量的業務,需要一主多從,或者 Mysql 環形復制場景,這些需要根據業務特性做一些人工介入.

6. 彈性擴展

• 彈性
  彈性是 PaaS 平臺的基本能力,彈性技術的好處有：
  • 高性能：在業務訪問規模上去時,服務器自動增加,保證性能
  • 經濟性：在業務規模降低時,自動收縮服務器,節省成本
  • 高可用：如果有服務器宕機,自動進行故障隔離
  • 平滑部署：實現熱部署,不影響現有業務運行彈性伸縮提供包括動態伸縮,熱部署,故障隔離三層含義.彈性示意(圖十四)

我們的彈性技術是由CloudRouter 和 CloudMonitor,資源池3個部分組成.架構：

• CloudRouter是核心組件,是彈性調度的大腦,在用戶的任務,資源分配中間起核心的調度協調的作用.
• CloudMonitor 負責項目服務器的狀態數據收集,并提供接口供 CloudRouter 查詢狀態.
• 資源池是基于預創建的可用資源緩沖池.這里主要是指 VM 資源.VM 資源又分為多種配置,對于每種配置的資源,可在后臺配置預先創建一定的數量.一旦服務需要資源,可立刻從池里獲取.
• 彈性的策略. 當前我們的彈性策略是模塊的所有 VM 的負載平均值.當負載平均值大于我們們指定的彈性閥值,則進行擴展,可設置每次擴展的服務器數量.同樣,當平均值小于我們指定的閥值,則進行縮減.

在實際的業務場景中,可能有些業務是內部小型項目,不需要進行彈性,是否彈性是一個可選項.另外,還有一些項目,可能無法滿足無狀態的設計要求,不希望每次部署都更換服務器,我們也提供了在部署的時候,選擇“就地部署”,就地部署的意思就是每次部署都使用同樣的服務器.彈性調度策略配置：

7. NoOps

• 自主運維

平臺提供一系列日常運維管理工具,包括常見的服務器性能查詢,日志查詢,應用分析工具,數據源相關信息查詢.大多數場景下,開發人員無需登錄服務器.

• 日志管理
  日志管理方面,我們提供了兩種方式
  • 文本日志.我們在每臺vm上通過 Rsyslog 進程收集業務進程日志發到集中日志服務器.在集中日志服務器端,我們按項目名稱存儲,一個項目一個日志目錄.日志目錄權限管理,我們使用Linux 用戶組權限設置,只有具備PaaS 平臺項目管理權限的用戶,才能查看該項目下的日志.
  • Web 日志分析.PaaS 平臺對接了公司級的 Web 日志分析系統,能夠實時展示項目域名的日志訪問量,帶寬流量,請求狀態等情況.
• 監控
  平臺監控主要是基于 Zabbix 做了一些 API 層面的定制開發,我們內部稱之的為“CloudMonitor“.主要包括以下三個方面功能：
  • 基礎監控
    VM:基礎監控包括 CPU,內存,磁盤 IOUtils,磁盤空間使用率,網絡流量,TCP鏈接數,進程數等.監控信息如圖：
    
  • 數據源：對 Mysql,Redis,Memcached 常規指標做了監控.
    自定義監控.支持 TCP,DNS,PING,HTTP,支持自定義告警條件和策略.如圖：
    
  • 告警.平臺告警由 CloudMonitor 組件負責,支持多種方式告警.CloudMonitor 組件是在Zabbix 的事件接口上,定期獲取事件,按業務維度進行匯總分析發送給業務開發負責人和運維負責人.做了一定程度的事件聚合,比如宿主機 Down 機,宿主機上的 vm 相關信息關聯起來,從業務開發負責人看：某 vm Down 機是由于某宿主機引起；從運維層面看,某宿主機 Down,影響了這些 vm,這些 vm 運行了這些業務.
• 工具組件
  在自助運維場景中,開發人員需要對項目 ,域名,IP 信息進行查詢,平臺提供相應的工具.
• 可用性反饋
  平臺的可用性反饋,主要是對平臺各個層面的服務可用性,進行系統化,自動化評估.這里主要介紹下我們的業務的可用性度量實踐方法.
  我們稱為“Monitor.X監控規范”具體描述如下：
  • X代表語言.(注：若是 PHP 項目,文件后綴為 monitor.php；若為 node.js,則文件名為,monitor.js).
  • 路徑要求：url規則為http://項目域名/monitor/monitor.X)項目域名取配置管理里面,設置域名框中,去掉 包括 test 字符串后的第一個域名.
  • 輸入參數：接口不用輸入參數.
  • 輸出說明：接口輸出只分為兩種,正常和不正常.
  • 正常：狀態碼為200,且輸出包括字符串“200”
  • 非正常：狀態碼200或者非200,且輸出字符串不包括200. (可以用作錯誤提示內容).
  • 對于狀態碼200,同時信息也包括200字符串,但是實際是服務不可用的情況,需要程序員特殊處理返回信息.
  • 接口內部實現要求：要覆蓋系統的核心業務邏輯(業務自身把握)；有多個業務邏輯時,也是統一在一個接口返回(調用順序由業務控制).

業務在PaaS 平臺發布,平臺將自動加上項目的 Monitor.X 監控,根據 Monitor.X 的狀態,來衡量業務是否可用.可用性反饋如圖：

8. 安全審計

所有操作包括打包,配置,部署,日常運維等操作全部收攏在PaaS平臺上,每一個用戶在平臺的的所有操作都有記錄,可追蹤.

對于核心項目的數據變更類的操作,引入運維審批.

9. 平臺運營

雙向反饋
構建平臺用戶反饋溝通群組,第一時間接受響應用戶的需求,重視“客戶滿意度”,并將客戶反饋的問題,由專人進行收集匯總,每周發出平臺質量問題周報,并組織開發運維力量,集中有效解決用戶反饋的問題.這些問題,有技術性的,流程性的和體驗性的,用戶每一個問題的交互過程,通過溝通群傳達給平臺每一個用戶.

體驗優化
長期以來,在面向技術人員的系統 UI設計,用戶體驗是不好的,內部技術平臺首要解決的是可用性問題.PaaS 平臺需重視用戶的體驗,體驗好也才能實現我們的 NoOps 的理念.試想一下,如果我們做了一個自己覺得很厲害的功能,而用戶覺得不好用而棄用,那做的可能就是無用功.

也許有種擔心,我們已經把所有的用戶放在一個群里面,任何一個細節問題,體驗問題,都會讓所有用戶知曉,平臺維護者比較被動.我們的經驗是,在 DevOps 文化下,平臺的建設者(運維團隊),平臺的使用者(開發團隊),都有面向業務最終用戶價值交付的共同目標,都將以合作,包容的心態,共同推動平臺的進步.

平臺收益

平臺收益情況,從四個方面表述,如圖所示

• 質量
  基礎組件平臺保障高可用,故障自動隔離.應用容器彈性伸縮,確保在業務變化中得到穩定的服務質量.平臺提供自動化可用性管理方案,對業務質量形成有效反饋.
• 效率
  執行 DevOps 理念,將研發,測試,運維全流程以自動化的方式整合,實現業務的快速交付.提供豐富的自助運維工具,系統,滿足開發自助式運維需求,提高日常維護的效率.
• 安全
  在網絡安全和系統安全上,接入公司級安全體系,包括云防 DDOS,主機基線安全,主機漏洞檢測,應用層引入公司的 WAF模塊.在數據安全和 D/O 權限分離上,平臺隔離開發人員登陸生產環境和生產數據庫的權限,所有權限全部收攏在平臺上,變更類操作自動引入工單,由運維介入審批.所有操作記錄可跟蹤.
• 成本
  通過 IaaS 層的計算虛擬化,資源池,彈性伸縮等技術手段,提高系統資源利用率,減少硬件資源采購.通過自動化的技術手段,減少人力資源的投入一站式的運維管理服務平臺,大大減少人員流動導致項目的交接成本,降低人力成本.

平臺風險

PaaS 平臺的風險,如圖所示

????1. 容量管理

PaaS 平臺的資源交付是完全自助的,不需要運維人員介入審批,IaaS 層的資源容量是有限的,因此,從接入層,應用層,IaaS 層,構建全面的自動化容量評估系統,顯得尤為重要.需要關注幾個點：

• 資源調度
  IaaS 層的資源調度器,一般都是靜態的調度策略,是基于資源創建時間點來選取一臺最優的節點進行資源新增.一般來說,我們的調度策略都會有一定的超額比例.但隨著業務的發展,某些節點的負載會比較高,甚至出現資源不足導致系統宕機.
  對于計算節點,我們有彈性擴展來保證業務可用性.但對于數據庫如 Mysql,如果出現宕機,對業務影響非常大,一個 Mysql 宿主機,可能運行10個以上的實例,一次宕機影響幾十個業務.
• 容量預警
  對各類資源設置一個預警閥值是非常重要的.比如對于 Mysql 數據源,我們主要關注的是內存的分配,那么預警閥值=(已經分配內存)/總的可分配內存*100%,這個閥值隨著資源池越大,可以調得越大.
• 容量預測
  定期發布容量預測報告.如對計算資源來說,定期自動預測不同類型的套餐可創建的數量.同時,還需構建基于一段時間的趨勢預測,以便及時發現平臺資源容量突變情況.

????2. 隔離性

• 資源隔離
  私有 PaaS平臺,對 IaaS層資源,一般都是沒有做資源隔離的.比如,像 Mysql 這種多線程的應用,單機跑多個實例,可能一個業務異常 SQL,就會耗盡宿主機的所有CPU資源而影響其他業務.因此,對于業務實例的質量分析,主動發現實例的質量變化,并及早介入優化,顯得尤為中重要.

從我們的經驗看,大部分的 SQL,只需簡單的索引即可得到明顯優化.而這些 SQL 優化,只要能及時讓開發人員知道,他們就有能力去優化,或者更近一步,質量分析平臺能自動生成優化的 SQL,自動推送給開發人員進行優化,或者再近一步,把優化的 SQL 應用到數據實例,并通知用戶執行結果.

• 網絡隔離
  當前我們的IaaS 層未實現 VPC 網絡,網絡上不具備隔離性.這是我們當前正在改進的方面.

YY互娛- PaaS 運維平臺未來規化

1. 面向業務/運維的一站式平臺

增強平臺的一站式運維管理的能力,包括容量評估,管理,預測,質量分析,成本分析,容災切換等.如圖所示

2. 多語言支持
支持 Task,Node.JS,Python等語言.
支持資源編排.

??3. 自動化、數據化、可視化、產品化

進一步提升自動化,包括IT運營分析,容量評估預測,容災備份切換等.
將運維的各項能力數據化,并進一步可視化出來.
產品化,提升用戶體驗.
如圖所示：

?4. 業務運行于VDC

YY 互娛技術團隊當前推出自主研發實現 SDN,SDC,SDS 的云計算平臺, 初步具備了SDDC 的能力,我們把 SDDC,稱之為 VDC(Vistual Data Center).

在 SDN上采取軟硬結合的方案,在硬件交換機上實現了基于 VxLAN技術的VPC網絡數據包的封裝和解封.下一步,我們將構建基于VPC的 PaaS 運維平臺.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4356.html