emu in blogjava

BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合

:: 管理 ::

171 隨筆 :: 103 文章 :: 1052 評論 :: 2 Trackbacks

<

2016年2月

>

日

一

二

三

四

五

六

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

1

2

3

4

5

6

7

8

9

10

11

12

公告

專心AJAX......

常用鏈接

留言簿(92)

隨筆分類(20)

隨筆檔案(171)

文章分類(89)

文章檔案(103)

收藏

搜索

積分與排名

積分 - 722069
排名 - 63

閱讀排行榜

評論排行榜

用騰訊云優化一個公益論壇

@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); @import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); 〇、背景

幾年前由于發起尋親項目的關系，和B網站開展了合作。B網站是國內最大的尋親網站，幾年來通過該網站和家人團聚的案例已經達到1397例。B論壇是網站中最活躍的板塊。當時論壇遇到一些不穩定的情況，因為B論壇是用Discuz！搭建的，而Discuz！當時剛好被騰訊收購，要獲得專業支持相對容易，我們開始把B論壇遷移到騰訊云上面，由Discuz！的志愿者協助維護直到去年底離職，把論壇的管理權限交給我。

一、論壇出問題了

我不對于php和linux都不熟，交接后看到論壇工作還算正常，也很長一段時間沒有去關注，直到前幾天，網站管理員突然發來了這個：

這是什么鬼？臣妾不懂啊……只好硬著頭皮登上服務器去看看。

還好，大概可以猜到出什么事了：數據盤不夠用了。那應該很好解決吧？擴數據盤？

二、COS

用騰訊云服務器而不是自己買服務器的一個好處就是，很多資源可以按需用，按需擴，包括硬盤。不過有個限制就是，買服務器的時候系統盤和數據盤都必須要買“云硬盤”而不能用本地盤。買云硬盤還有個附加的好處是可以申請開通硬盤快照功能，遷移復制服務器唰唰的。

但是云硬盤的性能跟本地硬盤是有差距的，處于性能考慮，志愿者選擇了性能更好的本地硬盤，這樣就導致硬盤滿了以后沒有辦法擴了。幾年來，尋親的網友們每天上傳大量的高清圖片線索，終于在世紀寒流這幾天把硬盤擠爆了。

不過擴硬盤本來也不是最佳選擇，比擴硬盤更好的選擇是：不用硬盤！

騰訊云為這種UGC文件提供的解決方案是COS（Cloud Object Service），當前版本是COS3.0。COS 大概的意思就是，你有一大堆文件（比如網站用戶上傳的照片），只知道量很大，不知道有多少，不但需要找個地方存著，還隨時有可能需要在某個網頁上引用它。那么平臺提供一個服務器讓你把文件放上去，并提供web訪問和API上傳和管理接口，你就不用把文件傳到自己服務器了。

個人認為使用COS的好處是：
1 能夠提供幾乎無限量的文件存儲空間，按存儲量和訪問量收費
2 很大的免費額度：50G的免費空間，每計費周期內10G的回源流量，每計費周期內100萬次的免費訪問次數（實際上COS通常在CDN后面提供服務，因此實際上每個計費周期可以提供10G和100萬次回源服務，配合恰當的CDN緩存策略，已經可以滿足很大的訪問量）。
因此用cos不但從此不用糾結容量爆倉的問題，也不用為沒有使用到的容量預先買單花冤枉錢，而且還不用自己的服務器的硬盤和網卡來扛這些流量，服務器的帶寬和硬盤I/O壓力也立刻就下來了。

COS的使用也很簡單:
1 建個倉庫（bucket），以后附件就往這個倉庫里面傳了。

2 修改上傳附件頁面，使用騰訊云提供的API把文件上傳到COS……開玩笑了，作為懶人，當然是提工單申請開通COS的FTP權限啦

大概兩個鐘頭后收到消息說ftp開通了。

3 用論壇創始人身份登錄discuz，打開遠程附件

