AWS云的設計模式與實踐

作者 丁建

本文根據(jù)歐特克中國研究院（ACRD）高級軟件工程師丁建在2014年6月7日的QClub活動分享內容整理而成。

過去一些年來，云計算逐漸發(fā)展起來，有人開始為云計算的設計總結可復用的模式，目前形成了不同的流派。

所有流派基本都遵循六條原則：

1. 無狀態(tài)，包括無狀態(tài)的鏡像和無狀態(tài)的實例。云上的實例是虛擬化的，很容易被搞壞，所以把需要持久化的數(shù)據(jù)和實例分離，無論是故障遷移、應用擴展還是升級都很容易。

2. 松耦合，包括地緣、平臺、時間、數(shù)據(jù)格式方面的解耦

3. 彈性。層、服務和組件都應該是有彈性的

4. 自動化。一方面可適應頻繁的擴展，另一方面也是避免人工失誤導致的問題

5. 全面的監(jiān)控/日志。線上做debug很困難，需要全面依賴詳細的日志

6. Design for failure。容忍錯誤，快速恢復，將failure當做普通事件處理

設計模式這一概念源自于建筑架構師Christopher Alexander，其目的是通過為特定專業(yè)領域的設計問題的解決方案形成文檔，以形成某一類問題的通用解決方案。這一概念被引入計算機領域后，就有了軟件設計模式這一概念，即針對軟件設計的常見問題提供通用的、可復用的解決方案。

云計算設計模式，即為云計算系統(tǒng)設計領域歸納出一套通用的、可復用的解決方案。目前流傳較為廣泛的云計算設計模式有四個流派，分別來自微軟高級總監(jiān)Simon Guest，cloudpatterns.org在線社區(qū)，德國斯圖加特大學的Frank Leymann教授等人所寫的Cloud Computing Patterns一書，以及AWS的三位日本同仁Ninja of Three。

Simon Guest是2010年微軟關鍵技術人才之一，他所描述的設計模式強調五個方面：可伸縮、多租戶、計算、存儲、通信（網(wǎng)絡）。其他方面大家比較熟悉，這里提到的多租戶主要是指一個應用實例服務多個用戶的場景，每個用戶被授權對應用做一些定制，如界面或業(yè)務流程，但不能動應用代碼。Salesforce就是典型的多租戶模式。

CloudPatterns.org提出的模式是一種通過提問來進展的模式，問題涉及到基礎架構、可擴展的資源池、可靠性與災難恢復、安全、監(jiān)控等多個方面。一個典型的問答流程為：

共享資源的場景

疑問：如何將物理資源的使用率最大化？

問題：將每臺IT資源分配給一個獨立用戶會造成IT資源的浪費。

解決方案：將物理IT資源虛擬化，拆分成更小的IT資源分配給多個用戶使用。

應用：在物理機上創(chuàng)建虛擬機實例，將每一個虛擬機實例指定給用戶，而底層的物理IT資源是多用戶共享的。

涉及的機制：審計監(jiān)控、云存儲設備、云資源使用監(jiān)控、虛擬機系統(tǒng)、邏輯網(wǎng)絡設備、資源復制、虛擬服務器

復合模式：Burst In，Burst Out至私有云/公共云，彈性環(huán)境，IaaS，多租戶環(huán)境，PaaS，私有云，公共云，彈性環(huán)境，SaaS

Frank Leymann教授提出的模式跟上述模式類似，也是以問題作為起點，然后描述背景，最后提出解決方案。比如對于松耦合，提出的問題是：

如何降低分布式應用之間的依賴性以及應用的各個組件之間的依賴性？

背景描述大意是降低依賴性的好處，即可伸縮性、故障處理與升級管理的簡化。解決方案是引入broker作為交互的中轉。

Ninja of Three（簡稱NoT）在2012年提出的AWS云系統(tǒng)設計模式列出了九大類48個模式，九大類分別是基本模式、靜態(tài)內容、批處理、高可用、動態(tài)內容、數(shù)據(jù)上傳、關系數(shù)據(jù)庫、運維、網(wǎng)絡。

