傳統(tǒng)IDC跟云服務(wù)的關(guān)系

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

混合IT架構(gòu)的尷尬地位

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

數(shù)據(jù)一致性

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

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

做到敏捷

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

盡可能多的使用服務(wù)

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

監(jiān)控一切

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