前不久，Facebook宣布投資10億美元收購僅成立15個月的移動照片分享應用Instagram，消息傳出時，人們不僅驚嘆于這筆巨額的交易，更為這支13個人的小團隊感到不可思議。Instagram的Android版客戶端發布時，24小時內下載量超過100萬，高峰期達到每分鐘2000次，是下載量最大的Android應用之一。究竟是什么原因讓這支團隊在很短的時間內一鳴驚人?又是什么技術讓他們在巨大的下載量下頂住了壓力?

讓我們回顧一下Instagram開發團隊奉行的3大原則：

1、Keep it very simple(極簡主義);

2、Don't re-invent the wheel (不重復發明輪子);

3、Go with proven and solid technologies when you can (能用就用靠譜的技術);

總而言之，專注于自己的業務和擅長領域，其它事情讓更專業的人去做。Instagram選擇了美國的亞馬遜云計算平臺作為基礎設施提供商，他們部署了數以百計的云服務器和存儲服務，卻只有區區3名工程師負責維護，不需要任何現場人員支持。如果依賴于傳統的IDC服務，光是把這幾百臺服務器托管到IDC機房，就需要數天時間和大量的人力成本。每當發布一個新版本時，Instagram所要做的只是在云計算平臺上開啟更多的服務器，便可穩坐釣魚臺，看著自己應用的下載量節節攀升了。

阿里云彈性計算平臺(Elastic Compute Service，簡稱ECS)面向中國互聯網開發者和站長，致力于為中國的Instagram提供靠譜的互聯網基礎服務。它基于底層的飛天分布式計算系統，結合高性能虛擬化技術，實現了計算、存儲和網絡資源的統一調度和彈性分配。在具體的產品形式上，客戶接觸的是最簡單的云服務器，與物理機無二，沒有任何的使用門檻。由于采用了云計算技術，相比傳統的IDC托管服務，彈性計算在自助管理、資源組合靈活性、基礎環境定制化、數據安全性及硬件資源利用率上都有不小的優勢。

在本文中，我們將和大家分享在云計算平臺上構建高可用、可擴展應用的一些進階技巧。考慮到有些讀者尚未接觸過ECS，所以在進入正題之前，讓我們簡單瀏覽一下ECS的各項特性。

自助管理

ECS在aliyun.com的控制臺中提供了多種用戶自助的操作，例如最為常見的創建、啟動、關閉云服務器，將來還會陸續推出比較高級的快照、自定義鏡像(Image)等功能。回想我們以前遇到服務器不可訪問時，提交工單、電話催促，在經歷漫長等待之后，也未必能夠得到一個滿意的答復。現在，我們可以在控制臺中全程監控和管理每一臺服務器的運行情況，從而做出快速的決定--重啟或者部署新的服務器。

ECS支持目前主流的Windows和Linux系列操作系統。用戶不僅可以使用這些標準的鏡像，還可以在此基礎上修改配置、安裝軟件，創建出自己的鏡像，當要快速恢復基礎環境或者批量部署集群時，自定義鏡像將成為提高運維效率的利器。

下圖簡單地描述了一個自定義鏡像的生產過程：

 

1、使用標準鏡像創建一臺云服務器;

2、用戶登錄云服務器，安裝自己所需的軟件，配置好系統參數;

3、安全關機，然后將云服務器當前狀態存為一個自定義鏡像;

4、隨后，用戶就可以使用剛創建的自定義鏡像啟動更多的云服務器了;

數據可靠性

對于寫入VM磁盤的數據，ECS會實時地在不同的交換機下同步3份拷貝，當集群中的磁盤損壞時，后臺進程也會自動地重建故障磁盤的數據。相比常見的RAID硬件方案，這種分布式存儲系統能夠提供更高的數據安全保障，因為它不受單臺服務器可用性的限制，并且，由于多臺服務器可以并發處理，數據恢復的時間更短。

ECS提供的在線快照功能可以完美地替代傳統的復制備份，它采用先進的增量數據算法，確保做到備份空間和時間的最優化。當用戶數據被誤刪或者系統被病毒破壞時，只需要一個簡單操作就可以瞬間恢復環境。

自動故障恢復