AutoDesk主要使用AWS，因此本次分享主要會介紹NoT的設計模式。目前AutoCAD 360、在線渲染、以及Autodesk 360都在AWS上運行。AutoDesk使用AWS的方式是所有的開發(fā)在內部域網(wǎng)絡中進行，源代碼不出域網(wǎng)絡；所有的server都是EC2實例，包括負載均衡、度量、授權驗證都是通過EC2實例完成；監(jiān)控采用CloudWatch；SNS用于做狀態(tài)異常郵件的推送；SQS在進行Scaling的時候啟用；EBS用來存儲Server依賴庫與中間數(shù)據(jù)，比如激光掃描文件，每一個文件都有幾十個G；數(shù)據(jù)庫采用SDB而不是DynamoDB，因為用戶數(shù)量不多，主要是單用戶資源量很大；S3用來做各種各樣的事情，比如客戶端安裝包、補丁、配置文件、日志信息都存在上面，因為它很便宜、帶寬很穩(wěn)定、對并發(fā)訪問的支持很好，這個要好好利用；IAM用于管理資源的可訪問權限，以保證安全性。

VPC目前還沒有使用，因為Autodesk開始用AWS的時候還沒有這個服務（2011年之前），而從非VPC環(huán)境遷移到VPC環(huán)境需要花很多功夫。不過VPC的好處很多，提供了一個簡化、可靠的安全性，所以終歸考慮要上的。

回到NoT的云系統(tǒng)設計模式。首先是基本模式，其中覆蓋了縱向擴展（Scale Up）、橫向擴展（Scale Out）、計劃的橫向擴展、按需擴容、Snapshot和Stamp這幾種。對于每一種模式，NoT列出了該模式的優(yōu)點及相關注意事項。

縱向擴展，即將small的實例換成large（增大）或micro（減少），優(yōu)點是容易操作，缺點是擴展上限受限于該平臺最大能提供的實例資源，而且調整時間在30秒到數(shù)分鐘不等。目前對于應用而言，Scale Up已經不是主流的擴展模式，主要是關系數(shù)據(jù)庫由于難以多機并行訪問而不得不主要從該模式下手。不過有時候，我們可以通過Scale Up獲得更好的經濟性，比如1個large + 1個x-large的組合就要比3個large便宜，效果卻差不多。

橫向擴展，即增加服務節(jié)點數(shù)，好處是無需中斷服務即可完成擴展，而且可以擴展的上限高于Scale Up方案。理想的情況下，CloudWatch可以實現(xiàn)autoscaling，但事實是啟動新的實例是有延時的，這導致該模式對突發(fā)增長起不到什么作用。

相比之下，計劃的橫向擴展更加適合容易預測的服務。比如我們做推廣活動，到了那個時間之前就可以提前把機器都起來warm up，活動開始的時候實例就已經在線上ready了。

我們之所以要把負載均衡放在EC2上自己跑，就是因為我們使用了多種scaling模式：Scale Out、Scale Up和Scheduled Scale，用自己的負載均衡就可以支持多種AMI類型，還可以精準的控制擴展開始和結束的時間——因為AWS是按小時收費的，如果autoscale，結果可能是用了2小時1分鐘，我們不得不花3小時的錢，而如果采用計劃模式就可以避免花這種冤枉錢。另外我們會時不時的把運行了太久的實例踢出去，因為實例運行時間長了之后穩(wěn)定性會變差。

對于靜態(tài)文件模式，NoT列出了Web Storage、Direct Hosting、Private Distribution、Cache Distribution和Rename Distribution等五種模式。我們首先用到Direct hosting，正如上面所說，我們的客戶端安裝文件和補丁文件、用戶配置文件、新版本說明、大文件都是存儲在S3上的。不過除此之外，我們還有一些特別的用法，就是用S3來生成日志數(shù)據(jù)：我們將參數(shù)放在URL當中，以此來傳遞度量數(shù)據(jù)。

查看原文：AWS云的設計模式與實踐