遠程訪問url可以域名解析到COS源上，不過這樣附件都要走IDC流量，不但貴，也沒有實現靜態文件就近訪問的目標，因此實際使用的時候最好在COS服務的上面加一層CDN：

現在用戶新上傳的附件都自動到cos里面了。然后我們來對付舊的附件吧。這時我們要用到回源功能了。先準備好一個回源專用的域名，修改httpd.conf（apache）或者conf.d（nginx）添加一個新的server，documentroot（或者root）指向服務器上discuz的附件目錄 data/attachment 并修改域名解析，瀏覽器里面訪問一下確認回源域名可以訪問到附件。然后修改cos的回源配置：

這樣如果有人訪問cos的時候cos上沒有相應的文件，服務器就會到老的服務器上獲取文件并緩存下來。通過瀏覽器訪問附件確認回源成功后，登錄數據庫 update cdb_attachments set remote = '1' 把所有的附件都更新為遠程的。這樣數據就會隨著用戶的訪問慢慢遷移到cos上了，這個過程平滑無感知，不過就是不知道遷移到什么時候成功。

可是我想釋放硬盤空間出來啊怎么辦？先裝上ftp神器 lftp再說。不得不說，在linux下，lftp實在是個神器。打開lftp，open登上COS的ftp服務器，mirror -RL ..... 老附件通通遷移上COS咯。

偷懶用ftp而不是修改上傳頁面代碼的一個代價是，有的時候ftp失敗，會有一些附件仍然被扔在CVM硬盤上?？梢远ㄆ?/span>update cdb_attachments set remote = '1' 把附件都改成遠程的，讓cos回源到CVM上。不過就算這樣，冷門的附件仍然可能長時間沒有辦法同步到cos上。crontab一個lftp任務定期把附件同步上COS可以解決問題。不過如果懂一點點開發的話，寫一點點腳本用inotify自動同步一下顯得會看起來好點兒：

三、 CDN優化：動靜分離

內容分發網絡（Content Delivery Network）大概的意思就是，我大騰訊在全國成百上千個機房里面屯有無數的服務器，如果某個邊遠地區的用戶要訪問你放在上海的一份數據，山長水遠的跑到上海機房來拉數據肯定快不了，如果我把這份數據先放在這個邊遠地區里，離用戶最近的一個機房呢？那速度就不一樣了。而且這個邊遠地區的機房流量還比我大上海三通機房的流量便宜了一大截。不過有個前提是服務器要提前知道用戶將要訪問的數據，并提前拉取這份數據緩存在當地，因此一般只用來服務靜態的圖片、樣式表、腳本、超文本、flash這些資源。

B論壇其實去年就用上了CDN，不過用的是一個比較冷門的用法：動態加速。這個用法就是說，先假設我網站的所有請求都是靜態的，這樣用戶所有的請求都訪問在當地的服務器（邊緣服務器），然后邊緣服務器檢查一下這個請求的資源我有沒有緩存啊，沒有的話邊緣服務器再受累跑去你的服務器上拉這個數據，把數據返回給你，并且嘗試緩存這個數據以備下次使用。然后對于不允許緩存的動態請求，只要聲明一個策略，比如“php文件緩存時間0秒”這樣，讓邊緣服務器直接訪問源CVM服務器就好了。

這樣做的好處是配置簡單，不需要關心動靜分離，并且不但靜態的文件都可以被邊緣服務器緩存，動態的請求也可以獲得cdn網絡的傳輸加速。壞處就是“流量double”。也就是說，你不但要給cvm購買外網帶寬，cvm的動態數據送到邊緣服務器以后，你還要再購買一次從邊緣服務器到用戶那里的cdn帶寬（或者流量）。

另外一個附加的“缺點”是，CDN網絡總是盡可能快的從CVM服務器拉取全部數據，再按照訪客用戶網絡的速度再把數據吐出去。這其實是最佳策略，因為CVM的帶寬已經買單了，不跑慢也是浪費，但是帶來的問題就是CVM監控上看起來，再多的帶寬都會被跑滿，好像帶寬永遠都不夠用。因此前任的管理員購買了非常多的帶寬來試圖滿足永遠喂不飽的CDN網絡，帶寬成了B論壇最沉重的成本。