有了分布式存儲的支持，ECS可以提供比傳統主機或VPS服務更高的可用性指標。當一臺物理機損壞時，ECS會自動監測到硬件故障，在第一時間內把云服務器遷移到新的宿主機上，同時硬盤數據保持最后一刻的狀態。 

 

 

圖3 自動故障恢復

從以上介紹可以知道，托管在彈性計算平臺上的應用可以獲得更多的保障，但我們是否可以認為，將應用搬到云計算平臺之后，它就能跑得歡快、永不宕機，還能自動擴展了?答案是NO!

每時每刻，硬盤、主板、電源或者網絡設備都可能突然損壞，甚至整個數據中心發生停電。云計算技術沒有辦法解決所有硬件問題，只是降低了某些故障的發生幾率，例如：

•普通SATA的年損壞率在2~4%，但使用分布式存儲的年損壞率在1‰以下;

•自動故障恢復只是減少了服務器的宕機時間，但不能防止宕機;

如果我們的應用只能跑在單臺服務器上，只能依賴單臺設備的硬件升級才能應付日益增長的訪問量，那么這種應用的宕機是遲早的事。我 們需要從部署架構和應用架構兩個方面來破解這個難題。

#p# 部署架構

既然沒有什么硬件是永不損壞的，我們是否可以用多份冗余的硬件來降低故障的概率?如果挨在一起的服務器被一把火燒掉的可能性太大，我們是否可以把它們分散在不同的集群?如果數據可能被破壞，是否要經常做些備份?… …

把各種故障因素都考慮一遍，我們就得出了一個大致的部署框架：

1、以集群方式提供服務

Web服務器、緩存服務器都是非常適合部署為集群的，單臺服務器損壞不會影響整個網站的訪問。數據庫服務器稍難一些，但它們也提供了主從復制、讀寫分離的解決方案。

2、 將云服務器分布在不同的可用區(Zone)下

不同的可用區代表數據中心里的不同物理位置，同一可用區內的服務器可能同時遭遇網絡設備、電力等故障，因此，把一個集群內的云服務器分散到不同的可用區甚至不同的數據中心(Region)是個明智的選擇。

3、 為Web服務集群配置負載均衡與DNS輪詢

多臺Web服務器可以通過配置負載均衡或者DNS輪詢提供對外服務。

相比DNS輪詢，負載均衡方式會更加靈活，因為它對外屏蔽了服務器的真實IP，當負載均衡資源池內增加或減少服務器時，對客戶是透明的。而DNS存在時延的問題，集群發生調整后，很有可能造成部分用戶在很長一段時間內無法正常訪問網站。

另外，負載均衡能夠跟蹤后端應用服務器的健康狀態，自動排除有故障的節點，避免出現服務時斷時續的問題。

對于特別大的應用，我們推薦使用負載均衡+DNS輪詢的方式，只是這里的DNS輪詢域名指向的是負載均衡的VIP。

4、 實現動態部署

為了應對經常性的業務推廣和可能的DDOS網絡攻擊，實現系統與應用程序的一鍵部署很重要。系統管理員可以根據應用的當前狀態(CPU、內存使用率、HTTP的響應時間等)作出判斷，即時增加服務器，并且快速部署應用程序，頂住突增的業務流量。如果實現得更智能一些，可以在應用服務器內部部署一些監控程序，由主控程序判斷當前整個集群的負載情況，調用ECS API自動增減服務節點。

用一臺主控機去批量操作其它云服務器時，應該盡量地使用一些便捷工具，例如SSH密鑰對，它實現了授權服務器間的免登錄，使得集群管理更加簡單。

5、定時備份很重要

前面說到，沒有什么技術可以保證100%的數據安全，你的數據始終面臨誤刪文件、病毒破壞、程序寫錯、硬件損壞等種種可能的風險。如果你的數據非常重要，請定期備份!在彈性計算平臺上，這件事情相對簡單，快照功能自動完成增量數據備份。然而，單個物理位置的存儲始終會面臨地震、火災等災難的威脅，如果你覺得還不夠安全，或者有異地使用的需要，且能夠承受異地備份帶來的存儲、帶寬等成本，可以自行拷貝數據文件。彈性計算平臺也正在考慮跨機房的容災方案。

