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

• Keep it very simple（極簡主義）；
• Don’t re-invent the wheel （不重複發明輪子）；
• 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簡單地描述了一個自定義映象的生產過程。

圖1 自定義映象

• 使用標準映象建立一臺雲伺服器；
• 使用者登入雲伺服器，安裝自己所需的軟體，配置好系統引數；
• 安全關機，然後將雲伺服器當前狀態存為一個自定義映象；
• 隨後，使用者就可以使用剛建立的自定義映象啟動更多的雲伺服器了。

資料可靠性

對於寫入VM磁碟的資料，ECS會實時地在不同的交換機下同步3份拷貝，當叢集中的磁碟損壞時，後臺程序也會自動地重建故障磁碟的資料。相比常見的RAID硬體方案，這種分散式儲存系統能夠提供更高的資料安全保障，因為它不受單臺伺服器可用性的限制，並且，由於多臺伺服器可以併發處理，資料恢復的時間更短。

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

自動故障恢復

有了分散式儲存的支援，ECS可以提供比傳統主機或VPS服務更高的可用性指標。當一臺物理機損壞時，ECS會自動監測到硬體故障，在第一時間內把雲伺服器遷移到新的宿主機上，同時硬碟資料保持最後一刻的狀態。如圖2所示。

圖2 自動故障恢復

從以上介紹可以看出，託管在彈性計算平臺上的應用可以獲得更多的保障，但我們是否可以認為，將應用搬到雲端計算平臺之後，它就能跑得歡快、永不宕機，還能自動擴充套件了？答案是NO！

每時每刻，硬碟、主機板、電源或者網路裝置都可能突然損壞，甚至整個資料中心發生停電。雲端計算技術沒有辦法解決所有硬體問題，只是降低了某些故障的發生機率，例如：

• 普通SATA的年損壞率在2%~4%，但使用分散式儲存的年損壞率在1‰以下；
• 自動故障恢復只是減少了伺服器的宕機時間，但不能防止宕機。

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

部署架構

既然沒有什麼硬體是永不損壞的，我們是否可以用多份冗餘的硬體來降低故障的概率？如果挨在一起的伺服器被一把火燒掉的可能性太大，我們是否可以把它們分散在不同的叢集？如果資料可能被破壞，是否要經常做些備份？……

把各種故障因素都考慮一遍，我們就可以得出下面這個大致的部署框架。

以叢集方式提供服務

Web伺服器、快取伺服器都是非常適合部署為叢集的，單臺伺服器損壞不會影響整個網站的訪問。資料庫伺服器稍難一些，但它們也提供了主從複製、讀寫分離的解決方案。

將雲伺服器分佈在不同的可用區（Zone）下

不同的可用區代表資料中心裡的不同物理位置，同一可用區內的伺服器可能同時遭遇網路裝置、電力等故障，因此，把一個叢集內的雲伺服器分散到不同的可用區甚至不同的資料中心（Region）是個明智的選擇。

為Web服務叢集配置負載均衡與DNS輪詢

多臺Web伺服器可以通過配置負載均衡或者DNS輪詢提供對外服務。DNS輪詢，負載均衡方式會更加靈活，因為它對外遮蔽了伺服器的真實IP，當負載均衡資源池內增加或減少伺服器時，對客戶是透明的。而DNS存在時延的問題，叢集發生調整後，很有可能造成部分使用者在很長一段時間內無法正常訪問網站。

另外，負載均衡能夠跟蹤後端應用伺服器的健康狀態，自動排除有故障的節點，避免出現服務時斷時續的問題。
對於特別大的應用，我們推薦使用負載均衡+DNS輪詢的方式，只是這裡的DNS輪詢域名指向的是負載均衡的VIP。

實現動態部署

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

用一臺主控機去批量操作其他雲伺服器時，應該儘量使用一些便捷工具，例如SSH金鑰對，它實現了授權伺服器間的免登入，使得叢集管理更加簡單。

定時備份很重要

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

將應用程式配置為自恢復的

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

加固系統

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

圖3 埠掃描攻擊

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

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

• 關閉不必要的系統服務

越多的服務意味著越多的漏洞，特別是Windows共享資料夾、遠端修改登錄檔項等服務都存在巨大的風險，如果你的工作不需要這些服務，請馬上關閉。

• 及時升級系統補丁

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

• 開啟系統防火牆

採用白名單控制策略，只開放最小集合的埠。對於資料庫伺服器，更要設定IP白名單，僅允許前端的Web伺服器訪問；對於Web伺服器，只對外開放80埠。

• 修改常見服務的埠

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

• 加密資料傳輸

我曾經遇到過一個很奇怪的現象，在一臺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：

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

name就可以輕易進入你的應用系統。杜絕這類問題的方法有2種：對輸入的特殊字元進行轉義，例如PHP的mysql_real_escape_string函式；或者採用引數化的SQL，例如：

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

• 上傳檔案漏洞

這是最為危險的應用級漏洞，特別容易出現在允許使用者上傳內容的網站中。假設一個tomcat搭建的Web網站允許使用者上傳附件，卻忘了限制上傳目錄的可執行許可權，攻擊者就可以上傳一個帶webshell的jsp檔案，通過訪問這個上傳檔案的URL就可以完全控制網站伺服器。一定要取消上傳檔案的可執行許可權，另外，絕不允許這類檔案被當作服務端指令碼解析。趕緊為你的網站實施安全策略吧！

• Cookie與傳輸加密

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

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

作者陳波，阿里雲總監，多年從事SaaS軟體、網際網路、搜尋引擎、雲端計算等技術領域的工作，目前主要負責阿里雲彈性計算平臺底層技術研發，涉及虛擬化、負載均衡及雲引擎等雲端計算產品。

本文選自《凌雲》雜誌第2期，更多精彩內容敬請關注《凌雲》專區