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

 

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

新浪微博遭遇流量峰值挑戰

 

新浪微博作為社交產品，經常出現因某些原因所致的話題突發流量峰值，且峰值不可預估。例如：

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

• 大型活動及三節保障：紅包飛

• Push 推送：運營的各種站內，站外 push

話題業務的流量特點

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

 

從架構角度，如何處理？

 

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

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

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

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

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

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

   

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

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

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

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

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

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

• 實現業務彈性擴容。各個業務之間峰值不一樣，可通過技術把環境抹平，實現隨時化的自由調度。

 

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

 

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

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

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

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

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

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

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

DCP平臺抽象版架構

• 主機層。這層的作用是假設需要擴容 50 臺服務器，這些服務器可能來自內網、也可能來自公有云。上層在使用過程中，需要通過 Adaoter 來提供，優先內網，之后去公有云創建。

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

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

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

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

 

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

 

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

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

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

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

2. 運行鏡像

3. 在運行容器中安裝 PHP 環境相關軟件包

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

5. PHP 服務鏡像制作完畢

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

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

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

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

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

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

這里值得提醒的一些細節有：

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

• 內核升級到 3.10

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

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

• 網絡模式：選用 host 網絡模式

• 容器的 reload 或優雅重啟采用 dockerexec xx reload 方式

 

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

 

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

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

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

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

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

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

 

總結

 

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

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

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

 

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

 

 

[[193977]]

侯青龍

新浪微博主站研發負責人

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

 

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】