6、 將應用程序配置為自恢復的

單臺服務器的硬件故障是常見現象，以現有的云計算技術能力，尚無法做到不影響云服務器的運行，但ECS可以快速檢測到故障特征，并且將云服務器自動遷移到新的宿主機上。這里存在一個問題，雖然云服務器重新啟動了，而且硬盤數據恢復到最后一刻的狀態，但是原先正在運行的應用程序中止了。為了讓你的服務中斷時間盡量地縮短，避免人工的介入，強烈建議將應用程序及相關服務設置為開機自啟動，這樣，你就可以高枕無憂地睡大覺，不用半夜起來恢復應用，盡管只是幾個點擊或者命令操作。

7、加固系統

安全也是高可用的重要前提之一。放在IDC機房中的服務器時時面臨各種惡意攻擊，下圖是我們偶然截取的一個攻擊片段：

 

 

 

圖4 端口掃描攻擊

這臺服務器在循環探測機房中每一臺機器的1433端口，有經驗的讀者很快猜出來了，它是在試探SQLServer服務，一旦SQLServer被攻破，再利用SQLServer管理員的系統權限漏洞，馬上就有一些機器淪為肉雞。

#p#  阿里云彈性計算服務在平臺層面就屏蔽了一些影響范圍很大的惡意攻擊，例如篡改MAC、偽造IP、發送ARP欺騙包等，但用戶的系統還是要遵循一些安全最佳實踐，才能讓自己的系統更加穩固：

1、關閉不必要的系統服務

越多的服務意味著越多的漏洞，特別是Windows共享文件夾、遠程修改注冊表項等服務都存在巨大的風險，如果你的工作不需要這些服務，請馬上關閉。

2、及時升級系統補丁

前段時間爆出的微軟高危RDP漏洞讓很多用戶深受其害，通過一個簡單的Python腳本，黑客就可以直接獲取系統管理員權限或者直接把服務器打至藍屏。不要忽略操作系統廠商的安全警告，一旦遭遇攻擊，將造成不可挽回的損失。

3、開啟系統防火墻

采用白名單控制策略，只開放最小集合的端口。對于數據庫服務器，更要設置IP白名單，僅允許前端的Web服務器訪問;對于Web服務器，只對外開放80端口。

4、修改常見服務的端口

從剛才的攻擊示例看出，黑客雖然漫無目的地掃描同一網段的IP，但攻擊的目標端口只有一個1433，這是SQLServer的默認配置。為了減少這類攻擊，最有效的方式就是修改數據庫、FTP這類常見服務的默認端口，增加黑客掃描的難度。

5、加密數據傳輸

筆者曾經遇到過一個很奇怪的現象，在一臺Windows 2003服務器上，應用的負載很低，但CPU利用率達到了99%，從任務管理器中看到，有無數個winlogon.exe進程瘋狂消耗CPU，當時百思不得其解。一天之后，這臺服務器就淪陷了，我才恍然大悟，一定是攻擊者在嘗試破解密碼。對于這類攻擊，即使調整密碼長度增加破解難度也收效不大，因為攻擊過程會消耗大量的系統資源，正常的業務根本無法進行。何況，現在的服務器計算能力越來越強，一個密碼的安全性實在太低了。

一些加密傳輸方式能夠有效地抵御這類攻擊，也減少傳輸過程中的敏感信息泄露問題。Windows可以配置遠程桌面服務使用SSL傳輸，要求客戶端必須持有證書登錄。Linux則可以使用SSH登錄密鑰對。結合修改默認端口的方式，將使你的系統安全性提高一個層次。

友情提醒：如果你開啟了防火墻，又修改了默認的遠程桌面或者SSH端口，請務必在防火墻中設置這些服務的白名單，否則就悲劇了。

應用架構

要支持上述高可用、可擴展的部署架構，應用程序也要做相應的調整。例如：

•Web應用的無狀態設計