（15M的帶寬，經常性的被CDN跑滿）

貿然的減少帶寬也是不合適的，最好的做法還是做盡量徹底的動靜分離，靜態的部分還是用cos托管源和FTP托管源來喂飽CDN網絡，讓用戶盡可能體驗好；動態的部分直接訪問CVM，根據用戶日常實際產生的帶寬情況再加上足夠充分的冗余來采購就可以。

傳統的動靜分離手段是最好的：直接修改html、css和js，通過靜態專用域名訪問靜態資源。但是這樣做需要很多的開發工作量，作為懶人，我直接用上了大殺器：rewrite！

懶得給每個域名打馬賽克了，也不是什么機密。這幾條規則是這樣：
1 對于普遍圖片超大的png圖片，自動轉向到優圖系統進行jpg壓縮。因為監控發現少數png圖片占了很大的流量比重。
2 對于用戶上傳到附件，自動轉向到attachment子目錄（COS源），這樣CVM就不需要承擔附件文件的存儲了（零星缺失的文件cos回源啟用了回源專用的域名）
3 對于系統的靜態文件，自動轉向到static子目錄（FTP源），不統一使用cos源的原因是，CDN回源到ftp源是免費的，但是ftp源只有6G的存儲空間?；卦吹絚os空間幾乎是無限的，但是是有可能收費的。
這樣就把CVM上出了favicon.ico之外的幾乎所有靜態文件都分離出去了。要注意的是如果盜鏈嚴重的話，原本nginx上的防盜鏈規則也要相應的設置到cdn上去。

動靜分離后cdn的整體命中率從瓶頸50%以下一下提升到75%以上，對于cvm的壓力大大減小了。看一下分域名的命中率數據

在不對論壇程序做細致的優化的情況下，只是通過策略調整達到這樣的命中率，還算比較理想了。

不過這樣做了以后，CDN的流量費用并沒有下降啊。因為B論壇的CDN采用了峰值帶寬計費模式，因此觀察了一下cdn監控的帶寬數據，發現了一個很有意思的問題：

CDN的峰值帶寬按天波動非常大。細看到具體的帶寬比較大的一天更明顯：

這天是央視《感動中國2016》B論壇的兩個發起人入選帶來的一個訪問波峰。

像這樣的帶寬曲線模式，按照帶寬購買CDN是非常浪費的。果斷切換到流量包計費模式，CDN費用從每月>￥500(每年大約￥6000~￥8000)下降到每年<6T(每年大約2000以內)

動靜分離后CVM的實際動態帶寬需求有多少呢？后面上了負載均衡之后沒有地方可以截屏幾臺服務器完整的帶寬總和曲線了，總體是2M帶寬平常跑不滿，但是偶發集中的訪問會超，所以兩臺CVM做負載均衡，各開了2M的帶寬，保證平常有超過一倍的帶寬冗余。

四：memcache和云數據庫

B論壇遷移到騰訊云的時候就使用了云數據庫，數據量雖然不大，但是數據庫訪問量不小，購買的是能支撐2400QPS的50G/2000MB型號。

（7天后到期，不需要續了）

但是查看了一下discuz的優化選項，發現內存緩存優化項都沒有打開。在CVM里裝上一個memcached測試了一下，數據庫請求可以有效的降低到100QPS以下。這樣高配云數據庫就太浪費了，換個10G/360MB/120QPS的就足夠了。不過性能冗余夠不夠？discuz支持master/slave的，先提個工單申請一個免費的slave。

配置slave后觀察了幾天，即使在峰值查詢接近700QPS的情況下數據庫也沒有出現訪問瓶頸，騰訊云數據庫的性能還是相當厚道的，這個性能冗余是足夠的。

（某海量網站配置錯誤導致出現大量404頁面，順帶給論壇帶來了很大壓力）

