系統架構的大大加強
SF以前的系統架構是什么樣子呢？回答是沒有什么架構，因為所有的服務都放在一臺服務器上，這個答案可能讓很多用戶大跌眼鏡。

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

云主機助力

對于SF這樣的初創企業，自己建立數據中心顯然是性價比極低的選擇，但是系統架構的限制又逼迫SegmentFault不得不做出改變。幸好現在已經進入了云時代，大量的基礎設施問題可以交給更專業的服務商解決。經過一系列權衡，SegmentFault最終選擇了青云作為SegmentFault的云主機提供商。

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

更加顆粒化的系統劃分

這一點在web服務器系統的設計上尤為突出，它是所有服務器中壓力最大的，因此機器數量也是最多。但是每臺服務器的配置卻是最小的 單核1G 的實例。

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

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

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

改變代碼上線模式

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

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

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

除了SegmentFault的云主機，SegmentFault還使用了如下云服務

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