心動網路CTO沈晟：「不要神話雲服務」

作者：沈晟 心動網路CTO 已獲授權

今年有兩個之於我關係比較大的項目，一個是「RO仙境傳說」，一個是「去月球」。「RO仙境傳說」是我經歷的第一個出口流量達到萬兆級的項目，運維比較重。「去月球」要對得起原作的口碑和盛名，責任比較大。這樣一來二去，不知不覺中專欄已經斷更近半年。好在近日去月球已經上線，終於可以鬆口氣，更新一下自己的專欄了。

心動網路（833897）作為一間遊戲發行公司，需要常年管理大量伺服器來支撐各種網遊服務玩家，涉及諸多伺服器部署決策。隨著雲計算的興起，心動網路開始越來越多的使用各種雲服務商的產品，也積累了不少經驗。

歷史

最早，心動網路的伺服器以自行採購伺服器硬體託管至IDC數據中心模式為主（後文簡稱 IDC託管）。部分海外業務除了少量海外的IDC託管外，會使用一些Linode服務和零星的AWS服務，由此我們開始接觸雲服務商。

2015年心動做了很多嘗試，包括在合作方的支持下建立了一個小規模的OpenStack集群（對內對外業務中都有使用）。同時隨著雲服務商的爆發，我們也開始使用一些阿里雲、騰訊雲和UCloud的服務。在AWS進入中國時，我們也第一時間啟用了AWS的北京服務區。可以說所有提供過雲計算的服務商，我們要麼上業務要麼評估，基本都接觸了個遍，而且都有一定深度。

問題分析

先說說我們碰到的問題。

問題一：雲計算價格貴，甚至現在仍然非常貴

曝光一下心動使用IDC託管的伺服器成本和算力：心動採購的伺服器中規中矩，例如我們最近採購的配置：兩顆各12 Cores的CPU，開HT可48核，512G內存，12塊硬碟做RAID10，組成24T可用存儲。這樣的伺服器一般可以使用3~5年，平攤到每個月成本不過2千元上下。在IDC數據中心，我們不將伺服器堆疊過密的情形下，託管費用均攤到每台也就每月1千元上下。之於說人員成本，在我們提倡DevOps和充分合理利用供應商支持的背景下，控制的非常好。管理這些設備的核心運維部門也只有3位同學，相對於我們龐大的伺服器數量基本可以忽略不計。（而且我們發現，即使使用雲服務，我們這些運維同學要做的事情也一點都不少。）所以在我們的IDC託管策略下，一台48核CPU 512G內存 24T硬碟的伺服器月使用成本，在3千元左右或更低。

用這個數字來對比各家雲服務商公開的價格，可以發現，接近這個計算能力的雲服務售價，一般都比我們IDC託管貴3-7倍，像AWS這種高端雲服務商的價格還會貴10倍以上。

而且，我們自行搭建OpenStack的過程也讓我們確信，這個成本問題並不是雲服務商給自己留的利潤。而是因為要想建立可靠、彈性和靈活的雲服務，就必須在網路、存儲和各種基礎設施上，投入更高的配置和額外的設備，即使不考慮研發和維護支出，成本也會直線上升。所以價格高，是傳統虛擬雲服務架構的硬傷。（未來的世界應該是屬於容器編排和Serverless Compute的，不過那是後話。）

問題二：同配置下，雲服務的服務能力更弱

只是貴而已？不那麼簡單。雲計算的虛擬化技術，還會在計算能力上打折扣。

首先，在很多雲服務商那裡都提供不了48核、512G內存、24T存儲這樣的配置。而在同樣的核心數時，我們也發現雲上的CPU計算能力和內存性能不如單純的物理機（Bare Metal）。以我們搭建OpenStack時的理解，這還是因為宿主機必須保證一定的資源來管理調度租戶所需的資源，包括保障SDN和分布式存儲的IO性能等，都是宿主機的職責。這是虛擬化的必然開銷和損失。如果買的不是獨享的配置，還會面臨主機資源會被其他租戶爭搶的問題。

更有甚之，存儲I/O、網路吞吐能力PPS（Packets per Second）和帶寬這些指標，不只是有性能折扣，為了避免多租戶爭搶，還會有配額限制，而且這些限制都遠低於物理機（bare-metal）。

問題三：所謂彈性，都是有限度的