這樣數據庫費用從￥2240/年陡降到￥210/年了。已經省了這么多錢，再買個C型的memcached好了，每天2元，每年大概700元。
CVM本機運行一個memcached雖然性能不錯，但是始終要和其他本機服務競爭各種資源，而且考慮到后面要做負載均衡，也希望把登錄態（session）丟到云里面去。

（memcache很輕松的扛住了情人節的感動中國帶來的訪問量）

修改了一下discuz的配置文件指向memcached，再修改php.ini把session也指向了memcached，這下CVM就沒有“狀態”了，可以很容易的替換，或者集成多個做負載均衡。

五：CVM和負載均衡

B論壇在騰訊云上一共兩臺CVM，對外提供服務的是一臺配置有點豪華的服務器：

這臺每年費用是￥16450，當然主要的錢都花在買帶寬去喂CDN了

另一臺不對外服務，只是有一個大的硬盤做數據備份。

一年￥1550。

經過上面一系列優化以后，原本買的CVM性能就太過冗余了，文件都丟到COS上去了，大硬盤備份也沒有必要了。已經遷移到cos的文件剔除后，整個系統只剩下了4G，全部回遷到系統盤上面，數據盤也不需要了：

因為數據庫在云上，附件文件也在cos上，本地沒有什么動態的數據，這樣系統備份也簡單的多了，定期對系統盤做一個“系統鏡像”就成，除了有一個問題：做系統鏡像要關機。

墨菲定律告訴我們，永遠要防著機器宕機！前面該清理的清理干凈了，是時候做雙機熱備了。先把備份機的論壇服務也啟動起來，session也指向memcached，然后添加一個負載均衡：

訪問低谷的時候把主服務器關掉，做鏡像，備份機自動扛住了全部訪問量。

有了鏡像以后換機型就方便了。新購一臺服務器

因為充分使用了云數據庫、memcache、cdn、cos等paas服務，又做了動靜分離，cpu現在已經清閑的很，1核的性能是足夠的。內存使用率也很低，內存其實1G也足夠，不過cpu不夠了還可以負載均衡，內存不夠了就只有干瞪眼，所以多加1G冗余。
，
購買的時候就可以直接指定安裝鏡像，支付每年￥1250的費用，10分鐘后，有了一臺全新的服務器，配置host驗證成功，加入到負載均衡后端列表里面

把權重分幾次從原來的高配服務器分配到新服務器上，運行指標都還好，就是負載有點兒高，訪問速度可能不是最優，也許是mysql或者memcache要通過網絡訪問導致的？

反正要做雙機熱備的，再買一臺一樣的服務器，加入負載均衡后臺分攤一半的訪問量，觀察了一下cpu利用率和負載都下來了，雖然偶爾有一些瞬間的毛刺，反問上已經感覺不到差別。

這樣就有了兩臺一模一樣的服務器，平常分攤訪問壓力，一臺宕機的時候負載均衡會自動發現并把訪問全部導向到正常工作的服務器。未來如果有更大的訪問壓力隨時可以新購機器，安裝上鏡像后加入負載均衡后端。

正好原來購買的服務器和數據庫這陣子都要過期了，就都不用續費了。

六、對公益捐贈負責

看看優化后比原來節省了多少：

CVM: 原來16450+1550=18000 ，優化后1250*2=2500

CDN+COS：原來：￥6000~￥8000，優化后約￥2000（COS回源流量暫時還沒收費，附件遷到cos后也不足50G還不需要存儲費用，不過未來有可能產生少量費用。）

mysql+memcache ：原來￥2240，優化后210+700=910

總體相比原來優化大約￥22000 /年。

雖然騰訊云一直對于公益組織免費扶持云資源，但是我覺得云資源和公益捐贈善款一樣，也要用負責的態度摳門的用好，才是對支持企業負責任的態度。

最后，感謝騰訊云對公益事業的慷慨支持。打完收工。

posted on 2016-02-19 17:56 emu 閱讀(1206) 評論(0) 編輯收藏

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理