傳統IDC跟云服務的關系

傳統IDC作為互聯網的基礎平臺為其服務了幾十年，可是對IDC的使用從來沒有像今天這樣使用了互聯網思維。云時代，服務商賣給企業的不只是場地，機柜，電。。還有一整套采用互聯網思維來使用它們的解決方案，所以通常我們會覺得云服務“哪兒哪兒都要花錢“，所以有實力的公司會搞“私有云“。

混合IT架構的尷尬地位

隨著云服務的逐漸完善，如果我要做一個產品，必然會去選擇云服務提供商，因此也就不會有混合IT架構這個概念了，因為這個概念通常存在于使用傳統 IDC的公司向云服務過度的一個中間狀態。也對運維部門是一個極大的考驗，因為要在一個新的環境建立產品運行環境，還要保障產品速度，各種轉換率不會因此降低。

數據一致性

混合架構有兩種方式，一種是備份機房，機主機房出現比較大的故障，可以將流量切至備用機房，一種則是雙活，即兩個機房同時為用戶提供服務。無論是哪種方案，都需要兩個機房之間的網絡延遲在可以接受的范圍內，一般通過專有光纖來解決，云服務商通常會提供這種專有光纖的接入(比如AWS的Direct Connect服務)來打通實體機房與云服務的網絡環境，我們可以利用它來做到數據的同步。

有了良好的網絡環境，如何實現數據同步同樣是一件及其困難的事情，比如數據庫，就需要用戶寫數據的時候往兩個機房各寫一份，比較普遍的做法是采用消息隊列，將用戶寫的數據先排進隊列，然后在開啟兩個隊列對不同機房的數據庫進行寫操作。 另外是緩存，如果用戶訪問新的機房，由于新的機房沒有緩存，則會出現新的機房數據庫被打爆的風險，比較簡單的做法是通過在請求包設置cookie用以標記是否是老用戶然后負載均衡層判斷，含有次cookie的轉發至老機房，沒有此cookie的新用戶則轉發至新機房，然后再將老用戶按照逐漸遞增的方式將流量遷移至新機房，直到新機房緩存完全建立。

做到敏捷

使用云服務的一大優勢便是資源到位速度快，一般情況下，我們可認為云的資源時***大的(如需求特別的，需要跟云服務商單獨談)，許多的云服務商(比如AWS)都會給用戶提供api接口用于開啟資源，并配合cloud-int服務實現資源的初始化，比如我們可以通過腳本的方式調用api快速開啟一臺 webserver，一臺memcache，一臺mysql，并使他們處于不同的集群以及不同的監控組中。

盡可能多的使用服務

云服務商提供的服務不僅僅有虛擬服務器，也會提供諸如負載均衡，分布式存儲，cache，消息隊列等其他的公共服務，將他們恰當的運用到自己的項目中是很有必要的，因為你將在短期內不用擔心他們的擴容問題，比如可以使用AWS的ELB作為負載均衡器對外提供服務，使用S3存儲靜態資源以及log文件 (有個叫s3fuse的項目可以實現將s3作為文件系統掛載到服務器上，可以向訪問本地文件一樣訪問s3上的文件)。

監控一切

在企業架構還處于混合架構的狀態中，我們要對產品的性能做兩套監控系統，另外一個用來專門監控處在云服務上的產品的性能數據，包括性能指標以及業務指標。我們可以通過在前端分流層對流向IDC以及云服務的流量打上cookie或者標記Etag，然后再log分析的時候便可以出兩套數據，用于對比，隨時對云服務進行優化或者技術決策，可以采用grafana做成類似如下的圖標用來實時觀測數據。