Web應用的諸多因素可能造成系統無法擴展：本地存放的上傳文件、進程內的Session等。以上傳文件為例，假設使用了本地存儲，用戶第一個請求上傳了一個頭像文件，存放在Web-A服務器上，接著刷新頁面，但這個請求被發送到Web-B服務器上，他驚奇地發現：上傳的頭像文件不見了!要解決這個問題，必須把上傳文件存放到共享的文件夾，Web服務器不能保留任何自己的數據(即無狀態)。而對于Session數據，一般的建議是用Cookie代替，或者存放到共享的Session服務器或者數據庫中。

•用分布式服務代替單點的服務

單點就意味著故障，不僅有可用性的風險也有性能瓶頸的問題。常見的單點一般出現在共享文件服務器、Session服務器、緩存服務器、數據庫服務器。阿里云計算平臺提供了一系列分布式服務，是這些單點服務的可行替代方案：

•需要無空間和訪問頻率限制的小文件存儲?用開放存儲服務(OSS)。

•需要可彈性分配存儲空間和IO能力的數據庫?用關系型數據庫服務(RDS)。

•需要海量結構化數據存儲服務?用開放數據表服務(OTS)。

對于平臺暫時不提供的分布式緩存服務，業界也提供了一些解決方案，例如Memcached集群技術，但這也對應用程序的設計提出了更高的要求，開發者必須清楚各種服務的HA原理，還需要了解一致性哈希算法等細節的實現。

■應用的安全不容忽視

安全不僅是操作系統配置的問題，堡壘更容易從內部被攻破，而這個內鬼很有可能就是我們的應用。從概率上說，一個復雜程序會比一個簡單程序多很多漏洞，而Web應用涉及數據庫、應用服務器、緩存等諸多組件，稍有不慎，攻擊的后門就會向黑客敞開。

常見的Web服務漏洞有：

■XSS跨站腳本攻擊

這類Web攻擊最為普遍，一般發生在允許用戶輸入內容的頁面，尤其是提供富文本編輯的模塊。幾乎所有的網站都會被XSS攻擊光顧，但防御這類攻擊也是最為簡單的：限制用戶輸入，并且在頁面輸出內容時對敏感字符進行編碼，相對來說，后者更為重要一些。PHP語言的htmlspecialchars函數、Java Jakarta commons的StringEscapeUtils類都是實現編碼功能的快捷工具。

■SQL注入攻擊

只要應用代碼中存在這樣的SQL：

sql = "select * from User where name='" + name

+ "' and password='" + password + "'";

那么這個應用距離淪陷也就不遠了，攻擊者只要輸入一個值為

”’ or 1=1 or name=’

的name就可以輕易進入你的應用系統。杜絕這類問題的方法有2種：

對輸入的特殊字符進行轉義，例如PHP的mysql_real_escape_string函數;

或者采用參數化的SQL，例如：

sql = "select * from User where name=? and password=?";

result = query(sql, name, password);

后者實現更加優雅，絕對避免了SQL注入的風險，而且在提升數據庫的查詢性能上也會有所幫助。

■ 上傳文件漏洞

這是最為危險的應用級漏洞，特別容易出現在允許用戶上傳內容的網站中。假設一個tomcat搭建的Web網站允許用戶上傳附件，卻忘了限制上傳目錄的可執行權限，攻擊者就可以上傳一個帶webshell的jsp文件，通過訪問這個上傳文件的URL就可以完全控制網站服務器。

一定要取消上傳文件的可執行權限，另外，絕不允許這類文件被當作服務端腳本解析。趕緊為你的網站實施安全策略吧!

■Cookie與傳輸加密

只要會用HttpWatch、Firebug等開發工具，大家都可以看到各大網站的Cookie數據，而這些Cookie正是網站用于鑒別用戶身份的憑證。通過分析Cookie構成，黑客有可能猜測出網站的鑒權策略。要想讓你的應用更安全，可以對Cookie等敏感數據進行加密。如果你的網站還包含在線支付功能，部署帶授權證書的HTTPS是必不可少的，這也是很多第三方支付平臺的強制要求。

綜上所述，雖然云計算平臺提供了更靈活、更穩定的基礎服務保障，但它不足以解決應用的高可用性和可擴展性問題，應用自身必須在架構設計和部署上 充分考慮各種意外情況，才能實現真正意義上的高可用、可擴展 。