新浪微博基于混合云的php服務(wù)化與彈性擴(kuò)容

原創(chuàng)
作者：侯青龍 2017-06-14 08:47:04

開發(fā)

架構(gòu)

混合云 本文由在新浪微博工作近七年、現(xiàn)任主站研發(fā)負(fù)責(zé)人的侯青龍分享新時代下的LNMP架構(gòu)，基于混合云平臺的PHP彈性擴(kuò)容部署方案，以及具體維護(hù)過程中遇到的挑戰(zhàn)。

創(chuàng)新互聯(lián)是一家專業(yè)提供無為企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、html5、小程序制作等業(yè)務(wù)。10年已為無為眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

【51CTO.com原創(chuàng)稿件】從后端來講，新浪微博可以分為Java和LNMP兩大體系，特別是在LNMP方面積累了很多經(jīng)驗。發(fā)展初期，新浪微博側(cè)重從性能角度出發(fā)，做架構(gòu)方面的調(diào)整和優(yōu)化。近兩年，它投入人力、物力，把重點放在了彈性擴(kuò)容方面。

本文由在新浪微博工作近七年、現(xiàn)任主站研發(fā)負(fù)責(zé)人的侯青龍分享新時代下的 LNMP 架構(gòu)，基于混合云平臺的 PHP 彈性擴(kuò)容部署方案，以及具體維護(hù)過程中遇到的挑戰(zhàn)。

新浪微博遭遇流量峰值挑戰(zhàn)

新浪微博作為社交產(chǎn)品，經(jīng)常出現(xiàn)因某些原因所致的話題突發(fā)流量峰值，且峰值不可預(yù)估。例如：

• 緊急突發(fā)事件：白百合出軌、周一見、寶寶離婚、女排奪冠

• 大型活動及三節(jié)保障：紅包飛

• Push 推送：運營的各種站內(nèi)，站外 push

話題業(yè)務(wù)的流量特點

話題業(yè)務(wù)的特點是平時流量比較平穩(wěn)，波動很小，一旦出現(xiàn)突發(fā)事件，10 分鐘時間流量就會突增 2-3 倍。像這樣的流量，一般持續(xù)時間不會長，約 1 個小時左右。

從架構(gòu)角度，如何處理？

新浪微博在做架構(gòu)調(diào)整之前，和很多公司的處理方案都相似，采用設(shè)備冗余與服務(wù)降級兩大傳統(tǒng)手段。

設(shè)備冗余。各業(yè)務(wù)提前申請足夠的設(shè)備保證冗余，正常情況下一臺服務(wù)器 CPU 約在 20%-30% 左右，當(dāng)峰值到來會達(dá)到 60%-70%，系統(tǒng)就會嚴(yán)重警告，需要做服務(wù)器擴(kuò)容。一般情況下，系統(tǒng)會準(zhǔn)備一倍左右的冗余。但這就存在一個問題，流量如果翻三倍、四倍怎么辦？

服務(wù)降級。當(dāng)突發(fā)流量峰值，系統(tǒng)將對非核心業(yè)務(wù)以及周邊業(yè)務(wù)進(jìn)行降級，PC 主站只保留主 feed。內(nèi)部降級的方式有很多，降級后用戶基本感覺不到。如極端情況下，系統(tǒng)一定主要保留微博主站，其他功能模塊全下線，進(jìn)而保證服務(wù)不會掛掉。

但從公司、老板層面，肯定不愿意出現(xiàn)這樣的情況，因為降級對廣告的影響很大。但是在傳統(tǒng)架構(gòu)下，面對突然產(chǎn)生的流量，技術(shù)只能這樣做。

這兩種傳統(tǒng)手段，面臨一系列的擴(kuò)容和降級難題：

• 設(shè)備申請周期長。如機(jī)房從其他業(yè)務(wù)挪用服務(wù)器，周期不會太長。但每年三節(jié)都會對常規(guī)流量進(jìn)行預(yù)估，做好幾倍擴(kuò)容。假設(shè)機(jī)器不夠，會發(fā)起采購，但周期會非常長。

