雲計算之路系列博文分享的是我們將網站遷移至雲計算平台的實際經歷，這篇博文分享的是我們在准備遷移至阿里雲的過程中遇到的一個棘手問題。
從春節期間就開始為遷移至阿里雲做各方面的准備工作，這是一個大工程——不是因為復雜，而是因為繁瑣，就像一個人在一個房子里住了5年，然后要搬家。我們采取的策略是螞蟻搬家，先一台一台地以最低配置購買雲服務器，然后一個一個應用地部署、測試。。。等正式遷移前再將雲服務器配置升級上去。
在其間，遇到了各種各樣的問題，遷移准備工作就在解決這些問題中一步一步地前進。今天遇到了一個棘手的問題，而且這個問題很典型、影響大，也得到了阿里雲客服的確認，所以在這里分享出來。
這個問題就是多台服務器帶寬共享的問題。在IDC機房托管服務器時，我們只需根據實際需求購買一條獨享帶寬的線路，而不必關心給每台服務器分配多少帶寬，只要總帶寬滿足需求即可。實際的總帶寬需求會小於各台服務器峰值帶寬需求之和，因為每台服務器不一定在同一時間段達到帶寬峰值。比如有10台服務器，每台峰值帶寬10M，我們不需要購買100M帶寬，可能購買80M就夠了。
但是現在阿里雲的帶寬只能綁定到一台雲服務器，無法在多台服務器之間共享帶寬。這樣，我們只能為每台服務器購買峰值帶寬，根據之前舉的例子，10台服務器就要購買100M帶寬，而如果能共享帶寬，只需要購買80M帶寬，這無疑增加了帶寬成本。
帶寬成本的增加只是一方面問題，更大的問題是我們購買的這些帶寬資源無法彈性分配。比如現在有一台服務器在每一天某個時間段內需要20M帶寬，而這個時間段內，其他服務器需要的帶寬不多，空閑帶寬就能滿足這台服務器的需求。如果這些服務器共享帶寬，我們就無需額外購買10M帶寬。而現在如果使用阿里雲，即使這台服務器一天內只有半小時需要20M帶寬，我們也需要為一天24小時的帶寬買單。雲計算最大的優勢就在於資源的彈性分配，而現在的帶寬分配方式卻喪失了彈性。
再舉一個帶寬資源無法彈性分配帶來弊端的例子，比如在夜里帶寬占用少的情況下，進行數據的異地備份，如果是共享帶寬，我們可以利用空閑帶寬的總和進行異地備份的數據傳輸。比如100M帶寬，我們可以用80M。而現在阿里雲的方式，帶寬只能單獨地分配在每台服務器上，比如100M帶寬，10台服務器，每台10M帶寬，即使某台服務器完全不占用帶寬，我們能用於異地數據備份的最大帶寬只有區區的10M。
這個問題帶來的最痛苦的是什么？還是異地備份，是數據庫的異地備份。由於數據庫服務器只需內網訪問，根本不會為之購買額外的帶寬，只有雲服務器默認的最低帶寬1M可用。異地備份時，只能先將數據庫備份數據先復制到空閑帶寬高的某一台雲服務器上，然后通過這台雲服務器進行數據傳輸。數據庫服務器無法分享總帶寬還有一個弊端，在遷移過程中，可能有一段時間需要讓原先在IDC機房的Web服務器通過外網接口訪問阿里雲上的數據庫服務器，這時數據庫服務器需要不少帶寬。如果帶寬是共享的，就可以用一下空閑的共享總帶寬（訪問量還在原來的Web服務器上）；而現在只能購買額外的臨時帶寬，即使只用1小時，也要購買1個月（在阿里雲上購買帶寬不能低於1個月）。
這是我們目前想到的阿里雲上帶寬無法共享的一些弊端，也是我們雲計算之路中遇到的一個很大的障礙。雖然障礙擋路，但我們不會望而卻步，困難總是有辦法克服的。
針對這個問題終極解決方法是什么？One Server，就用一台服務器，所有帶寬都綁定在這一台服務器上。這樣的話，對這個服務器的硬件配置要求極高，而阿里雲雲服務器的頂級配置只有單個8核CPU、32G內存，遠遠不夠。而本來我們遷移到阿里雲上的想法是“分”，將原來的5台服務器分為十幾台雲服務器，“分”的好處是顯而易見的，可以減少互相之間的影響。
臨時解決方法是什么？endure，忍。為每台服務器單獨購買帶寬，異地備份時將數據分在多台服務器上進行傳輸，在帶寬成本上多一點投入，相信阿里雲會在可以忍受的時間內解決這個問題。
還有其他解決方法嗎？。。。我們會進一步思考，並想方設法盡可能減少這個問題帶來的影響。
路是走出來的，不管遇到多大的困難，我們都會走出自己的雲計算之路！