原書中涉及實操的地方，在本文中被省略。一是篇幅太長，放入文中太過累贅，二是原書成書過早，現在 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又會結合使用。