• 擴(kuò)縮容繁瑣。如下圖，當(dāng)服務(wù)器到位，做擴(kuò)容，又是一個繁瑣流程，還需要多部門共同合作。

• 設(shè)備運營成本高。如每個業(yè)務(wù)都做一定的冗余，假設(shè)一百臺服務(wù)器，要用二百臺來保證正常運營，可以想象這個成本會非常高。舉例，PC 和手機(jī)端，業(yè)務(wù)峰值不在一個點，峰值不在一起，利用率也有所差別，就算同一事件，每個業(yè)務(wù)的負(fù)載也會不一。

  業(yè)務(wù)之間拆借，也是行不通。因為短時間內(nèi)，無法應(yīng)對服務(wù)器之間的環(huán)境差異、代碼等差異，初始化完畢，峰值也消失了。

綜上所述，擴(kuò)容和峰值是面對突發(fā)流量峰值的兩個解決維度，但存在的問題是擴(kuò)容不能針對服務(wù)器快速擴(kuò)容、降級又對服務(wù)器損害相對較大。

新浪微博決定從架構(gòu)層面解決這兩個問題，通過引入混合云 DCP 平臺，達(dá)到下面的效果：

• 降低設(shè)備運營成本。不希望為冗余準(zhǔn)備的大量設(shè)備，一年中的很多時間空閑。

• 實現(xiàn)業(yè)務(wù)彈性擴(kuò)容。各個業(yè)務(wù)之間峰值不一樣，可通過技術(shù)把環(huán)境抹平，實現(xiàn)隨時化的自由調(diào)度。

新浪微博混合云DCP平臺簡介

DCP（Docker Container Platform）平臺解決思路是從業(yè)務(wù)的彈性角度，在各業(yè)務(wù)之間，無論是 Java 還是 PHP 等，通過抹平所有的環(huán)境，快速應(yīng)對峰值，同時在基礎(chǔ)設(shè)施上支持跨云。之后，在內(nèi)容服務(wù)器用完的情況下，可借用公有云這份解決方案，把流量峰值問題遷移到公有云。

業(yè)務(wù)彈性調(diào)度。如下圖，是舊的應(yīng)對手段和彈性擴(kuò)容手段的對比。實現(xiàn)彈性擴(kuò)容后，系統(tǒng)會使用容器化來抹平各業(yè)務(wù)環(huán)境，把各業(yè)務(wù)之間的冗余部分放到共享池。這樣一來，哪個業(yè)務(wù)需要擴(kuò)容，就可以很簡單地從共有池把這部分設(shè)備擴(kuò)容。

因各個業(yè)務(wù)之間的峰值和負(fù)載程度不一，把其他業(yè)務(wù)的冗余設(shè)備拆借過來，實際擴(kuò)容能力相比以前的 1~2 倍，可以提升到 2-3 倍。

基礎(chǔ)設(shè)施支持跨云。如下圖，是私有云和公有云各自的優(yōu)勢。針對各自的特點，在部署流量時，需做一些側(cè)重操作。如針對常規(guī)的流量，優(yōu)先會部署到私有云，保障體驗、性能等都是最優(yōu)。這里涉及公有云安全性和私有云之間有一定差異以及在性能上會有一定下降的問題。

假設(shè)在公有云流量部署 1 小時，其中可能公有云一些服務(wù)還會依賴于私有云服務(wù)，這樣就會出現(xiàn)跨機(jī)房調(diào)用的情況?？煞?wù)只是微慢，而不是降級或停用，和之前相比優(yōu)勢很大。

另外，假設(shè)把常規(guī)的負(fù)載也部署到公有云，只要把所有底層全部做多機(jī)房部署，根據(jù)不同業(yè)務(wù)做流量分配即可。

DCP 平臺架構(gòu)。如下圖，是 DCP 平臺抽象版架構(gòu)，主要分為主機(jī)、環(huán)境、服務(wù)和業(yè)務(wù)四層：

DCP平臺抽象版架構(gòu)

