淚說新公司使用雲服務器後構架的不堪歷史

第一階段（3臺）：1測試，1web 1數據庫

這個是雲服務器，配置高的驚人，測試的機子居然和正式的機子如出一轍，只實現了web和數據庫分離的構架
維持了3個月，因爲物理機故障，3臺服務器同時掛掉，網站暫停服務至少一天

第二階段（4臺）：1測試，1web 1數據庫 另外一機房1數據庫＋web

master-slave:
仍是雲服務器，配置仍是高的驚人, 除了另外一個機房實現了web備份和數據庫主從外，跟第一階段沒什麼差異
由於一次數據庫服務器數據頁面錯誤，主庫崩潰，web和數據庫跨機房了

第三階段（6臺）：1測試，1web 1數據庫，另外一項目1web，1數據庫 另外一機房1數據庫＋web

master-master
上一次的教訓是數據庫修復的時候，發現master的數據必須從slave導出來...數據一致性的要求.
痛定思痛，決定上雙master-master，這個時候出現了一個應用層的悲劇，就是多個項目要公用一部分表了，而web卻在另在兩個服務器上 期間爲了解決衝突，把自增id給岔開了

這個階段最大的悲劇在同一個機房內，web＋數據庫沒有備份的，在某次攻擊後，悲劇的發現，web＋數據必須切換到那個備份的機房去了

第三階段...

還在進行中...

推動太困難了，通過2次事故..我有點不想繼續既作開發又作運維的了...出現問題的時候你們說，我不知道啊，服務器不歸我管理，我怎麼操做呢？要講解運維思路的時候你們又不積極

總結

得出的最大教訓就是：雲服務器太不穩定了，要以數量取勝，不能同一機櫃。有一次別人的雲服務器被攻擊，提供商居然重啓了物理機..而後又諸多悲劇出現

最大的感恩就是：學到了不少知識。每次事故服務器我都要被迫親自參與修復，原本不那麼熟悉的，一會兒被強迫作了不少事情

最近這段時間開始測試的東西有：

1. Fabric 用於多項目多服務器的代碼發佈...
2. Atlas 數據庫讀寫分離中間件，從另外一方面說也是屏蔽數據庫服務器差別的中間件，這點認識很重要，若是有3臺web，當一臺出現問題是，3臺的數據庫鏈接都要修改，但有了這個中間件，只要把有問題的offline便可...1分鐘就能搞定

Fabric 已經上線使用，Atlas 上線遙遙無期..不少坑等待被發現

2014年2月8日補充：

今天由於到期，來不及續費，還剩下10個小時的時間，服務器居然自動關機了...還好，是關機而已，不是刪除服務器....坑啊

2014年2月12日補充:

今天新增長2臺服務器，準備內網使用，中國的帶寬真TMD的貴.並非每臺都能10M出口帶寬的..
由於沒有統一的上傳文件和圖片，每一個服務器都把圖片上傳到本身那臺，最近要考慮怎麼把這些圖片整合起來了，由於圖片量比較少，因此準備了一下方案：

1. rsync + crontab
2. rsync + inotify
3. sersync + inotify
4. inotify + svn

不知道你們還有其它方案麼？難點在於多臺服務器之間相互rsync...

再次重申雲服務器的好處：新開服務器幾乎是1小時之內，而後，必定要以數量取勝...

2014年2月13日補充：

今天同一個物理盤所在的雲盤上可能有人大量寫入數據...致使同一個機櫃上的N個機子云盤io 100%... 之前對雲主機都沒怎麼認識，今天真是大開眼界了...

雲盤和雲主機，另外一個大坑就是：天佑同機櫃和同物理機的的人都正正當當，否則，通常的人都不知道問題出在哪裏