系統(tǒng)架構(gòu)的大大加強(qiáng)
SF以前的系統(tǒng)架構(gòu)是什么樣子呢？回答是沒有什么架構(gòu)，因?yàn)樗械姆?wù)都放在一臺服務(wù)器上，這個答案可能讓很多用戶大跌眼鏡。

是的，受制于創(chuàng)辦之初的資金限制，SegmentFault的網(wǎng)站只有一臺服務(wù)器。在后期訪問量逐漸增大的情況下，這臺服務(wù)器狀況不斷，如果有一天它突然掛掉，那恢復(fù)它可就費(fèi)事了。

云主機(jī)助力

對于SF這樣的初創(chuàng)企業(yè)，自己建立數(shù)據(jù)中心顯然是性價比極低的選擇，但是系統(tǒng)架構(gòu)的限制又逼迫SegmentFault不得不做出改變。幸好現(xiàn)在已經(jīng)進(jìn)入了云時代，大量的基礎(chǔ)設(shè)施問題可以交給更專業(yè)的服務(wù)商解決。經(jīng)過一系列權(quán)衡，SegmentFault最終選擇了青云作為SegmentFault的云主機(jī)提供商。

4 * web服務(wù)器(其中一臺備用)
1 * db服務(wù)器(得力于ssd和緩存的使用，目前一臺db是可以滿足需求的)
1 * 搜索服務(wù)器
1 * 緩存服務(wù)器
1 * 后臺服務(wù)服務(wù)器
一般工作的就是這8臺服務(wù)器

更加顆?；南到y(tǒng)劃分

這一點(diǎn)在web服務(wù)器系統(tǒng)的設(shè)計(jì)上尤為突出，它是所有服務(wù)器中壓力最大的，因此機(jī)器數(shù)量也是最多。但是每臺服務(wù)器的配置卻是最小的 單核1G 的實(shí)例。

這種顆粒化的劃分，有以下幾個好處

節(jié)約成本，如果SegmentFault一次性配置一臺多核大內(nèi)存的服務(wù)器，成本是很高的，而且大部分情況下性能是有浪費(fèi)的。
增加可靠性，一臺機(jī)器掛掉的可能性遠(yuǎn)大于多臺機(jī)器同時掛掉
方便水平擴(kuò)展，你可能已經(jīng)注意到我設(shè)計(jì)了一臺備用服務(wù)器，它平時就是掛在負(fù)載均衡節(jié)點(diǎn)上的，只是不需要開機(jī)（如果不開機(jī)是不會計(jì)費(fèi)的），當(dāng)遇到突然增加的訪問量時，SegmentFault可以實(shí)時啟動這臺服務(wù)器，從而瞬間減輕其它節(jié)點(diǎn)的壓力。而訪問量降低后，SegmentFault又可以關(guān)掉它，降低使用成本。

比如上面這張圖就是一次典型的流量沖擊處理，在11點(diǎn)左右網(wǎng)站的訪問量陡增，前端web的負(fù)載全部到頂，根據(jù)它的增長曲線，SegmentFault判斷這是一次惡意抓取。需要SegmentFault在程序上做防護(hù)的同時在這期間不影響用戶訪問，因此SegmentFault將第四臺備用服務(wù)器的配置臨時調(diào)整到 4核2G，并在12點(diǎn)左右上線，系統(tǒng)負(fù)載馬上恢復(fù)到了正常水平

改變代碼上線模式

通常的上線流程就是直接把可發(fā)布的代碼通過rsync之類的同步到線上機(jī)器。

在新版的SF中SegmentFault根據(jù)PHP的特點(diǎn)改變了這一模式，SegmentFault將代碼打包成phar發(fā)布到服務(wù)器，每上線一次就重新打一個包，并將其文件名命名為版本號，比如14.9.5.195755.1718937340.phar。打包發(fā)布有如下好處：

方便管理，只有一個文件，而且傳輸比以前的同步模式更加快速，并且可以避免當(dāng)某些文件沒有同步完用戶就來訪問的錯誤
可以回滾，回滾非常方便，在配置文件里將需要加載的包版本號改成你需要回滾的版本即可，可以快速完成災(zāi)難恢復(fù)
更加好地依賴云服務(wù)

除了SegmentFault的云主機(jī)，SegmentFault還使用了如下云服務(wù)

Amazon SES，群發(fā)郵件價格便宜量又足
Mailgun，目前SegmentFault的主力郵件發(fā)送服務(wù)，大家的通知提醒服務(wù)都是通過它
SendCloud，備份郵件發(fā)送服務(wù)，主要用來發(fā)一些mailgun無法收到的郵件，比如QQ Mail等等
又拍云，所有的靜態(tài)文件，包括用戶頭像和上傳圖片的存儲
NewRelic，程序性能監(jiān)測