新版 SegmentFault 重構之系統架構

若是有關心SF發展同窗確定經過很多渠道瞭解到咱們正在對它進行全站的重構，如今重構已經進入了尾聲，並且內部測試也已經通過了一個階段，因此不出意外的話，這個新版本過不了幾天就會出如今你們面前了。

那麼此次重構在系統上有什麼進步呢？

系統架構的大大增強

在過去的一年，SF由於系統的制約發生了很多起宕機事故，有的時候甚至長達數小時之久，大大影響了用戶的體驗，所以在此次重構之初，咱們就下決心從系統層面開始解決這一問題。

截止到2014年9月15日，你們看到的雖然仍是老版本的界面，可是實際上背後已經遷移到新的系統架構上了，而且在這段時間內沒有發生任何訪問故障或者宕機事故，新的系統架構威力初顯。

那麼SF之前的系統架構是什麼樣子呢？個人回答是沒有什麼架構，由於全部的服務都放在一臺服務器上，這個答案可能讓不少用戶大跌眼鏡。

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

雲主機助力

對於SF這樣的初創企業，本身創建數據中心顯然是性價比極低的選擇，可是系統架構的限制又逼迫咱們不得不作出改變。幸虧如今已經進入了雲時代，大量的基礎設施問題能夠交給更專業的服務商解決。通過一系列權衡，咱們最終選擇了青雲做爲咱們的雲主機提供商。

• 4 * web服務器(其中一臺備用)
• 1 * db服務器(得力於ssd和緩存的使用，目前一臺db是能夠知足需求的)
• 1 * 搜索服務器
• 1 * 緩存服務器
• 1 * 後臺服務服務器

通常工做的就是這8臺服務器

更加顆粒化的系統劃分

這一點在web服務器系統的設計上尤其突出，它是全部服務器中壓力最大的，所以機器數量也是最多。可是每臺服務器的配置倒是最小的 單核1G 的實例。

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

1. 節約成本，若是咱們一次性配置一臺多核大內存的服務器，成本是很高的，並且大部分狀況下性能是有浪費的。
2. 增長可靠性，一臺機器掛掉的可能性遠大於多臺機器同時掛掉
3. 方便水平擴展，你可能已經注意到我設計了一臺備用服務器，它平時就是掛在負載均衡節點上的，只是不須要開機（若是不開機是不會計費的），當遇到忽然增長的訪問量時，咱們能夠實時啓動這臺服務器，從而瞬間減輕其它節點的壓力。而訪問量下降後，咱們又能夠關掉它，下降使用成本。

好比上面這張圖就是一次典型的流量衝擊處理，在11點左右網站的訪問量陡增，前端web的負載所有到頂，根據它的增加曲線，咱們判斷這是一次惡意抓取。須要咱們在程序上作防禦的同時在這期間不影響用戶訪問，所以咱們將第四臺備用服務器的配置臨時調整到 4核2G，並在12點左右上線，系統負載立刻恢復到了正常水平

改變代碼上線模式

一般的上線流程就是直接把可發佈的代碼經過rsync之類的同步到線上機器。

在新版的SF中咱們根據PHP的特色改變了這一模式，咱們將代碼打包成phar發佈到服務器，每上線一次就從新打一個包，並將其文件名命名爲版本號，好比14.9.5.195755.1718937340.phar。打包發佈有以下好處

1. 方便管理，只有一個文件，並且傳輸比之前的同步模式更加快速，而且能夠避免當某些文件沒有同步完用戶就來訪問的錯誤
2. 能夠回滾，回滾很是方便，在配置文件裏將須要加載的包版本號改爲你須要回滾的版本便可，能夠快速完成災難恢復

更加好地依賴雲服務

除了咱們的雲主機，咱們還使用了以下雲服務

1. Amazon SES，羣發郵件價格便宜量又足
2. Mailgun，目前咱們的主力郵件發送服務，你們的通知提醒服務都是經過它
3. SendCloud，備份郵件發送服務，主要用來發一些mailgun沒法收到的郵件，好比QQ Mail等等
4. 又拍雲，全部的靜態文件，包括用戶頭像和上傳圖片的存儲
5. NewRelic，程序性能監測

Todo

雖然咱們已經達成了一個milestone，可是後面要作的事情依然不少，而且咱們的後端服務能力會逐漸增強。咱們後續的工做會圍繞數據流的處理展開，咱們也會使用更多的技術來完善咱們的服務，Node.js，Go-lang，Scala，都是咱們的選項。也歡迎在這方面有經驗的工程師加入咱們