雲計算大為鼓吹伸縮性的優勢，聽上去很美好。但事實上，所有的彈性都是有限度的。雲服務商的計算能力也是靠一個個數據中心、一台台伺服器堆上去的。當你有100-200台高配置伺服器資源需求時，最大的雲服務商也不能保證第一時間滿足。即使在谷歌雲和AWS上，可購買的資源也是有配額的。如果超過一定量級，就要開工單申請，還不一定能被批准。國內服務溝通上好一點的，會先來和我們打招呼，讓我們有大量需求時，盡量提前1~2個月提出來，讓服務商做些準備，免得真上業務時創建不了實例。

即使如此，我們還是碰到幾次，雖然提前打了招呼，到點還是拿不到計算資源，一台台買好的伺服器就是啟動不起來的情況。

問題四：雲的高可用容災，不能神話

有的人會說，「即使雲服務成本高些性能弱些，但是技術先進、多地冗餘，高可用和容災能力都是IDC託管比不了的」… 我以前也這麼以為的，但是用了兩年各家雲服務，現在的我只想說：「不要神話雲服務」

我還清楚記得收到第一封來自AWS，通知實例「退休」郵件時的心情：

這裡AWS所謂的「退休（Retirement）」也就是中止實例了，甚至默認分配的公網IP都不一定能保留下來…… 而這樣被「退休」的事，每年都還有4～5次左右。

阿里雲和UCloud碰到同樣情形時略好些，會盡量保留實例，只是做下物理宿主機遷移，短暫甚至不太影響業務。但是在一些大型的規劃變更時，也是有關機時間長達數小時，IP地址也必須更換的經歷。

再舉個例子，各家雲服務商的存儲都是花大代價「兩地三中心」「異地冗餘」保證多個9的。但是今年2月底，亞馬遜 AWS S3 服務也故障了。

所以真的不能神話雲服務。

部署策略

當然，儘管發現了這麼多問題。雲服務還是在很多業務類型上有優勢：

適合小於一個託管機櫃的業務

IDC託管的規劃配置比較高，對於低負載的業務來說，會造成比較多的資源浪費。

適合快速成長中的業務

成長特別快，難以預估峰值時間點和量級的業務，在IDC託管部署流程上，是缺乏靈活性，會受到拘束。存在IDC託管部署跟不上業務發展的風險。這種業務，更適合使用雲服務。

適合對成本不敏感的業務

霸道總裁不需要解釋。

適合缺乏運維能力的團隊

IDC託管需要自己搭建資料庫等服務環境，出現問題時輔助工具少，修復周期長，確實更需要有豐富經驗可以信賴的運維團隊。如果團隊中沒有這樣的成員，就存有風險了。

適合責任重大（不敢自己背鍋）的業務

當出現事故時可以對業務說，是XX雲的鍋…… 雖然我個人並不認可這個思路，但是我相信這在有些公司是客觀存在的。

所以，儘管雲服務成本比IDC託管高，性能比IDC託管差，但通過有策略的部署，將上述幾個類型的業務部署到雲服務商，還是能發掘很大價值。

遊戲業務和互聯網業務不同，在大尺度下業務負載曲線模型比較穩定，類似下圖。而且大部分業務負載都會隨著時間推移進入穩定期。

因此，如果我們按業務預估峰值去準備IDC託管資源，那麼在峰值過後，必然會造成計算資源的閑置。這時一旦沒有新的業務上線，這些計算資源就會浪費。

所以我們心動遊戲業務的上雲策略，根據業務特點不同分為兩類。一類是針對研發中和測試期間的遊戲項目，鑒於負載低變化快，會優先使用雲服務，利用雲服務商的靈活性。

另一類是正式上線有壓力預期的業務。對於這類業務，我們會將雲服務商的計算能力作為彈性池。具體而言，就是對長期均線以下的計算負載部分，安排使用IDC託管資源提供服務。而對在彈性峰值的負載部分，盡量利用雲服務商的服務能力來支撐。

在這樣的策略下，讓IDC託管承載業務穩定期的負載，可以獲得最低的運維成本。同時充分利用雲服務的彈性，支撐高峰期業務，使我們在成本和靈活性之間獲得了一個平衡。

（文中數據均經過加擾處理，僅用於輔助說明推論過程，請勿用於財務投資參考）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！