原書中涉及實操的地方，在本文中被省略。一是篇幅太長，放入文中太過累贅，二是原書成書過早，現在 AWS 的界面早已變化很大，不具備參考性。
第一章 誰在使用雲計算
1、什么是雲計算
雲計算（cloud computing) 是一種基於互聯網的計算方式，通過這種方式，共享的軟硬件資源和信息可以按需求提供給計算機各種終端和其他設備。
雲計算的“
雲”，指的就是因特網。
2、歷史
（1）雲計算元年是何年？
一般認為，亞馬遜 AWS 在 2006 年公開發布 S3 存儲服務、SQS 消息隊列及 EC2 虛擬機服務，正式宣告了現代雲計算的到來。
在 2007 年底，AWS 使用的網絡帶寬就超過 Amazon 網站本身（Amazon 的網絡流量位居世界前 15)，AWS 也是 Amazon 的營業額成長最快的項目。
而如果從行業視角來看，我們也不妨視 2008 年為另一個意義上的雲計算元年。原因是：
微軟在 PDC2008 上宣布 Windows Azure 的技術社區預覽版，正式開始微軟眾多技術與服務托管化和線上化的嘗試；
Google 恰好也在 2008 年推出了 Google App Engine 預覽版本，通過專有 Web 框架允許開發者開發 Web 應用並部署在 Google 的基礎設施之上，這是一種更偏向 PaaS 層面的雲計算進入方式；
國內的雲計算標桿阿里雲也是從 2008 年開始籌辦和起步。
Amazon AWS、Microsoft Azure、Google Cloud 和國內的阿里雲，乃是幾個大廠推出的著名雲計算平台。
（2）為什么 AWS 雲計算服務是亞馬遜先做出來，而不是 Google ？
1、亞馬遜的業務天然對 IaaS 的需求很強烈
亞馬遜的核心業務電子商務有太強的季節性，這在 2002-2003 年已經成為公司越滾越大的年度噩夢。如何有效地配置具備足夠擴展性而且可以持續上線的基礎系統的確是一個迫在眉睫的瓶頸。
2、Google 更傾向於 PaaS
Google 在 docker 流行起來之前十年就開始使用 container 技術了。這也就能夠解釋為什么 Google 在雲計算領域推出的第一個服務就是 AppEngine。
2、IaaS、PaaS、SaaS
雲計算一般分為三個層級，從最底層到最高層依次是 IaaS（Infrastructure as a Service 基礎設施服務）、PaaS（Platform as a Service 平台服務）、SaaS（Software as a Service 軟件服務）。如圖：
IaaS
IaaS（基礎設施服務）是通過因特網，以服務的形式提供運算能力、存儲設備、網絡及其他基礎設施（如防火牆、DNS、Load balancers 等），以前也叫作 HaaS (Hardware as a Service，硬件服務）。
PaaS
與 IaaS 類似，PaaS（平台服務）也是通過因特網以服務的形式提供運算能力、存儲設備、網絡等。但是 PaaS 需要特定的執行環境（runtime environment），也就是說用戶要按照 PaaS 服務提供者的規格來開發、部署，オ能在 PaaS 上面執行。
由於 PaaS 的抽象化程度比較高，所以 PaaS 的部署單位就是一個應用程序而已，而不像 IaaS 是整個機器的映像。
通常 PaaS 服務提供者都會提供開發套件（SDK）、集成開發工具（IDE）來幫助開發應用。
早期的 PaaS 不溫不火（如 Google App Engine），但在后來大發展時代也找到了崛起之道，即不再尋求大一統的應用程序框架，而是更多提供標准的可復用中間件，並與其他 IaaS/PaaS 設施進行組合與聯動。典型的例子包括 API 網關、負載均衡器、消息隊列、泛數據庫類服務等。
SaaS
SaaS（軟件服務）則是完成的應用程序，通過因特網以服務的形式提供給用戶。所以 SaaS 的用戶就是最終用戶（end user）。
web 應用和安裝好的軟件不一樣，用戶只需要 browser 就可以使用 SaaS 的應用（軟件）。
區別：
3、雲計算優點
彈性、可伸縮性
節省時間成本
節省人力成本
沒有折舊
一定的安全性
現在 AWS 希望所有服務都使用新的
訪問策略語言（Access Policy Language, APL），用同一套語法就可以設置所有 AWS 服務的訪問權限。訪問策略語言是一份 JSON 文件，可以很詳細地設置訪問的權限范圍，例如：客戶端的 P 地址、訪問的時間、訪問的資源的名稱（可以用通用字符）。（缺點就是不太好寫。）
4、未來趨勢
（1）混合雲
下面會詳細談到。
（2）垂直雲
典型的垂直雲代表有視頻雲、金融雲、游戲雲、政務雲、工業雲等。
5、使用雲計算的著名公司
Twitter 用 AWS 管理存儲空間，例如使用 S3 來存儲用戶的頭像，以及備份數據。
Netflix 百分之百的運營都在 AWS 上。AWS 能有今天的成就，跟他們 Netflix 盡情折騰是有關系的。說到這個公司的折騰，他們專門編寫了一個內部軟件，叫 Chaos Monkey，這個瘋猴應用會在不定的時間，不定的環節，有意的破壞雲計算系統，好做備災測試。
第二章 雲計算領導者 AWS
1、什么是 AWS
AWS (Amazon Web Services)，即亞馬遜雲計算服務，由亞馬遜公司所創建的雲計算平台，提供許多遠程Web服務。
AWS 通過 ISO27001 認證，在系統安全和管理上面有一定的水平。
2、AWS 主要業務
你可以選用你需要的 AWS 服務，去組合出適合你的軟件架構。
以我的經驗來說，開發一個完整的網絡應用大約需要 3、4 種服務，如果架構復雜一點的話，7、8 種也足夠了，所以 AWS 確實能夠滿足開發的需求。
3、如何開始使用 AWS
（1）為什么要有 地區 和 所在地
地區（Region）是地理上分離的大區域，例如美國東部（us-east-1) 或歐洲西部（eu-west-1)。
所在地（Availability Zone - AZ）則是在地區里面的數據中心所在的代號，例如“美國東部-1a”（us-east-1a）、“歐洲西部-1a”（eu-west-1a）。
（1）容災
例如：所在區（AZ）在物理上獨立的意義是：獨立的機房，獨立的供電系統，獨立的 ISP 接入系統等。這保證在一個 AZ 完全掛掉的情況下（比如電力故障，網絡故障，甚至修路施工隊的愚蠢的「實習生」挖斷了光纜導致的 ISP 故障等），你的應用在另一個 AZ 還能正常使用。
（2）安全
例如：不同的所在區（AZ）就好像被隔離的沙箱，可以保證一定的安全性。還可以通過 IAM（Identity and Access Management）對不同 AZ 的EC2 實例上運行的應用程序提供安全憑證。
（3）性能
例如：不同的所在區（AZ）的EC2 虛擬機之間，可通過內部 IP 地址訪問，提高傳輸性能。
1、建議盡量把 EC2 的虛擬機放在同一個所在地。
2、建議能用內部 IP 地址就盡量使用內部 P 地址。否則可能會收費。
（2）開始使用
1、網絡服務（Web Services）接口
通常是同時提供 SOAP 和 REST 兩種，另外還有一種類似 REST 的網絡服務接口，叫作 Query AP，是把參數都使用查詢字符串（query string）傳送。
響應數據都是用 XML 格式。
2、AWS Management Console
即瀏覽器上的網頁。
3、EC2 API Tools
可用來操作 EC2 的所有功能，是我最常用的工具。
4、AWS SDK
例如 for IOS or Android 的 SDK。
（3）注意事項
AWS 為了維持一定的服務質量，通常都會限制每個請求可以占用的時間，比如說 S3 或 Simpledb 如果請求的時間太長，會直接響應錯誤。
另外，為了應付可能的網絡瞬間斷線（不論是 AWS 內部或是因特網），有時客戶端會收到狀態碼“500 Internal Server Error”或是“503 Service Unavailable”，通常這些錯誤都是可以重試的。重試的邏輯最好是用所謂的 exponential backoff（指數地等待），也就是每重試一次，應該要等久一點，才能再重試。使用 “exponential backoff” 可以讓我們的應用程序避免受到單一錯誤的影響，最好是再配合異步的作業流程，讓終端用戶可以不用一直等待結果。
一般的公式是，第 n 次重試的時候，在 0~2"-1 之間，隨機選一個數字作為等待的時間。比如說，我的單位用 100 毫秒（millisecond），也就是剛剛的結果乘以 100 ms，第一次重試的時候，我可以在 0~100 之間選一個毫秒，第二次重試，就是 0~300 之間選毫秒，當然你可以選適合的單位，但是重試要有一個極限，例如限制最大重試次數。
第三章 AWS上手必備工具
略
第四章 AWS基礎：S3與雲端存儲服務
AWS 跟隨了計算和存儲分離的先進理念。
以存儲功能來說，AWS 有 S3 (Simple Storage Service，簡單存儲服務）、Simpledb（簡單數據庫）及 RDS (Relational Database Service，關系型數據庫服務）可以用。
EBS 雖然也是存儲功能，不過是專屬於 EC2 的。
區別：S3 提供的是像文件一樣的一般性存儲功能，而 Simpledb 是非關系型的數據庫，RDS 則是 AWS 提供的關系型數據庫服務。
1、簡單存儲服務：S3
（1）適用場景
不論你做什么樣的網絡應用，幾乎都會碰到一個常見的使用情境，就是訪問動態產生的數據。比如說，存儲用戶上傳的照片，在網頁上展示出來，或是讓用戶上傳 PPT 文件，然后轉成網頁讓人觀看，或是存放每天爆增的日志文件或備份文件。這些使用情境通常有一個特色，就是你不知道數據量會增長得多快。
以標准存儲來說，S3 的持久性（durability）是 99.999999999% (11 個 9），也就是如果你存了 1 萬個對象在 S3, 在 1000 萬年內オ會損失一個對象，可以說是超高的持久性。如果使用低備份存儲來存對象，那持久性是 99.99% (4 個 9），也就是如果你存了 1 萬個對象在 S3， 在 1 年內會損失一個對象。
低備份存儲很適合存儲那些非原始來源的文件，例如圖片文件的縮圖。如果縮圖壞了可以從原圖再產生。因為低備份存儲的收費大約只有標准存儲的 67%，所以如果存儲的數量大的話，用低備份存儲可以省下不少錢。如果這個對象消失了，之后對這個對象的任何操作，S3 都會響應 HTYP 狀態碼“405”（Method Not Allowed），讓我們的系統可以從原始的文件再次產生這個衍生的對象。
（2）基本概念
S3 的兩個組成層次是容器（bucket）和對象（object）。
1、容器
一個容器可以放無限個對象。
容器名稱（bucket name）在 S3 里必須是唯一的（unique），這是因為每個對象都有唯可識別的 URL。一個賬號可以建立 100 個容器，不過一般不需要那么多，多了反而難管理。我建議每一個應用或服務開一個容器就夠了。
因為，和 EC2 類似，S3 的容器也有地區的架構。但和 EC2 不同的是，S3 的容器是全 AWS 有效的，而不是地區內有效的（region specific）。也就是說，如果筆者在“US- Standard”這個地區開一個叫“test”的容器，所有 AWS 的用戶在所有地區就不能再開一個叫“test”的容器了。
2、對象
每個對象大小的限制是 5 TB。
（3）使用
現在選擇地區的條件很簡單，就是盡量和你的主機放在一起。以我們使用 EC2 來說，就是和 EC2 放在同一個地區就對了，因為在同地區內，EC2 和 S3 間的網絡傳輸是不收費的，當然也有低網絡延遲的好處
S3 同時支持“http”與“https”。
（4）對象版本
容器可以設置成記錄對象版本（versioning），主要功能是：避免不小心用相同的對象名稱覆蓋了對象，或是不小心刪除了該對象。我不建議使用“對象版本”的功能來管理對象，最好只用來記錄對象的歷史版本，因為版本識別碼（version ID）是 S3 自動產生的，我們的程序沒有控制權。而且對象的 URL 會多“versioned”參數，自己的系統在操作 S3 對刪除（Delete）也是類似，S3 產生新的版本識別碼，但是沒有對象內容，而是一個“刪除記號”（delete marker）。所以讀取對象，但是沒給版本識別碼，會得到最新的版本。舊的版本還是可以用版本識別碼讀取得到。要永久刪除一個版本，也要在做除操作的時候，指定版本識別碼。
（5）標頭（headers）及其他數據
有一些標頭信息，建議每次在存儲對象的時候，最好要加上去，方便日后讀取。S3 有偷窺（peek）對象的功能，也就是只讀取這個對象的標頭信息。這在對象很大的時候很方便，我們可以先看標頭信息，再決定要不要把這個對象讀取下來。
1、建議添加的標頭：
Content-Length：也就是對象的長度，大部分的函數庫會自動加上去。
Content-Type：對象的類型，是 MIME Type 格式，大部分的函數庫會依附文件名自動加上去，不過最好是自己明確地給定，比較不會有問題。
Cache-Control: HTTP 的緩存控制，一定要明確寫清楚緩存的時間，如果這個對象不能緩存，也要注明不可以緩存。這在網站速度最佳化以及和 Cloudfront 合作的時候非常重要。
2、另外以下這些標頭，可以視需要加上去：
Content-Disposition：如果想要實現用戶單擊鏈接的時候，瀏覽器自動另存新文件，可以加這個標頭。例如設成：“Content-disposition: attachment; filename= test"，Pdf 就會自動存檔成 “test.pdf"。
Content-Encoding：通常用在壓縮軟件壓縮過的對象，需要加這個標頭。例如“Content- Encoding:deflate”。
Last-Modified 和 Content-MD5: 如果正確地更新這兩個標頭（可以只用其中之一），就能夠知道 S3 上面存儲的對象和本地有沒有差異，能作為快速比對版本的用途。“x-amz-meta-*”：用戶自定義的元數據，以“x-amz-meta-”開頭。例如，我可以加上這個對象在關系型數據庫的數據表和識別碼對應，以下的例子，代表這個對象是在“photo”數據表，“id”是 92814：
X-amz-meta-entity: photo
x-amz-meta-entity-id: 92814
（6）訪問控制列表（Access Control List）
容器和對象可以個別設置訪問控制列表，如果對象不設置的話，就會繼承容器的訪問控制列表。
但是不建議對容器設置訪問控制列表，而是直接對對象設置比較好。
（7）對象名稱瀏覽（key listing）
S3 並沒有目錄的概念。
但可依對象名稱來瀏覽，簡單講就是分頁的功能。所以即使不知道對象的名稱，也可以用瀏覽的方式，知道有哪些對象存在於 S3 容器里面。
可以理解成 search + pagination。
（8）多部分上傳（Multipart Upload）
先把大文件分成許多小文件，然后再分別上傳這些小文件。如果一個小文件上傳掛掉了，只要重傳那個小文件就可以了。你甚至可以只擁有一部分文件就開始上傳。
最多可以分成 1024 份小文件。
（9）日志記錄（logging）和范圍讀取（Range）
略
2、簡單數據庫：Simpledb
（1）適用場景
1、非關系型數據庫
簡單數據庫（Simpledb）提供了比 S3 高級一點的存儲服務，提供非關系型數據庫服務。
類似市面上的如 Cassandra、Hbase、Hypertable、COUCHDB、Mongodb。
2、分布式
Simpledb 一樣也是分地區，如果你有用 EC2，通常建議跟 EC2 在同一地區。
（2）數值數據
Simpledb 是沒有數據類別，所有值都是 UTF-8 的字符串。雖然數據庫的讀寫變得很容易，但是在處理數值數據上，應用層要處理更多事。
（3）查詢
每個到 Simpledb 的查詢，在返回結果里面都有一個叫“Box Usage”的數據，這個值表示這次查詢用了多少系統資源。“Box Usage”會被查詢的復雜度和數據的存儲結構所影響，這個值越高，表示這個查詢越昂貴。你可以把它想成是 CPU 利用率，因為這個值不包含存儲和傳輸的資源。
昂貴不僅表示 Simpledb 的運算資源消耗得多，而且 Simpledb 也是用“Box Usage”來收費的。
如果查詢時間超過 5s, 會得到“Request Timeout”的錯誤，這時再重試通常也沒有用，因為這個查詢就是無法在 5s內完成，解決之道是針對査詢去做優化。
空值查詢：
因為空值是沒有建索引的，所以“is null'”是整個 Domain 掃描。如果要用空值的數據很多，又要用來查詢，可以用特別的值存儲為空值，例如：字符串 ”null“。
（4） 數據分割（partitioning）
數據分割也有水平和垂直兩種。
水平分割是指同一種數據存儲在不同的數據庫實體里面，例如把“user”數據表，ID 小於 1000 萬的存在第台，D 小於 2000 萬的存在第二台……
垂直分割則是把不同種數據存儲在不同的數據庫實體，例如把“user”數據表存在第一台，“product'”數據表存在第二台……
垂直分割比較容易做到，而且還能支持原來的關系型數據庫的功能，如聯結查詢。
水平分割就會讓關系型數據庫變得非常不好用了，必須要在應用層去額外處理許多工作，如合並查詢數據、排序的查詢等。
非關系型數據庫通常使用水平分割，因為水平分割能提供最好的機器利用率以及高可用性、高可擴展性。
水平分割的做法常見的有兩種：
1、依主鍵的值的范圍來分
例如，第 0 到 100 萬筆數據存在 A 存儲空間，第 100 萬到 200 萬數據存在 B 存儲空間。
2、是對主鍵做散列函數
例如，有 4 個存儲空間（通常要是 2 的整數次方），先對主鍵做 MD5 計算，再對 MD5 的值對 4 取余數，就可以決定要存到哪個存儲空間。
缺點：最大問題就是存儲空間的數目不能隨意改變，如果要改變，通常代表着要做數據轉移。
（5）最終一致性
Simpledb 是分布式的數據庫，存有多份副本（replicas）。每當有改變值的時候，Simpledb 要同步這些副本。而在一致性上面是用最終一致性（eventually consistent）的概念，也就是允許在某一時間點，集群內會有不一致的數據，但是最終會一致。
最終一致性的詳細解釋可以看本文最后。
如果用戶 A 更新了一筆“user”數據之后，用戶 B 連接到還沒更新這筆數據的 Simpledb 集群節點，會讀到舊的數據。這是一般（默認）的使用情境，叫最終一致性讀取（eventually consistent read)
如果這不適合你的需求，那么 Simpledb 提供了另一種讀取數據的方式，叫一致性讀取（consistent read）。用一致性讀取就不會讀到舊的（stale）數據，但是在延遲（latency）和性能（throughput）方面都比最終一致性讀取來得差。要使用一致性讀取很簡單，只要在讀取的命令加上“Consistentread=true”這個參數就好了。
但即使是一致性讀取，看起來是有點可怕，很容易會把數據弄錯，建議使用 Simpledb 提供了“條件式的更新”的做法。
例如賣商品防止剩余庫存是負數，就可以把條件設為庫存必須>=要買的件數才能修改。
（6）和其他 AWS 服務合作
例如，因為 Simpledb 的值只能存 1KB，所以可以把 Simpledb 當成索引，用來查詢存在 S3 里面的數據。Simpledb 查詢到的 Item，有一項屬性就是指向 S3 的 URL，可以去讀 S3 上的數據。實際上，AWS 的 EMR (Elastic Mapreduce，一種大數據框架）就是這樣使用 Simpledb 和 S3 的。EMR 把日志文件存在 S3, 但是把日志文件的索引寫在 Simpledb，所以用戶能查詢 S3 里的數據。
（7）其他
Simpledb 是沒有數據綱要（schema）的數據庫。
3、關系型數據庫服務：RDS
（1）適用場景
RDS（Relational Database Service）提供在雲端上的關系型數據庫服務（現在只有 MYSQL5.1），你可以把 RDS 看成是特殊化的 EC2, 只提供 MYSQL 的功能。
（2）使用
建議用 INNODB 數據庫引擎，因為支持的特性更多，功能更豐富。
（3）維護
備份分自動備份和數據庫快照。
第五章 AWS 核心：EC2 與其相關服務
EC2 即彈性運算雲（Elastic Computing Cloud)。
AWS 中有很多服務是完全依附 EC2 的，EC2 確實是作為 AWS 的核心服務存在，所以想要真正掌握雲計算 IaaS 的實質，對 BC2 一定要有相當程度的了解才行。
（1）使用
EC2 是用 AMI (Amazon Machine Image）作為模板的。
以面向對象程序（Object Oriented Programming, OOP）來比喻的話，AMI 就是類（class)，EC2 虛擬機就是實體（Instance）。
AMI 有收費也有免費的。
（2）Instance storage（虛擬機存儲）& EBS (Elastic Blocking Store）區別
Instance storage 是 EC2 的 短暫存儲（斷電后即數據丟失）。
EBS 是 EC2 的長期存儲（且可擴充）。
Instance storage 和 EBS 都是完全依賴於 EC2 的存儲服務。
基於上述兩者分別有不同類型的 EC2 虛擬機，即： S3-backed 虛擬機和 EBS-boot 虛擬機。
但這兩者的區別，現在已經沒必要了解了。因為目前幾乎 EC2 都是基於 EBS-boot。
如果想要了解更多，可以看：You Should Use EBS Boot Instances on Amazon EC2
（2）彈性 IP 地址
每個 EC2 虛擬機在開機以后，都會配發一個外部 IP 地址（public IP address），以及一個內部 IP 地址（private IP address）。這兩個 IP 地址，在虛擬機的生命周期里面，可能會改好多次。
使用外部 IP 和內部 IP 有什么差別？
在 EC2 環境內的網絡聯機，最好都使用內部 IP。可以確保聯機不會有較大的延退（latency)。
EC2 虛擬機進入“running”（開機）的狀態時會配發 IP 地址，在每次“reboot”（重新開機），以及“stop”（暫停）再“stat”（啟動）的時候，EC2 虛擬機都會重新配發 IP 地址（外部及內部）。這對於一些公開服務的服務器，例如網頁服務器來說，很不方便，所以 AWS 提供了彈性 IP 地址（Elastic IP addresses, EIP）的功能。
彈性 IP 地址可以讓你申請固定 IP 地址，然后把這個 IP 地址指定給一台虛擬機。 如果那個虛擬機掛掉，可以開另一台虛擬機，然后把這個彈性 IP 地址指定給新的虛擬機。這樣對遠程用戶來說，還是連到同一個 IP 地址，只是服務器已經換了。
彈性 IP 只有外部 IP 地址，沒有內部 IP 地址。
（3）解決利用 EC2 傳送郵件的需求
EC2 的所有外部 IP 地址已經都在反垃圾郵件（anti-spam）服務的策略黑名單（Policy Block List）里面了，所以如果用 EC2 虛擬機去發送郵件，一般是會被退回的。
解決方法就是為郵件服務器申請一個彈性 IP 地址，然后填表格告訴 AWS 這是一台郵件服務器， AWS 會直接去各大反垃圾郵件服務，申請撤消這個彈性 IP 地址的黑名單。
或者，直接使用 AWS 在 2011 年 1 月推出了簡單郵件服務（Simple Email Service, SES)。
（4）新機型
EC2 新機器類型：集群運算虛擬機、集群運算 GPU 虛擬機等……
EC2 新機器類型：集群運算 GPU 虛擬機
集群 GPU 運算虛擬機和集群運算虛擬機類似，都是為了應對大量運算（High- Performace omputing, HPC）的需求。
要利用集群 GPU 運算虛擬機的運算能力，就必須使用 NVIDIA 的 CUDA (Compute Unified Device Architecture） 平行運算架構，開發者可以用多種語言來開發 CUDA 的程序, 如C/C++、Java、Python、Ruby、FORTRAN 等。
第六章 AWS 高級：實現 EC2 部署策略
待寫
第七章 AWS 架構關鍵 1 : 組建高可擴展性系統
1、什么是可擴展性
可擴展性（scalability），是系統的一種性質，指的是投入的運算資源，與能夠得到的結果產出量之間的關系，這個關系會受到輸入工作量的多寡來影響。
以網絡應用來說，可以用每秒的服務請求數（輸入），和每秒可以完成幾個服務請求（輸出）來計算。
對於增加/減少運算資源以提高服務能力有兩種模式：
1、向上延展（scale up）/ 向下延展（scale down），又叫垂直延展（scale vertically）
向上延展是指增加單一節點的運算資源，例如增加 RAM，或是增加機器上的 CPU、網卡。
2、向外延展（scale out) / 向內延展（scale in）
向外延展是指增加更多的運算節點，理論上無限，但是受到通信的限制。
雲計算在這里，可以發揮很大的作用，因為動態調配資源正是雲計算的長處。
比如傳統系統很難實現向下延展和向內延展，因為硬件花費已經支出了。AWS 可以讓你在幾分鍾內減少運算資源，不論是向下延展或是向內延展。
雲計算本身是方便實行高可擴展性的系統架構，但是如果你的系統本身不具備可擴展性，那你就不能指望把系統放上雲計算的環境就自動變成高可擴展性。
2、常見的高可擴展性架構模式
1、使用集群（clustering) + 負載平衡（load Balancing）的機制
2、數據分割（partitioning)：垂直分割（vertical partitioning）+ 水平分割（horizontal partitioning）
3、分布式運算（distributed computing)：如 Hadoop
4、放松一致性的限制（relaxed consistenc）：例如非關系型數據庫
5、異步（asynchronous）及批處理作業（batch)
異步在下面說到消息隊列時還會進一步提到。
3、如何實現有效率同步聯機
一般我們希望系統是無狀態的（stateless），如此一來，節點間不用同步數據，每個服務請求也不用一定找同一台服務器。不過這是理想狀態，實際上真正使用的網絡服務，是很難完全達到無狀態的，所以最好能用以下的策略來有效率地同步聯機狀態（session)：
1、減少聯機狀態（session）的內容
2、使用簡單的數據形態
盡量存簡單的數據形態，如 int、string 等，避免存復雜的對象圖譜（object graph)，因為在同步聯機狀態的時候，序列化/反序列化（serialize/ deserialize）可能會造成大量的額外運算負擔。
3、使用獨立的聯機狀態存儲庫：例如數據庫或是 memcached 集群。
4、AWS 解決可擴展性問題的相關服務
5、負載平衡
（1）在 AWS 上負載平衡的幾種做法
1、循環輪替（Round robin DNS)
2、軟件的負載平衡
針對同一個所在地
3、彈性負載平衡（Elastic Load Balancing, ELB)
針對不同所在地
4、全域服務器負載平衡（Global Server Load Balancing, GSLB)
針對全球范圍。
（1）Round robin DNS
原理：就是在你的 DNS 設置上，把你的對外服務器的 IP 地址都對應到同一個域名上。用戶端在査詢這個域名時，排在第一筆的 IP 地址會一直更換。
缺點：用 Round robin DNS 的缺點還不少，不過主要都是在更改集群節點的時候發生的問題，比如：
1、由於 DNS 記錄有 TTL (Time to live）的設置，用戶端很可能只査詢一次，還沒逾時之前就不査詢了。如果想把一個掛掉的集群節點移出 DNS 記錄，用戶端可能要很久以后才會看到。
2、不光是 TTL，DNS 査詢記錄在很多地方都有緩存，無法單靠設置 DNS 記錄就能有效地更新客戶端的 DNS 記錄。例如 OS 會有 DNS 緩存，Java1.4 默認的行為是永久緩存 DNS 記錄（直到 JVM 終結），瀏覽器也可以有自己的 DNS 緩存。
3、另外的一點，靈活性較差，不能控制用戶端要使用哪一個 IP 地址來聯機。
（2）軟件的負載平衡
許多的網頁服務器或應用程序服務器都有負載平衡的功能，像最常見的 Apache server、Lighttpd、nginx、varnish、Tomcat 等。也有專門的負載平衡的軟件，例如 LVS、Pound 等。
（3）彈性負載平衡（ELB)
當 ELB 分派請求給負載平衡器內的虛擬機時，是完全平均分配給每個所在地的。ELB 不會考慮每個所在地內的虛擬機數量或大小。
所以如果使用多個所在地，要開始使用 ELB 的話，維持每個所在地間的運算資源的平衡是很重要的。最好的做法就是每個所在地，里面有一樣的機器類型和一樣的虛擬機數目，讓 ELB 分配服務請求。
（4）全域服務器負載平衡（GSLB）
全域服務器負載平衡是一個很大的議題，通常需要和 ISP 合作或專門提供這個服務的公司才能達到。目前 AWS 也只有 Cloudfront 能夠達到全域服務器負載平衡的功能，其他像 ELB 也只能達到同一地區不同所在地的負載平衡而已。
6、自動延展（Auto Scaling）
使用 Auto Scaling 的話，一定要會用 Cloudwatch。
在收費方面比較特別，Auto Scaling 本身並不收費，只計算 Cloudwatch 的收費。
（1）自動延展組（Auto Scaling Group)
自動延展組是用來管理自動延展行為的單位，代表着一群在 EC2 上的虛擬機如何增加或減少的規則。和 EC2 的概念一樣，自動延展組也是只在一個地區內有效的。
設置包括：
啟動設置（Launch Configuration）：是開啟 EC2 虛擬杌時所需要的參數。
觸發器（tigger）：這是定義如何觸發自動延展組的延展操作。包括：時間間隔（Period）及突破時間門檻（Breachduration）。
通過 Cloudwatch 作為數據輸入。
延展操作（scaling activities）：是一個獨立的操作，代表對自動延展組內的機器數量的增減。
地區（region）及所在地（availability zone)
設置自動延展的參數，需要更了解你的系統，才能達到好的效果。一般來說太頻繁的增加、減少集群里的節點，很容易會增加額外的負擔，反而拖累整體的性能和輸出量。
（2）重新平衡（rebalancing)
Auto Scaling 會試着把虛擬機均勻地分布到每個所在地。但是，有時候有些所在地的容量（capacity）不夠，或者有的所在地失效，Auto Scaling 可以在不受影響的所在地內開機器，等到原本的所在地恢復正常，Auto Scaling 會自動重新平衡（rebalancing）各所在地內的虛擬機的數目。
重新平衡時，Auto Scaling 會先開新機器，再關掉機器，所以不會影響系統的服務能量。因為是以這個原則來執行重新平衡，所以在重新平衡的時候，有可能會暫超過這個自動延展組所設置的機器上限。這只有在系統已經逼近機器數目上限，而且又需要重新平衡時才會發生。不過，Auto Scaling 有限制，在重新平衡時，不會超過所設置的機器數目上限的 10%。
第八章 AWS 架構關鍵 2 : 異步消息構建策略
1、什么是異步消息傳遞
前面提到，要建立高可擴展性系統很常見的一個做法是，在分布式的系統里使用異步 （asynchronous）傳遞消息的架構。
異步的好處是能讓用戶端不用一直等待回應，也讓服務端有機會調節運算的資源。
缺點當然就是比同步的系統還要復雜。
2、消息導向中間件
“消息導向中間件（Message-oriented middleware, MOM)，又叫面向消息的中間件，是支持在分布式系統之間發送和接收消息的軟件或硬件基礎結構。基於 MOM 的系統允許通過異步交換消息來進行通信。
它的發展很早，所以市場上有很多商業產品，像 IBM MQ、Microsoft MQ，開放源碼的產品也不少，像 Apache Activemq、Apache Qpid、Rabbitmq。
“消息導向中間件”的標准大多是產品制定的，像 IBM MQ、Microsoft MQ、JMS 都自有一套標准，公開的也有 AMQP (Advanced Message Queuing Protocol）標准。消息傳遞發展到現在有所謂的 “企業服務總線”（ESB）及“服務導向架構”（SOA）等延伸的概念。
3、消息導向中間件 傳遞消息的模式
1、點對點模式（Point to Point）
2、發布與訂閱模式（Publish and Subscribe）
詳細見下圖。
目前 AWS 有兩個服務是作為消息傳遞的用途：
1、SQS (Simple Queue Service）的模式是點對點。
2、SNS (Simple Notification Service) 就是發布與訂閱。
4、AMS 的簡單隊列服務（SQS)
簡單隊列服務（Simple Queue Service, SQS）基於點對點模式（Point to Point）。
優點：分布式
缺點：
1、沒有公開標准：移植性差。
2、因為基於分布式，所以不保證“先進先出”。
3、對於多個分布式節點，用取樣（sampling）的方式讀取消息。所以你不能預期，明明已經寫入隊列的消息，馬上就能讀得到。
4、因為基於分布式，有可能拿到已被刪除的消息。不過也可以解決。就是設計你的系統，能夠接受同一個消息多次，而不會有數據錯誤，也就是實現“冪等函數”（idempotent function）。
5、單條消息的最大限制為 8 KB。如果消息的大小超過就必須把內容先存到別的地方了，例如 S3 或 Simpledb，然后把真正內容的 URL 寫在消息里面，再傳出去。
（1）消息與消息隊列
Queue URL：這是在建立新的 Queue 的時候，會產生代表這個 Queue 的 URL。
控制 Queue 的權限，是使用 AWS 的訪問權限策略語言（APL）來描述的。
消息識別碼（Message ID）：是 SQS 給每個消息的識別碼。
（2）消息被讀並處理
接收存根（Receipt handle）：每次成功讀取一個消息時，SQS 會發一個接收存根給你。這個接收存根代表一個讀取消息的操作，之后要刪除或修改這個消息，都要使用接收存根。也就是說不能知道消息識別碼就把這個消息刪除，而是一定要先讀過才行。每次讀消息拿到的接收存根都不同，但是只有最新的可以成功地刪除或修改消息。
在一般的消息導向中間件系統里，也有類似的做法，就是接收者要回復
確認信號（ACK），消息中介者才把消息從隊列里刪除。
（3）消息被讀卻遲遲不被處理
為了避免一個客戶端把消息讀出來之后，一直不處理這個消息（通常是掛掉了），例如上面說的不拿着接收存根去處理該消息（或者不回復 ACK），造成其他用戶端不能處理這個消息，所以 SQS 有“讀取逾時”的做法。消息在變成不可讀取之后，在“讀取逾時”（Visibility timeout）內（默認為 30 s)，這個消息不會被讀取到。但是如果超過“讀取逾時”，這個消息還沒被刪除，那 SQS 會把這個消息再變成“可讀取”（Visible），讓其他用戶端有機會可以讀到這個消息。
在實踐中會發生這樣的事，就是如果一個消息還處理沒完，但是“讀取逾時”快到了，又不想放棄，這時候可以延長“讀取逾時”。一個消息的“讀取逾時”最長只有 12 個小時，不可以再延長了。
（4）消息一直沒被讀
如果這個消息待在隊列里太久（最長 14 天）, SQS 也會刪除它。
5、AMS 的簡單通知服務（SNS)
SNS (Simple Notification Service) 基於發布與訂閱模式（Publish and Subscribe）。
SNS 目前支持以下的訂閱后的通知方式：
E-mail、HMIP、HTTPS 、SQS。
第九章 AWS 架構關鍵 3 : 高可用性的雲計算
1、什么是可用性
可用性（availability）的計算方法是，在一段時間內（通常是一年），系統可以被使用（uptime）的總時間的比例。
以一年的時間來計算，如果可用性是 99.9% (3 個 9），那么系統離線（downtime）的總時間就是 8 小時多，如果可用性是 99.999% (5 個 9），那么一年只能離線 5 分 15 秒。
2、CloudFront
為了讓客戶端能夠更快地下載數據，AWS 提供了 CDN (Content Delivery Network 內容傳遞網絡） 服務，叫 CloudlFront。
（1） CDN
邊緣服務器在 CDN 里叫邊緣地點（edge location），當客戶端向 Cloudlfront 請求一個文件時，Cloudfront 會決定哪一個邊緣地點去服務這個請求最快。
如果這個邊緣地點沒有客戶端要的那個文件時，邊緣地點就會去來源服務器，把該文件抓下來，並且在這個邊緣地點存儲一份，也就是緩存。下次有用戶來這個邊緣地點要這個文件時，就會直接從邊緣地點傳遞給客戶端。
放在邊緣地點的文件，默認是存儲 24 小時。如果文件逾時（expiration）之后，當下次又有用戶請求這個文件時，邊緣地點就會再次去來源服務器讀取一次。
（2） 發布單位（distribution）
發布單位（distribution）是 Cloudfront 的部署單位，代表一個來源服務器和一個 Cloudfront 域名的連接。
發布單位：分“下載”（distribution）和“流”（streaming distribution）兩種。
來源服務器：可以使用 S3 容器或自定義來源服務器（Custom Origins)。
自定義來源服務器接受來自 Cloudfront 的請求需考慮下面的情形：
Cloudfront 只接收“GET”及“HEAD”服務請求
Cloudfront 忽視查詢字符串（query string，也就是問號后面的東西）
Set-cookie 標頭會被移除，所以不能依賴 cookie 來響應內容。
自定義來源服務器看到的客戶端 IP 是 Cloudfront，所以不能依賴客戶端 IP 來響應內容。
自定義來源服務器給 Cloudfront 的回應（response）還要符合若干的特性：略
（3）服務私有內容（private content)
CloudFront 也可設置服務私有內容。例如用戶要付費之后，オ能取得一個暫時可用的 URL 去下載文件，或只有某些客戶端 IP 地址才能下載。
3、用 Amazon Cloudwatch 監視系統健康
（1）傳統
原理：
監視程序和監視器之間的信息傳遞，一般可以用 SNMP 協議。
收集數據的做法有許多種，一般分成以下 3 種：推（push）、拉（pull）、混合（hybrid)。
用途：
收集系統的信息主要有兩個用途：
1、在系統出現缺失的時候，有機會發出警告給管理人員，快速地反映系統的問題。
2、能展望未來。利用過去的數據，可以得知系統可能潛在的弱點，在問題發生之前，有時間解決它。根據長期的資源利用模式，也可以規划將來系統可以改進的方向。可以說是好處多多。
工具：
傳統最常用的監視工具就是 RRDTOOL 。
（2）使用 Cloudwatch
“基本監視” 免費。
“詳細監視” 收費。
缺點：目前來說，不建議使用 Cloudwatch 來作為完整系統的監視工具，因為有很多局限性。最好自己另外安裝監視工具。如果使用 Cloudwatch 的話，也一定要自己把數據存下來。
第十章 AWS 活用策略 ：企業雲端優化方案
1、數據存儲加密
（1）文件層級
對個別文件做加解密處理，通常是傳到 S3 或 Simpledb 這種存設備上面，麻煩的地方在於自己要個別處理加解密的步驟。有很多開放源代碼（open source）的工具可以用，例如 GNUPG。
（2）文件系統層級
在文件系統層級做加密，因為是透明化（transparently）的，所以存儲的時候不用自己另外處理。工具有Encfs 可以用存儲設備層級。
（3）存儲設備層級
在存儲設備層級做加密，可以使用各種文件系統，當然也可以用在 EBS volumes 和 ephemeral storage 上。工具有 dm-crypt 可以用。
2、安全組（security groups)
（1）功能
1、設置來源的 IP 地址范圍（用 CDR 表示）
使用防火牆（firewall) 的基本原則，就是只開需要使用的 IP 地址和聯機端口（port)。
2、開放 ssh
3、開放 RDP（遠程桌面）
等等
（2）范例
下面是一個常見 web 應用如何設置安全組的范例（見圖）：
“web”安全組開放了80/tcp和443/tcp給全世界(0.0.0.00)
“app”安全組開放了8009/tcp 給“web”安全組
“database”安全組開放了 3306/tcp 給“app”安全組
（3）不建議用 Iptables
一般來說，EC2 的安全組已經夠用了，如果嫌安全組不好用的話，可以自己安裝防火牆軟件，例如 Iptables，但是不建議，原因如下：
1、在 EC2 虛擬機上安裝防火牆軟件，代表所有聯機和服務請求都要經過這台機器，平白增加一個網絡的瓶頸。
2、每一台機器都要去做一樣的防火牆設置，非常煩瑣。
3、一般防火牆軟件是以 IP 地址范國來設置的，但是 EC2 虛擬機的 IP 地址是動態的，增加了設置上的困難和麻煩。如果要自動初始化 EC2 虛擬機，也會增加復雜度。而 EC2 的安全組是以虛擬機所屬的組來套用的，不用管 IP 地址的變動。
4、除非很熟悉該防火牆軟件，否則很容易就弄成自己也聯不進去，只好把那 EC2 虛擬機關掉。而 EC2 的安全組還是可以在 EC2 外面使用 API 修改的。
3、如何善用花在 ANS 上的每塊錢
拿 EC2 的機器為例，有 3 種收費方式：
1、默認就是“On-Demand”，也就是沒有最低收費，開啟就收費。
但是“On-Demand”的費率是最高的。
2、“Reserved Instances”，就是先付一筆年費（有 1 年或 3 年兩種），之后只要開啟 EC2 虛擬機，就會用比較便宜的費率。
所以如果我們有長期使用 EC2 的打算，就一定要優先考慮使用 Reserved Instances 的收費方式。
3、“Spot Instances”，這是非常特別的一種計費方式，簡單來講就是用“競標”的方式購買運算資源。
如果目前 EC2 的運算資源還很多，也就是客戶要求運算資源很少，那就可以用較便宜的價格買到 EC2 的運算資源，但是如果大家都要用，那價格就會上漲。
跟電費很像，價格隨着用電需求變化（例如一年的不同季節，一天的不同時段，定價不一樣）
也就是說，如果有大量的工作，但是並不急着完成。那 Spot Instances 就是好的選擇。
4、用分布式運算處理大量數據
雲端上的 Hadoop: EMR (Elastic Map Reduce)。
待寫
5、虛擬私有雲 VPC
（1）公有雲 & 私有雲 & 混合雲 區別
公有雲不贅述了。
- 成本更低 — 無需購買硬件或軟件，僅對使用的服務付費。
- 無需維護 — 維護由服務提供商提供。
- 近乎無限制的縮放性 — 提供按需資源，可滿足業務需求。
- 高可靠性 — 具備眾多服務器，確保免受故障影響。
私有雲由專供一個企業或組織使用的雲計算資源構成。
- 靈活性更高 — 組織可自定義雲環境以滿足特定業務需求。
- 安全性更高 — 資源不與其他組織共享，從而可實現更高控制性和安全性級別。
- 縮放性更高 — 私有雲仍然具有公有雲的縮放性和效率。
要搭建自己的雲計算環境，現在也有很多項目，大多是開放源碼的產品。例如：Eucalyptus、OpenNebula、Nimbus、Cloud.com、OpenStack。
混合雲通常被認為是“兩全其美”，它將本地基礎架構或私有雲與公有雲相結合。
例如，對於基於 Web 的電子郵件等大批量和低安全性需求可使用公有雲，對於財務報表等敏感性和業務關鍵型運作可使用私有雲（或其他本地基礎架構）。
（2）什么是虛擬私有雲？跟私有雲有什么區別？
私有雲不贅述了。
但虛擬私有雲計算(VPC)並不是一個真正的私有雲，而是公有雲資源供個人使用。所以實際上虛擬私有雲計算是一種混合雲。
虛擬私有雲計算之於公有雲計算有如虛擬私有網絡(Virtual Private Network, VPN)之於公共網絡。
（3）用 AWS 的虛擬私有雲擴張既有系統
一般公司（企業）很可能已經搭建了信息系統，如果想要維持目前系統的運行，又想要利用雲計算的好處，有什么好的做法可以實現？
可以使用 Amazon VPC (Virtual Private Cloud 虛擬私有雲）把現有的數據中心（data center）和 AWS 的運算資源做結合。
VPC 讓你可以在 EC2 上面開一個分離的區域，然后用 VPN (Virtual Private Network）聯機把這個區域和你的數據中心連接。
（4）使用
待寫
其他
根據芬蘭國家廣播公司 YLE 的報導，芬蘭的運輸與通訊部已經把 IMB 寬帶網絡訪問權明定為法定權利。自 2010 年 7 月起，芬蘭所有的人民，都將享有訪問 1MB 寬帶網絡的權利。並且在 2015 年底之前，再把寬帶網絡權利提升到 100 MB。
人民有享受網絡的權利，真好。
拓展
1、RDBMS VS NoSQL
（1）CAP 理論
在理論計算機科學中，影響分布式系統的一項重要理論就是 CAP 理論（CAP theorem），又被稱作布魯爾定理（Brewer's theorem）。根據 CAP 理論，在分布式的系統里，以下 3 種性質，在同一時間里，最多只能滿足兩項：
CAP理論的證明：Brewer's CAP Theorem
數據一致性（Consistency, C）：所有節點的數據在某一時間點是一致的。
可用性（Availability, A)：任一個節點失效不影響其他節點繼續工作。
斷層容忍性（Partition Tolerance, P）：通常發生在網絡斷線的時候，整個系統被分成兩個小系統（partition），也就是有斷層。這時候雖然有很多消息會遺失，但是系統能夠正常工作。
理解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了C性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那么又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質。
（2）ACID & BASE
關系型數據庫強調的是交易（transaction）的 ACID (Atomicity 原子性, Consistency 一致性, Isolation 隔離性, Durability 持久性）特性。
-
A (Atomicity) 原子性
原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。例如銀行的轉賬。
-
C (Consistency) 一致性
一致性也比較容易理解，也就是說數據庫要一直處於一致的狀態，事務的運行不會改變數據庫原本的一致性約束。例如現有完整性約束a+b=10，如果一個事務改變了a，那么必須得改變b，使得事務結束后依然滿足a+b=10，否則事務失敗。
例如從A賬戶轉100元至B賬戶，同時從B賬戶轉100元至C賬戶，但是無論哪一個時間點他們三個的余額總是是保持不變的。
-
I (Isolation) 隔離性
所謂的隔離性是指並發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的。
-
D (Durability) 持久性
持久性是指一旦事務提交后，它所做的修改將會永久的保存在數據庫上，不會再回滾，即使出現宕機也不會丟失。
但是非關系型數據庫強調的是 BASE (Basically Available 基本可用, Soft-state 軟狀態/柔性事務, Eventual consistency 最終一致性）。
說起來很有趣，BASE的英文意義是鹼，而ACID是酸。真的是水火不容啊。
-
Basically Available 基本可用
基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用，支持分區失敗(e.g. sharding碎片，划分數據庫)。
電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
-
Soft state 軟狀態
弱狀態也稱為軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。 -
Eventually consistent 最終一致性
最終數據是一致的就可以了，而不是時時一致。是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。
BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency)，CAP的一致性就是強一致性），也可以采用適合的方式達到最終一致性（Eventual Consitency）。
弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。
放松（強）一致性的要求，可以說是 NOSQL 數據庫為了實現高可擴展性、高可用性的取舍（trade off）了。
通常這不是非常嚴重的問題，“樂觀並行控制”（Optimistic Concurrency Control, OCC）可以幫我們解決一部分的問題。
ACID和BASE代表了兩種截然相反的設計哲學，在分布式系統設計的場景中，系統組件對一致性要求是不同的，因此ACID和BASE又會結合使用。
2、XX 性的匯總對比
（1）可伸縮性 與 可擴展性 的區別
可擴展性（scalability）是系統的一種性質，指的是投入的運算資源，與能夠得到的結果產出量之間的關系，這個關系會受到輸入工作量的多寡來影響。
光投入不行，還得有與之相匹配的產出。
可伸縮性（scalable） = 可擴展性。
（2）可靠性 與 可用性 的區別
可靠性（reliability），為一個服務連續無故障運行的時間，無故障運行的時間越長，可靠性就越高。
只要中斷就會極大影響可靠性。
可用性（availability）的計算方法是，在一段時間內（通常是一年），系統可以被使用（uptime）的總時間的比例。
極端情況下，中斷許多次，但每次恢復的時間極短，可用性也會很高。
在上文說到 CAP 的時候，也提到可用性，即那個 A（Availability）：任一個節點失效不影響其他節點繼續工作。
這個解釋比較專門，不具普適性。