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

 

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

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

 

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

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

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

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

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

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

 

從架構角度，如何處理？

 

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

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

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

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

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

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

   

• 擴縮容繁瑣。如下圖，當服務器到位，做擴容，又是一個繁瑣流程，還需要多部門共同合作。

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

DCP平臺抽象版架構

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

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

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

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

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

 

基于混合云 DCP 平臺的 PHP 服務 Docker 化

 

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

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

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

1. 從鏡像倉庫中拉出 CentOS 作為基礎鏡像

2. 運行鏡像

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

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

5. PHP 服務鏡像制作完畢

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

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

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

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

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

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

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

• Docker 化后，宿主機運行在 Centos7.0

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

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

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

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

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

 

基于混合云DCP平臺的PHP彈性擴容

 

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

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

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

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

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

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

 

總結

 

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

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

視頻地址：http://edu.51cto.com/center/course/lesson/index?id=166147

 

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

 

 

[[193977]]

侯青龍

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

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

 

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