• 主機(jī)層。這層的作用是假設(shè)需要擴(kuò)容 50 臺服務(wù)器，這些服務(wù)器可能來自內(nèi)網(wǎng)、也可能來自公有云。上層在使用過程中，需要通過 Adaoter 來提供，優(yōu)先內(nèi)網(wǎng)，之后去公有云創(chuàng)建。

• 環(huán)境層。這層主要是編排的過程，封裝眾多的原則性行為的 API。

• 服務(wù)層。負(fù)責(zé)根據(jù)眾多 API，組合搭建一個服務(wù)。

• 業(yè)務(wù)層。業(yè)務(wù)層通過負(fù)載均衡把流量引入服務(wù)器。

私有云“化零為整”。如下圖，是一個基于 DCP 的模型，左側(cè)是傳統(tǒng)架構(gòu)，假設(shè)長方形是每個業(yè)務(wù)需要的機(jī)器，如 A 業(yè)務(wù)要擴(kuò)充兩臺，就承載不了，就需降級。右側(cè)接入到混合云后，把所有業(yè)務(wù)的環(huán)境抹平，所有設(shè)備放到共享池，假設(shè) C 業(yè)務(wù)需要三臺設(shè)備，在新的架構(gòu)下，可輕松從共有池選取。

基于混合云 DCP 平臺的 PHP 服務(wù) Docker 化

服務(wù) Docker 化。Docker 是從邏輯層面虛擬化，把環(huán)境做鏡像差異化從而進(jìn)行快速部署。Docker 服務(wù)啟動快，鏡像一次制作，多次快速部署，尤其適合動態(tài)擴(kuò)容部署。

PHP 服務(wù) Docker 化的部署方案設(shè)計。如下圖，粉色部分是 PHP 服務(wù)相關(guān)組件nginx、php-fpm、memcache、scribe 等，這些組件容器單獨部署。像代碼、配置、日志等經(jīng)常變更，黃色部分通過掛載的方式和 Docker 容器互動。

鏡像制作。鏡像制作的步驟如下：

1. 從鏡像倉庫中拉出 CentOS 作為基礎(chǔ)鏡像

2. 運行鏡像

3. 在運行容器中安裝 PHP 環(huán)境相關(guān)軟件包

4. 提交修改并推送至倉庫

5. PHP 服務(wù)鏡像制作完畢

鏡像方案。基于 CentOS 6.7 來制作鏡像，將 PHP 服務(wù)組件拆成獨立鏡像。這里涉及到的問題是“鏡像占用空間相對較大，每個都超過 1G 大小。同時拉取鏡像耗時太久，占用寬帶較高。針對這個問題，解決的辦法是將 PHP 相關(guān)的組件制作成一個鏡像，服務(wù)通過容器命令來啟動。

在部署過程中，主要解決三大核心問題：首次部署、代碼上線與配置變更。

首次部署，如下圖是首次部署的流程，由 DCP 平臺發(fā)起擴(kuò)容，把擴(kuò)容的數(shù)據(jù)和業(yè)務(wù)相關(guān)的文件配置好，全部發(fā)到前端機(jī)。每一個前端機(jī)基于配置文件，進(jìn)行拉取代碼、啟動容器和服務(wù)查詢等操作。

代碼上線。如下圖，通過鏡像完成上線，代碼鏡像使用 busybox 為基礎(chǔ)，大小僅1M。

創(chuàng)建代碼鏡像。如下圖，創(chuàng)建代碼分為 Dockfile，Build，下載代碼鏡像、啟動容器、拷貝代碼三步驟。

配置文件更新。如下圖，把配置文件制作成 Docker 鏡像，每臺機(jī)器拉取鏡像，替換配置文件，自定義腳本執(zhí)行 reload。

這里值得提醒的一些細(xì)節(jié)有：

• Docker 化后，宿主機(jī)運行在 Centos7.0

• 內(nèi)核升級到 3.10

• 容器中的啟動命令需要前臺啟動

• 經(jīng)常變更的部分放在鏡像外，通過 volume 掛接容器

• 網(wǎng)絡(luò)模式：選用 host 網(wǎng)絡(luò)模式

• 容器的 reload 或優(yōu)雅重啟采用 dockerexec xx reload 方式

