微博:春節日活躍用戶超一億,探秘如何實現服務器分鐘級擴容
摘要
每逢重要節日,微博流量會出現暴漲,2016年春晚,微博日活躍用戶達到1.34億,比去年除夕增長31%。在如此大訪問量的情況下,后端服務的穩定性和性能保障任務艱巨。本次重點分享微博利用阿里云實現分鐘級服務器規模成倍擴容的技術體系。
3月30日云棲社區在線實時分享順利結束,本次由微博研發中心技術經理及高級技術專家陳飛分享了微博利用阿里云實現分鐘級服務器規模成倍擴容的技術體系,包括Docker與虛機結合的使用經驗、網絡架構以及負載均衡、緩存架構的跨IDC服務部署的一些經驗。本次視頻直播的整理文章、視頻、幻燈片整理完畢,如下內容。
DCP設計“初心”
圖一 DCP設計初心
DCP是微博容器化的混合云彈性調度運維平臺,其誕生初衷是以最低成本實現彈性能力。DCP系統對外提供的功能包括集群管理、服務池之間的調度。目前使用DCP系統的業務方涵蓋微博的核心業務,主要包括微博平臺、紅包飛、手機微博等。
DCP最初的設計目標主要有三點:
- 要具有彈性能力,當時預估在春晚峰值時,需要10分鐘16000核,25600GB的計算資源彈性能力;
- 能夠節約成本,設計之時希望2016年春晚的總體成本不超過2015年,且通過阿里云等公有云按需付費模式,未來可大幅降低單位成本;
- 能提供一個標準的技術平臺,拉通不同語言、運行環境差異,向微博各個業務系統提供標準的彈性能力。
DCP混合云架構設計
圖二 DCP混合云架構設計原則
當具體去設計這樣一個系統架構時,由于涉及到不同的業務方、不同的部門,各個環節協調還是比較復雜的。因此在架構設計時必須遵循幾個具體的原則。
- 在使用公有云時,不僅要單單使用公有云,要將公有云和專有云結合使用,最大程度利用公有云按需付費的特點,降低單位成本,例如在2016年春晚,微博與阿里云合作,在流量峰值到來的前幾個小時才部署了相應的公有云資源。同時業務需要在公有云與專有云之間無差異化部署;
- 服務化,系統各組件之間通過Restful API而不是原來的運維干預方式進行通信。這里要求各組件應具有良好的擴展性,實現機制可插拔;
- 可伸縮,各系統組件可以根據管理集群的規模,實現自身的自動伸縮。各組件應無狀態、無單點。運維操作自動化。
圖三 DCP架構分層
DCP架構具體分為四層。第一層是不可變基礎設施,Docker的出現很大程度上改變了原有的運維方式,下文將具體介紹在容器化、系統初始化、鏡像分發、帶寬監控方面的實踐經驗。第二層主要完成彈性調度,包括業務跨云調度、調度機制的建立、容量評估。在已有基礎設施資源前提下,動態合理的分配給各個業務節點。第三層主要完成服務發現,在業務彈性部署后,調用方需要快速發現服務集群分布的節點,通過配置中心、負載均衡、RPC協同快速實現發現機制。第四層主要完成容器編排,包括自動擴容和監控報警。
圖四 DCP整體架構
上面這張圖是DCP整體架構。架構的最下層是私有云和阿里云的計算資源。各個系統之間通過API相互通信,利用阿里云的Open API動態創建所需的計算節點。再上一層是基礎設施管理系統,負責虛機的創建、鏡像的分發等服務抽象和實現,對外提供和專有云相同的計算環境。再上一層通過Swarm、Mesos實現了業務容器動態調度框架。最上面一層是業務系統。最左邊是一套服務發現框架,該框架是基于Consul集群建立配置中心,實現服務發現機制。
接下來,對各個層的實現進行詳細剖析。
不可變基礎設施
微博在15年春晚就開始嘗試Docker技術,當時目的是讓業務與宿主機的運行環境解耦。Docker解決了業務對運行軟件的版本、組件需求,將這些依賴關系封裝到Docker Image中,統一了私有云、公有云之間及不同業務線之間的交互標準。
圖五 容器化
DCP對業務層提供了十分標準的基礎運行環境。底層選用ECS的CentOS7.1.1503的鏡像,在此之上是Docker的Devicemapper-direct-lvm文件承接系統,版本選擇是Docker 1.6.2版本。中間層是調度框架的實現,使用的是Mesos 0.25和Swarm 1.0.0版本,以及一些容器級別的監控,如貢獻給開源社區的cAdvisor 0.7.1.fix。PHP和Java對應不同的后端應用,微博的核心Feed、用戶關系等基礎服務都是用Java實現,偏業務性的系統是用PHP來實現。對應于Java和PHP的Docker體系是一致的,只是其中使用的版本不同,在Docker 1.3.2版本中需要兼容一些離線計算平臺。目前Java和PHP底層運行環境已經實現歸一化。
圖六 初始化
有了容器化的無差異運行環境之后,在阿里云上分鐘級完成上千個計算節點的彈性擴容還需要進行性能優化。首先各Stage盡可能并行化,目前可實現4分鐘內初始化上百臺能力。同時通過Ansible的Callback機制,把耗時操作異步化。此外,使用Ansible自動伸縮功能,根據初始化需求規模自動伸縮,可支持分鐘內千萬級別初始化能力。
圖七 鏡像分發
在Docker環境和云服務器計算資源準備充分之后,之后的工作就是將業務鏡像進行快速部署。由于單個鏡像的大小在GB級別,如果采用動態拉取的方式,需要幾百臺云服務器專門做這個任務,大大增加了擴容成本。
微博將整個鏡像進行分層,不變基礎鏡像放到云服務鏡像環境里面,通過本地Load方式實現鏡像的加載,大大減少了鏡像分發的帶寬需求,同時速度也有一定的提升;另外的一種操作就是反向緩存,突然之間在公有云上大規模彈性擴容時會面臨冷啟動的問題,即公有云上不存在相應的業務鏡像,拉去業務變更的鏡像會占用大量專線帶寬。為了應對這種情況,在公有云上常態化部署對專有云Registry反向緩存,對專有云Registry內部變更和推送、配置都會同步到公有云的反向緩存節點上。此外也實現分發網絡可自動伸縮。未來應對超過千萬級別規模,微博正在嘗試采用P2P進行分發。
圖八 混合云網絡架構
在混合云中,最核心的就是整個網絡架構。打通公有云和私有云時,網絡環境、IP規劃等問題都應該慎重考慮。目前微博采用阿里云的專有網絡服務,構建公有云與專有云一致的網絡環境。另外,采用多專線確保網絡高可用。路由方面,通過在核心交換上配置路由轉發規則,采用就近原則,最大程度減少路由跳數,保證網絡低延遲,當網絡故障時,自動啟動備份路由。
同時基于原有的帶寬監控,實現跨云專線監控,細化到IP級別,根據每臺云服務器的IP自動匯聚到對應的產品線,監控其整體帶寬消耗情況,確保各個業務產品線實際單寬占用不會影響。
彈性調度
不可變基礎設施的部署完成后,就已經具備了在公有云上創建大規模 云服務器 計算節點的能力。接下來面臨的問題就是如何將業務合理調度到計算節點上。
圖九 業務跨云彈性調度
跨云業務部署時,應該使得業務以最小規模部署,在公有云上通過預付費方式,常態化部署業務的最小規模,并提供在線服務。另外應該盡量減少跨云專線的調用,保持帶寬在可控范圍之內,需要將業務后端資源Memory Cache等Loacl化,減少跨專線請求;一旦發生跨專線請求時,需要開啟一些流量壓縮的協議。同時,微博內部通過WMB緩存數據雙向同步機制,基于消息分發策略,在專有云內部對緩存的讀寫以消息的方式同步到公有云的緩存上,延遲一般在毫秒級,同時在專線出現異常時,消息不會丟失,做到高可用。
圖十 業務混合云部署形態
上圖是2016年春晚上典型的業務混合云部署形態。內部是典型的后端互聯網服務技術站,通過四層的負載,通過Nginx實現七層負載,再往后是一些WEB層的計算和RPC服務,最下面是緩存層的資源、數據庫。由于數據庫的請求量和數據安全要求比較高,因此暫時沒有將DB層放到公有云上。架構的最右側是采用了負載均衡服務、之下的RPC、WEB、Nginx都是部署在 云服務器 上的。
圖十一 彈性調度機制
在具體的彈性調度框架上采用了開源的解決方案,例如Swarm、Mesos等。在它們的基礎上封裝了統一調度的API,將原來專有云內分散的各個應用平臺統一到一起,大大節省在基礎運維上的時間成本。
圖十二容量評估
通過在線容量評估,決策某一個服務是否需要在公有云上擴容。通過選取服務的多個業務上的指標來綜合評價某一個業務是否存在流量突增或者性能的瓶頸。比如采集平均響應時間和QPS、內部計算資源線程池,最終計算出總體資源池的冗余百分比,用于決策是否需要動態擴容。
編排與容器發現
業務部署到阿里云之后,需要快速地將業務提供方與調用方快速地銜接起來,就需要編排和容器發現的機制。
圖十三 業務容器編排
在實現DCP系統環節內部可能存在微博內部其他的系統,比如原有的運維系統、發布系統、監控系統等等。這些原有的系統內部需要打通,這也是業務編排的核心任務。另外一個問題就是實現自動化,擴容一臺完整的微博后端業務大概需要上百步的操作,通過自動化操作避免了數據不一致問題的出現。還有一些服務發現的機制,原來通過管理員配置的服務發現機制對上千規模的彈性業務節點管理起來成本較高。
圖十四 自動擴縮容
上面這張圖是微博自動擴容的具體流程。首先預測流量到來時,向DCP系統發出指令進行擴容。DCP平臺首先向共享池或公有云申請資源,進行資源配額模塊后,在經過初始化,進入調度中心。在調度中心中根據服務之間的依賴關系,在公有云上啟動該服務,比如需要先啟動緩存的服務,才能再啟動RPC服務,再啟動WEB前端的服務,最后再啟動應用的PHP服務。服務啟動后需要向Consul集群進行服務注冊和服務健康的檢查。
圖十五 服務發現
對于服務發現,業界通用服務發現機制是基于Nginx Reload本地文件來實現服務發現。這種服務發現實現管理成本高,并且不支持并發注冊,會帶來性能損耗。目前微博采用基于Consul配置中心實現自動發現服務,解決了Reload的性能問題。
圖十六 資源的自動發現
對于資源的動態發現,原有的方式是將后端緩存、Redis等資源的配置放在配置框架中進行,在增加阿里云RDC時會導致配置文件快速膨脹。現在,微博采用將配置同步到Consul集群的方式,通過域名動態解析阿里云上資源IP變更,無需變更業務代碼,對整體的彈性伸縮帶來了很大的便利。
來自:https://yq.aliyun.com/product/318