【51CTO.com原創稿件】就在上周，由51CTO主辦的WOTA全球架構與運維技術峰會在北京富力萬麗酒店隆重召開。本次WOTA設置了15大前沿熱點技術論壇，60+來自Google、LinkedIn、Airbnb、百度、阿里巴巴、騰訊、金山等海內外一線互聯網公司的技術大咖帶來超過50個歷經沉淀的架構實戰心得與成功經驗分享案例，攜手打造歷時2天的行業***技術盛會。

　　在***天下午高可用架構的A會場，新浪微博主站研發負責人侯青龍發表了一場《新時代下的微博LNMP架構》的演講。演講結束后，記者采訪了侯青龍，他與記者分享了他和新浪微博的技術團隊關于新時代下的LNMP架構的一些部署經驗，以及在新時代中遇到的一些挑戰。此外他還從彈性角度介紹了新浪微博LNMP平臺在開發時的思路和收獲。

　　用新的思路規避傳統架構弊端

　　新浪微博作為一個重要的社交平臺，經常會遇到一些突發事件，海量轉發給服務架構帶來極大的考驗。傳統做法存在一些不足之處，例如傳統設備采購申請周期長、擴縮容繁瑣、設備運營成本高。當面臨流量壓力時，常規做法是IT設備會做一部分冗余，但不能***冗余，畢竟還需要考慮到成本問題。侯青龍以CPU為例，一般情況下，CPU利用率可能在20%~ 30%這個區間，是一種常態，新浪內部有要求，每臺服務器CPU要運行到40%左右才不會被認為是閑置。但如果CPU運行到了60%，那技術團隊可能就需要考慮擴容。

　　面對流量壓力，還有一個常規做法是服務降級，將那些不是很重要的功能模塊依次關閉，保證最主要功能運行無虞。但是這樣做的弊端是，在最嚴重情況下，微博很多模塊不再顯示，用戶體驗非常不好。

　　在這樣的情況下，新浪微博的技術團隊開始思索如何既降低設備運營成本，又能增強業務的彈性擴容部署。侯青龍告訴記者，最終新浪微博選擇了基于混合云平臺的PHP彈性擴容部署方案，搭建了DCP平臺，既可以實現業務的彈性調度，基礎設施又可以跨云操作，非常好地解決了突發流量的問題。

　　之前在會場，有一位與會者問了一個問題：如果流量突然之間暴增，那么臨時去擴容也存在一定時間差，這時該如何處理，確保服務無損?侯青龍表示這時候就需要去做提前預判。如果CPU在60%的運營狀態就處于危險邊緣，那么在50%的時候就應該提前去做擴容處理，如果時間緊張，那就先進行降級處理，因為我們降級比較方便，后臺很多級只需要動個按鈕就可以完成，優先去進行一個降級，等到擴容完成立刻恢復，盡量縮短降級的時間。

　　DCP的價值

　　那么，新浪的這個DCP平臺究竟是如何解決彈性擴容和跨云問題的呢?

　　侯青龍告訴記者，彈性擴容是把所有環境差異通過容器化鏡像進行打包，盡量讓底層主機變得透明。為什么要這么做呢?是因為之前部署PHP服務器還有Java服務器，各自操作系統的選擇和業務環境的部署差異非常大，即使處于冗余狀態，也無法使用。但是通過DevOps Community化的技術，把這些技術全部分流到鏡像中去，部署一模一樣的Docker引擎，當新浪微博需要部署某個服務時，可以快速地將鏡像下載下來并立即啟動。

　　而基礎設施跨云，其實等于抹平了主機的差異，讓用戶不再關心擴容需要多少服務器，減輕了過去在基礎設施環節的工作量。

　　在侯青龍看來，DCP的價值在于把所有的行為在事前都以系統的方式組織起來，當需要去部署某一個服務或打包某個鏡像時，都可以基于系統通過按鈕的方式快速完成，細節的東西完全做到了自動化。

　　DCP帶來的另外一個明顯的好處是降低了運維的難度，因為運維人員不再需要精通技術，只需要懂得操作系統就可以了，所有技術化的東西都已經被隱藏在后端，前端呈現的就是自動化的操作界面。

　　為什么選擇Docker?

　　侯青龍透露，其實以前他們也考慮過不用Docker技術，用虛擬機來代替，新浪微博在做一個開發機或者測試環節時，實際上已經有了一套純虛擬機，完全可以直接使用。而如果基于Docker，那就意味著所有的接入方式必須以Docker方式接入。

　　但是***技術團隊認為，他們更希望新的服務架構對于開發的同事而言是沒有感知差異的，不希望內部有兩套體系，因為同一個配置實際上可以部署到彈性擴容平臺，也可以部署到傳統的平臺，沒有差異，所以最終選擇了Docker技術。

　　此外，新的服務架構也遇到了一些難題。因為彈性擴容時代碼隨時會刪，環節比較復雜，最穩妥的做法是全量部署，但由于PHP代碼和Java代碼不一樣，Java代碼是本地打包完了以后，直接把那個打包文件推送就行。而PHP文件完全是散的，傳統方式是通過rsync去推送，但是Docker化之后，他們發現，每次全量部署都需要重新推送，哪怕代碼只改動了一個指令。后來經過一些測試，他們發現鏡像部署特別好，1G的鏡像可能幾十秒鐘就下載完了，全量部署比想象中快很多。

　　經驗分享：如何讓架構變得有彈性?

　　侯青龍介紹到，新浪微博的業務系統都是基于PHP開發，技術團隊過去做鏡像、做優化時，大多都會進行單獨部署，單獨做成一個鏡像。但當遇到需要擴容的時候，系統運行的時間就變得非常慢。原因在于過去編輯鏡像的時候，技術人員會針對每一個鏡像做一個打包，相當于每個鏡像都包含一個操作系統，假設一個操作系統600兆大小，那么即便是鏡像安裝100兆大小的PHP加起來也有700兆，下載特別慢。

　　后來他們把這個鏡像打成鏡像包，所有的組件都共用一個操作系統，大小被壓縮了好多，下載速度也更快。這樣部署新系統功能時，以前可能要半個小時，現在只需幾分鐘就搞定。

　　在采訪結束時，記者詢問侯青龍對于服務架構未來發展趨勢的一個預測，他表示，從宏觀角度看，當企業在發展初期時，服務架構的宗旨就是怎么方便怎么做，但是當企業已經具備了一定規模，這時候服務架構就需要去考慮如何用工具解決所有問題，盡量用自動化的角度解決問題，這是他的經驗分享，希望能夠對大家有所幫助。

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