基于混合云DCP平臺的PHP彈性擴(kuò)容

說到彈性擴(kuò)容之前，先說三個概念：服務(wù)、服務(wù)池、集群。如下圖，服務(wù)可以理解為業(yè)務(wù)，像新浪微博的紅包飛、問答等。服務(wù)池，就是業(yè)務(wù)會部署到哪個機(jī)房。集群就是來自內(nèi)網(wǎng)或公有云上的閑置不屬于任何業(yè)務(wù)的機(jī)器。

擴(kuò)容流程。如下圖，整個流程分為資源申請、環(huán)境初始化和服務(wù)上線三部分。管理員向混合云平臺發(fā)起請求，之后完成設(shè)備、服務(wù)初始化的過程、調(diào)度中心對服務(wù)進(jìn)行部署，包括代碼的拉取。初始化完成后，通過服務(wù)上線，把4/7層流量切入，部署整個監(jiān)控中心。

擴(kuò)容模板。一個新業(yè)務(wù)需要支持彈性擴(kuò)容，都需要在 DCP 平臺配置，與之相匹配的是配置系統(tǒng)，如下圖。鏡像地址 image.1.6.1、所有服務(wù)器組件的參數(shù)、掛載的容器、代碼的掛載位置、配置容器參數(shù)等都需要提前配置好。

流量切換。這里和阿里云合作非常多，把公有云已經(jīng)初始化好的前端機(jī) IP 加載到負(fù)載均衡中，自動重啟、部署，無須人為操作。

彈性容量的考慮。Push 時，就要考慮擴(kuò)容，針對某一事件在某一地區(qū)進(jìn)行部署，基于以往的數(shù)據(jù) ，評估系統(tǒng)預(yù)估需要擴(kuò)容的服務(wù)器。還有穩(wěn)定性高、低峰的服務(wù)，針對一些每天晚上 9、10 點出現(xiàn)流量翻倍的情況，實現(xiàn)自動擴(kuò)，自動退。

擴(kuò)容控制、效果。如下圖是抗峰值，話題服務(wù)器的擴(kuò)容過程以及完成后的內(nèi)部效果。需要 16G 機(jī)器，50臺，在擴(kuò)容系統(tǒng)輸入完成，五分鐘搞定。大概15分鐘左右，流量峰值被削平。

總結(jié)

本文結(jié)合架構(gòu)圖和數(shù)據(jù)圖，詳細(xì)介紹了 LNMP 服務(wù)的Docker化，如何制作PHP服務(wù)相關(guān)鏡像，最后結(jié)合DCP平臺完成PHP服務(wù)的首次部署、配置更改、代碼上線等。

目前，新浪微博主站 TV 視頻站、頭條問答、話題、紅包飛、通行證等 LNMP 項目已全量部署，方便彈性擴(kuò)容。同時，也將繼續(xù)推進(jìn) PC 主站服務(wù)的部署。

以上內(nèi)容由編輯王雪燕根據(jù)侯青龍老師在 WOTA2017 “高可用架構(gòu)”專場的演講內(nèi)容整理。

侯青龍

新浪微博主站研發(fā)負(fù)責(zé)人

侯青龍 ，2010 年加入新浪微博，先后參與過微博主站 V2 版至 V6 版的研發(fā)，主導(dǎo)過主站 V6 版、多機(jī)房部署以及淘浪合作等重大項目的架構(gòu)設(shè)計工作。目前，他負(fù)責(zé) PC 主站研發(fā)工作，致力于提升產(chǎn)品研發(fā)效率以及優(yōu)化系統(tǒng)性能，善于在業(yè)務(wù)需求和產(chǎn)品研發(fā)之間找到最大公約數(shù)。在基于 LAMP 架構(gòu)的大型系統(tǒng)架構(gòu)設(shè)計、海量數(shù)據(jù)訪問、分布式緩存設(shè)計等領(lǐng)域具有豐富的經(jīng)驗。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

標(biāo)題名稱：新浪微博基于混合云的PHP服務(wù)化與彈性擴(kuò)容
網(wǎng)頁URL：http://www.dlmjj.cn/article/ccssepd.html