云應(yīng)用設(shè)計模式
下面的章節(jié)詳細(xì)介紹了一些設(shè)計模式，這些現(xiàn)有的設(shè)計模式可以有效地應(yīng)用到云服務(wù)應(yīng)用程序設(shè)計中去颅崩。
電路開關(guān)
電路開關(guān)（Circuit Breaker）設(shè)計模式由Michael Nygard所提出，Netflix將它作為云服務(wù)的一部分進(jìn)行了進(jìn)一步的發(fā)展。在該模式下馆蠕，一個“電路開關(guān)”被插入在發(fā)送請求和處理請求的組件之間。就像在一個電路中惊奇，一個開關(guān)有兩個狀態(tài)：閉合或者斷開互躬。當(dāng)電路開關(guān)閉合則整個電路激活，能量被傳輸颂郎；對于軟件來說吼渡，請求被發(fā)送到正常處理它的組件上。當(dāng)電路開關(guān)斷開則意味著正常路徑被打斷乓序，則系統(tǒng)執(zhí)行一個備份的代碼路徑寺酪。電路開關(guān)用于檢測電路中的故障然后使電路倒換到一個安全的備份狀態(tài)坎背。以下條件可以觸發(fā)軟件電路斷開：
一個到遠(yuǎn)端服務(wù)的請求超時；
遠(yuǎn)端服務(wù)的請求隊列滿了寄雀，意味著遠(yuǎn)端服務(wù)不能處理更多的請求了得滤；
這些因素可以設(shè)計一個錯誤率作為閾值，當(dāng)閾值超過時盒犹，電路開關(guān)進(jìn)入到斷開狀態(tài)懂更。
當(dāng)電路開關(guān)斷開，組件轉(zhuǎn)移到備用狀態(tài)急膀，有三種備用狀態(tài)的策略：
失敗透明沮协。通過設(shè)計一個備用API的方式產(chǎn)生一個替代響應(yīng)，例如該方法可以根據(jù)緩存構(gòu)建返回響應(yīng)或者根據(jù)默認(rèn)值返回一個響應(yīng)卓嫂。
失敗靜默慷暂。對請求返回空值。在返回值內(nèi)容對于呼叫服務(wù)并不關(guān)鍵的場景是有用的命黔。
快速失敗呜呐。產(chǎn)生一個包含錯誤碼的響應(yīng)，這意味著呼叫服務(wù)必須處理這些對用戶來說有意義的錯誤悍募。
理想情況下，組件最好應(yīng)該失敗透明洋机，但實際上往往不是總能做到這點坠宴。
注意電路開關(guān)和根據(jù)條件進(jìn)行響應(yīng)（“如果請求超時，則返回錯誤碼500”）并不同：
電路開關(guān)的觸發(fā)條件是隨著時間變化的绷旗，根據(jù)一個滑動窗口喜鼓，而不是一個單一的失敗衔肢；
當(dāng)電路開發(fā)觸發(fā)后會進(jìn)行保持庄岖，備份狀態(tài)會持續(xù)到開關(guān)被重置；
電路開關(guān)的狀態(tài)組件外部是可見的角骤，工具可以看到電路開關(guān)的狀態(tài)以便進(jìn)行故障處理隅忿；
電路開關(guān)可以由組件外部進(jìn)行控制；
在Netflix邦尊，電路開關(guān)周期性地讓部分請求通過背桐，如果請求處理成功，則開關(guān)重置蝉揍，所有的請求都允許通過链峭。下圖描述了電路開關(guān)的邏輯：
Netflix通過儀表盤將電路開關(guān)的狀態(tài)可視化出來。這使得組件狀態(tài)更加一目了然又沾，比傳統(tǒng)的使用異常碼的組件更加容易狀態(tài)可視化弊仪。
下面的截圖顯示了一個電路開發(fā)服務(wù)在儀表盤中可視化的樣子：
** 電路開關(guān)模式 **
以下是電路開關(guān)設(shè)計模式的要點：
優(yōu)點
增強容錯性
對于組件失敗可視化（通過對電路開發(fā)狀態(tài)的可視化）
使用場景
為了減少由于網(wǎng)絡(luò)或者虛機實例失敗造成的超時或者延遲
為了避免錯誤級聯(lián)以及復(fù)雜的上游錯誤處理（失敗透明熙卡，失敗靜默）
請求隊列
請求隊列設(shè)計模式包含一個組件鞭呕，將請求消息（或者任務(wù)）放入一個或者多個待處理隊列中攒发。計算節(jié)點從隊列中取出請求消息進(jìn)行處理。隊列作為請求和處理服務(wù)之間的緩沖區(qū)可以防止重負(fù)載導(dǎo)致的服務(wù)失敗或者超時雇毫。這種模式是生產(chǎn)者消費者或者基于隊列的負(fù)載均衡模式的一個變種曲横。
將請求放入隊列喂柒，可以方便負(fù)載被分布的計算集群進(jìn)行處理。如果一個計算節(jié)點失敗禾嫉，其它的工作者可以繼續(xù)處理隊列中的請求灾杰。這提供了分級的容錯性可以確保云計算應(yīng)用程序的高可用性。
消息隊列可以充當(dāng)閥門的作用熙参，可以通過阻止請求進(jìn)入控制服務(wù)的資源消耗艳吠。如果某個服務(wù)超過了每秒給定的消息配額，可以阻塞后續(xù)的請求進(jìn)入該服務(wù)孽椰。對于進(jìn)入的請求在入隊前可以應(yīng)用性能計數(shù)器昭娩，一旦某一客戶端的請求超過了云應(yīng)用程序的配置閾值，則后續(xù)的消息被阻塞黍匾。在互聯(lián)網(wǎng)應(yīng)用中栏渺，可以給客戶端發(fā)送HTTP 429錯誤碼（含義：請求過多）以及通過報文頭中的Retry-After指示多久服務(wù)無法響應(yīng)客戶端的請求。下圖用Microsoft Developer Network描述了隊列是如何有效地進(jìn)行服務(wù)間的負(fù)載均衡的锐涯。
** 消息隊列模式 **
下面是消息隊列設(shè)計模式的特點：
優(yōu)點
增加容錯性以支持高可用
對于高訪問的API可以提升性能
使用場景
需要管理應(yīng)用程序的故障轉(zhuǎn)移（容錯）
對于高訪問的API降低負(fù)載
將閥門機制作為自動伸縮的替代策略
合并請求
合并請求設(shè)計模式將對同一API的相鄰請求進(jìn)行緩存合并磕诊。例如，播放視頻的網(wǎng)絡(luò)應(yīng)用程序需要從數(shù)據(jù)中心獲得視頻的元信息（例如片長）纹腌，傳統(tǒng)的實現(xiàn)中每個用戶單獨發(fā)送請求獲取視頻的元信息霎终，利用請求合并，一定時間間隔內(nèi)的請求可以并合并成一個升薯，這樣減少了網(wǎng)絡(luò)帶寬消耗以及API的負(fù)載莱褒，使得API端可以水平擴展支持更大量的并發(fā)用戶。
為了合并請求涎劈，對API使用一個代理（Proxy）將給定時間窗（例如10ms）內(nèi)的請求進(jìn)行排隊广凸，周期地將隊列內(nèi)的消息合并成一個請求發(fā)給API。響應(yīng)消息則并發(fā)地分發(fā)給所有請求者责语。這種優(yōu)化對高并發(fā)的請求很有意義炮障。如果隊列中只有一個消息，它也得等夠時間窗的時間長度才能發(fā)送坤候，這會引入一定的延遲可能會影響性能胁赢。一般請求會落在時間窗內(nèi)的任何位置，所以引起的平均時延等于時間窗的一半（對于10ms的時間窗白筹，平均延遲為5ms）智末。下圖給出請求合并的一個例子：
對象變更通知
傳統(tǒng)的緊耦合的軟件架構(gòu)中谅摄，系統(tǒng)組件間的關(guān)系是固定的。例如兩個組件A和B存在依賴系馆，當(dāng)A變化的時候需要通知B送漠，這時A知道B只有一個實例，同時也知道B的位置由蘑。如果B由于某種原因不可訪問了闽寡，A無法將通知發(fā)送給B，這時A必須實現(xiàn)某種機制去處理這種場景尼酿。A和B之間的這種依賴導(dǎo)致了系統(tǒng)存在單點失敗爷狈，影響系統(tǒng)的可擴展性。
分布式系統(tǒng)中如果存在許多這樣的靜態(tài)依賴裳擎，每一個都會降低系統(tǒng)整體的彈性涎永。對該問題的一個解決方式是為架構(gòu)引入冗余，用一對多的關(guān)系代替組件間的一對一關(guān)系鹿响。例如A不再依賴于固定的B羡微，而是存在B的多份實例，任意B的失敗給A帶來的影響可以忽略不計惶我。
對象變更通知模式妈倔，也被稱作觀察者模式，在這種處理模式下使用可以增強系統(tǒng)的彈性绸贡。
該模式下启涯，通知組件（A）實現(xiàn)一個可觀察（Observable）的接口，觀察者（B）通過該接口注冊自己感興趣的變化恃轩。當(dāng)A發(fā)生一些變化，它則將變化通知給所有的觀察者們黎做。觀察者可以通過變化通知消息直接獲取變化內(nèi)容（push mode）叉跛，也可以根據(jù)事件內(nèi)容再去向被觀察對象請求變化細(xì)節(jié)（pull mode）。
云環(huán)境下該模式可以使得應(yīng)用程序具備彈性擴展的能力蒸殿。因為組件不再是緊耦合筷厘，額外的實例可以動態(tài)的添加以處理增加的負(fù)載。這對于計算或者I/O密集型的任務(wù)做并行化很有價值宏所。例如Netflix為了適應(yīng)不同終端設(shè)備和網(wǎng)絡(luò)帶寬酥艳，需要將視頻轉(zhuǎn)換成不同碼率的好多版本。利用對象變更通知模式爬骤，當(dāng)?shù)谝粋€新的視頻加載到存儲時充石，一個代理檢測到存儲設(shè)備發(fā)生了變化則觸發(fā)產(chǎn)生一組轉(zhuǎn)碼任務(wù)去并行處理不同碼率的視頻版本，當(dāng)計算完成霞玄，這些轉(zhuǎn)碼任務(wù)自行關(guān)閉骤铃。
** 對象變更通知模式 **
下面是對象變更通知模式的要點：
優(yōu)點：
提高容錯性
增加可擴展性
更高的資源利用率
使用場景
為了將計算密集型任務(wù)并行化
為了減少單點失敗
為了減少組件間的耦合以便可以替換組件的實現(xiàn)
服務(wù)發(fā)現(xiàn)
在分布式應(yīng)用中拉岁，組件需要知道對端服務(wù)地址才能向?qū)Χ税l(fā)送請求。在傳統(tǒng)的分層架構(gòu)中惰爬，服務(wù)的主機名存在配置文件中喊暖。DNS用來查詢主機的實際IP地址。為了可擴展性撕瞧，IP可以指向一個負(fù)載均衡使得負(fù)載可以分發(fā)給多個服務(wù)實例陵叽。
云環(huán)境具有高度的動態(tài)性，服務(wù)和組件實例不斷的由于負(fù)載的變化或者故障原因而產(chǎn)生和消失丛版。在云中基于DNS的負(fù)載均衡可能會將請求轉(zhuǎn)給不存在或者已經(jīng)失敗的服務(wù)實例巩掺。解決方案是實現(xiàn)一套云服務(wù)的發(fā)現(xiàn)機制，只有正常的服務(wù)實例是可被定位的硼婿。這樣的服務(wù)發(fā)現(xiàn)機制應(yīng)該具備以下能力：
提供給組件一種直接將請求發(fā)給可用實例的方式
支持服務(wù)實例的動態(tài)注冊和注銷
對于給定實例可以查詢它的狀態(tài)
Netflix實現(xiàn)的服務(wù)注冊“Eureka”具備上述能力锌半。它是一個分布的服務(wù)，同時嵌入在應(yīng)用程序的服務(wù)組件和客戶端中寇漫。
如下圖刊殉，Eureka服務(wù)維持了一組健康服務(wù)的注冊列表。注冊的服務(wù)需要定期發(fā)送心跳更新它們的狀態(tài)州胳。如果和已注冊服務(wù)之間連接失敗记焊，則發(fā)現(xiàn)服務(wù)在一個超時周期后將它從注冊列表里移去。當(dāng)新的服務(wù)啟動的時候栓撞，它們向Eureka注冊遍膜，同樣當(dāng)實例終止或者失敗他們自動的從注冊中去掉不會影響別的服務(wù)。注冊機制意味著只有準(zhǔn)備好處理消息的服務(wù)才會在注冊列表里面瓤湘，正在上線過程中的服務(wù)不會瓢颅。
每個客戶端組件內(nèi)嵌了Eureka的客戶端程序，它維護(hù)了一個從Eureka服務(wù)端拷貝下來的注冊服務(wù)的一份緩存弛说。通過這種方式可用服務(wù)的知識在整個環(huán)境中備份著挽懦，這天然為系統(tǒng)提供了容錯性，避免Eureka服務(wù)端故障導(dǎo)致網(wǎng)絡(luò)不可用木人。Eureka客戶端根據(jù)某種算法將請求負(fù)載均衡到不同的處理服務(wù)上信柿，默認(rèn)的負(fù)載均衡算法是輪詢，可以對算法進(jìn)行修改醒第。
實際上渔嚷，Eureka將決定請求發(fā)送給哪一個服務(wù)的決策放到每一個客戶端，將這種行為封裝在客戶端的代碼庫中稠曼，服務(wù)端開發(fā)者則降低了對服務(wù)端不可用的設(shè)計形病。因為注冊列表中的同類服務(wù)會輪流處理請求，Eureka要求服務(wù)是無狀態(tài)的。這是可擴展性和彈性的先決條件窒朋，是云應(yīng)用架構(gòu)的普遍原則搀罢。
因為客戶端組件緩存著可用服務(wù)實例，所以它們能夠在Ereka服務(wù)端故障的時候繼續(xù)運行侥猩。當(dāng)分布式環(huán)境跨越多個數(shù)據(jù)中心或者云榔至，這時網(wǎng)絡(luò)發(fā)生分區(qū)故障后每個區(qū)域的Eureka服務(wù)可以繼續(xù)運行，因為服務(wù)的注冊信息在每個區(qū)域都存在冗余欺劳。
** 服務(wù)發(fā)現(xiàn)模式 **
以下是服務(wù)發(fā)現(xiàn)模式的要點：
優(yōu)點：
提高容錯性
簡化基礎(chǔ)架構(gòu)的管理
簡化動態(tài)環(huán)境的應(yīng)用程序開發(fā)
使用場景：
在需要支持自動擴展的場景
微服務(wù)
微服務(wù)設(shè)計模式中唧取，一個單體（monolithic）服務(wù)的功能被分解成一系列良好設(shè)計的單一職責(zé)的微服務(wù)。例如划提，郵件消息系統(tǒng)中的提供消息創(chuàng)建枫弟、讀取、更新和刪除的消息存儲服務(wù)鹏往，可以將其每個功能分解成一個獨立的服務(wù)淡诗，其中讀取服務(wù)僅提供讀取消息的功能。微服務(wù)有很多優(yōu)點伊履，包含更好的彈性和性能韩容、更高的可靠性以及易于部署。
彈性的提高是因為微服務(wù)下每個小的服務(wù)都可以獨立的伸縮唐瀑。例如群凶，如果消息的讀取遠(yuǎn)大于寫的請求，這時額外的讀服務(wù)可以被創(chuàng)建來消化負(fù)載哄辣。而在原來消息存儲作為一體的情況下请梢，整個服務(wù)都需要復(fù)制，這時水平擴展就會引起不必要的資源浪費力穗。
微服務(wù)簡化了軟件的開發(fā)和部署毅弧。軟件開發(fā)人員可以擁有一個微服務(wù)完整的開發(fā)和獨立發(fā)布的權(quán)利，如果消息讀取服務(wù)的開發(fā)者改進(jìn)了消息的緩存功能当窗，則可以直接將此發(fā)布到生產(chǎn)環(huán)境而不用與其它消息存儲功能進(jìn)行集成形真。這種解耦的特性開發(fā)使得開發(fā)人員可以按照自己的時間表并行工作。
"部署到云上最好的方法是什么超全，最好的方法是編寫可重用的代碼，我們?nèi)绾慰焖夙憫?yīng)業(yè)務(wù)變化邓馒？答案似乎是微服務(wù)嘶朱。通過創(chuàng)建小的獨立的服務(wù)，程序可以專注將一件事做好 - 我們減少了開銷光酣，增加了可伸縮性和彈性疏遏。開發(fā)成百上千的小的程序，去除過多的耦合，促使開發(fā)人員重新審視與重構(gòu)架構(gòu)财异，最終創(chuàng)建可以快速響應(yīng)的倘零、具有彈性的云應(yīng)用程序。"
Michael Forhan, AppFirst blog: “Lessons from Distill”
Netflix已經(jīng)開發(fā)了一套微服務(wù)升級部署的方法戳寸。這種方法中不再一次升級服務(wù)的所有實例呈驶，而是部署新的版本的一個實例進(jìn)行冒煙測試。如果新的版本失敗了疫鹊，對整個系統(tǒng)的影響很小袖瞻，開發(fā)人員可以修復(fù)問題快速的重新部署。如果微服務(wù)的新版本運行正常拆吆，一組新的實例則被創(chuàng)建分擔(dān)現(xiàn)存在實例的負(fù)載聋迎。新的實例會被密切監(jiān)控幾小時以便確認(rèn)沒有內(nèi)存泄露等其它問題。如果發(fā)現(xiàn)存在問題枣耀，則將負(fù)載重新路由回舊的實例霉晕。如果新的微服務(wù)版本最終功能一切正常，舊的實例則會在一定時間后自動關(guān)閉捞奕。Netflix通過持續(xù)交付的方式將這一過程自動化牺堰，從而加快部署，實現(xiàn)了快速迭代缝彬，而且降低了錯誤的可能萌焰。Nerflix采用了一套簡單的哲學(xué)：錯誤不可避免，但是需要能夠快速恢復(fù)而不影響整體服務(wù)谷浅。
微服務(wù)的另一個好處是如果發(fā)生故障扒俯，很容易定位出故障的原因，因為錯誤范圍往往內(nèi)聚在微服務(wù)的邊界內(nèi)一疯，容易定位出哪次升級導(dǎo)致了故障撼玄。
** 微服務(wù)模式 **
下面是微服務(wù)設(shè)計模式的要點：
優(yōu)點：
減少升級部署的負(fù)擔(dān)
減少由于服務(wù)共筑引起的副作用
提高彈性
對于問題根源的可視化程度更高
提高開發(fā)效率
使用場景：
在大的系統(tǒng)中，需要大規(guī)模的彈性和成本效益
為了消除單點失敗
為了改進(jìn)性能
為了支持對關(guān)鍵系統(tǒng)的頻繁升級
服務(wù)無狀態(tài)化
無狀態(tài)要求服務(wù)不保存每個客戶請求之間的客戶端狀態(tài)墩邀，相應(yīng)的每個請求消息必須攜帶服務(wù)需要處理的所有上下文信息掌猛。這一設(shè)計模式對于分布式系統(tǒng)提供了很多的好處，包括：
可靠性眉睹±蟛纾可靠性體現(xiàn)在一個客戶端可以對一個失敗的請求進(jìn)行重試，而不用服務(wù)端重構(gòu)失敗前的狀態(tài)竹海；
可擴展性慕蔚。無狀態(tài)化可以通過幾個途徑提高可擴展性。因為服務(wù)端實例不存儲狀態(tài)斋配，任何實例都可以處理任何客戶端的任何請求孔飒，隨著請求負(fù)載的增加灌闺，在不影響現(xiàn)有實例的情況下可以動態(tài)地啟動其它實例來進(jìn)行負(fù)載分擔(dān)。此外由于服務(wù)端不存儲任何客戶端狀態(tài)坏瞄，服務(wù)的資源消耗相對輕量級桂对，可以提高整體資源利用率使得每個服務(wù)端可以支持更高的請求負(fù)載。
可視化鸠匀。從運維的角度看蕉斜，每個請求和響應(yīng)消息的凈荷中包含了所有交互信息，這使得可以容易使用請求代理等方案狮崩，對請求的語義具有更大的可視化空間蛛勉。
簡單。當(dāng)服務(wù)不再存儲狀態(tài)睦柴，則就沒有必要管理請求在多次事務(wù)間的數(shù)據(jù)诽凌。無狀態(tài)服務(wù)的實現(xiàn)也相對容易，更容易調(diào)試坦敌。無狀態(tài)服務(wù)可預(yù)測性更高侣诵，由于巧合引起的bug也會被消除。
無狀態(tài)服務(wù)的缺點則是消息的負(fù)載會比較大狱窘，因為消息中攜帶了所有服務(wù)端需要處理它的上下文杜顺。然而無狀態(tài)設(shè)計整體帶來的優(yōu)點要比缺點更多。
** 無狀態(tài)服務(wù)模式 **
下面是無狀態(tài)服務(wù)設(shè)計模式的要點：
優(yōu)點：
增加可靠性
增加可擴展性
提高了請求消息管理和監(jiān)控的可視化
實現(xiàn)簡單
相比狀態(tài)敏感的服務(wù)bug更少
使用場景
任何需要高擴展性的分布式系統(tǒng)
配置服務(wù)
傳統(tǒng)應(yīng)用程序的運行時配置通常依靠應(yīng)用的文件系統(tǒng)上的一個多個文件蘸炸。在某些場景躬络，可以對這些文件進(jìn)行運行時修改（也就是說文件被熱加載）。更一般的場景下這些配置文件在應(yīng)用啟動的時候進(jìn)行加載搭儒，這意味著配置修改需要重新啟動或者加載應(yīng)用程序穷当，這時該過程會導(dǎo)致應(yīng)用停機以及付出額外的管理成本。
通常這些配置文件被存儲和管理在應(yīng)用程序本地淹禾，導(dǎo)致應(yīng)用程序部署的每個節(jié)點上都需要冗余地存儲配置文件馁菜。當(dāng)應(yīng)用程序的集群增長，每個節(jié)點配置文件的管理開銷開銷也隨之增長铃岔。
外部配置存儲
將應(yīng)用程序的配置文件持久化在外部數(shù)據(jù)存儲區(qū)中汪疮，為云計算應(yīng)用程序的配置提供一個中心化的管理倉庫。將配置移出本地應(yīng)用實例毁习，可以讓跨越應(yīng)用程序的配置管理和共享變得容易智嚷。外部配置數(shù)據(jù)存儲可以可以在不同的運維環(huán)境中變化。
數(shù)據(jù)庫或者文件倉庫可以提供對配置文件讀取和寫入的最大靈活性纺且。敏感信息如密碼等可以在應(yīng)用程序動態(tài)構(gòu)建的時候動態(tài)注入纤勒，或者通過應(yīng)用程序啟動時動態(tài)加載的環(huán)境變量進(jìn)行加載。下圖說明了外部配置存儲和應(yīng)用程序加載過程隆檀。
運行時重配
良好設(shè)計的云計算應(yīng)用程序應(yīng)該具備高可用性，盡量減少停機時間。任何需要應(yīng)用程序重新部署的配置變化都會增加停機時間恐仑。運行時重配需要應(yīng)用程序能夠檢查配置變更從而在運行時重新加載配置泉坐。
支持運行時重配需要應(yīng)用程序源代碼設(shè)計能夠處理配置變更通知消息。一般這會通過觀察者模式來實現(xiàn)裳仆。應(yīng)用程序向中心配置服務(wù)注冊配置變更消息腕让。當(dāng)通知消息被觸發(fā)，例如新的配置文件上傳歧斟，應(yīng)用程序?qū)⒌玫酵ㄖ@得最新的配置纯丸，將其加載到內(nèi)存。
Apache Zookeeper是Apache軟件基金會用來支持運行時重配的開源項目静袖。ZooKeeper提供了一個集中服務(wù)用來管理配置信息觉鼻、命名、并提供分布式同步和組服務(wù)队橙。ZooKeeper可以被用作共享配置服務(wù)坠陈，也就是用來做集群協(xié)調(diào)。
使用ZooKeeper來存儲配置信息具有兩個主要的好處：
新的節(jié)點可以接收到如何連接到ZooKeeper的指令捐康，然后從ZooKeeper上下載所有的配置信息同時決策它們在集群中的合適角色仇矾。
應(yīng)用程序可以訂閱配置的更改，在運行時允許通過ZooKeeper客戶端獲得最新的配置完成云計算應(yīng)用程序的集群行為修改解总。ZooKeeper運行在稱作“ensemble”的服務(wù)器集群上進(jìn)行應(yīng)用程序的數(shù)據(jù)狀態(tài)共享贮匕，它可以協(xié)調(diào)云計算應(yīng)用程序集群的分布式一致性。
** 配置服務(wù)模式 **
下面是配置服務(wù)設(shè)計模式的要點：
優(yōu)點：
對于配置管理的獨立集中的數(shù)據(jù)存儲花枫；
減少應(yīng)用程序配置管理的負(fù)擔(dān)刻盐；
減少應(yīng)用停機；
應(yīng)用場景：
任何需要應(yīng)用程序配置的分布式系統(tǒng)乌昔；
需要減少停機時間的高可用場景隙疚；
授權(quán)模式
在云環(huán)境下，不能假定網(wǎng)絡(luò)是安全的磕道，因為很多因素都不在應(yīng)用程序所有者的控制下供屉。這意味著第三方可能監(jiān)聽或者重定向傳輸?shù)臄?shù)據(jù)。另外的風(fēng)險是API可能會被多租戶云環(huán)境中的其它租戶訪問溺蕉，或者被外部互聯(lián)網(wǎng)進(jìn)行訪問伶丐。這種暴漏性導(dǎo)致了風(fēng)險，API可能成為DoS攻擊的對象疯特，或者導(dǎo)致信息泄露以及使服務(wù)遭到惡意破壞哗魂。云應(yīng)用程序更容易受到這些攻擊，因為它們是由互相依賴的服務(wù)組成漓雅，每一個網(wǎng)絡(luò)依賴的接口都會增加應(yīng)用程序的風(fēng)險录别。解決方案是為網(wǎng)絡(luò)流量進(jìn)行加密以及為API提供授權(quán)保護(hù)機制朽色。
API授權(quán)
API授權(quán)保證了只有被信賴的API客戶能夠訪問API，防止服務(wù)被惡意訪問组题，還可以支持對不同客戶端分配不同的權(quán)限葫男。例如，一些客戶端僅被授權(quán)只讀權(quán)限崔列，而其它有讀寫權(quán)限梢褐。授權(quán)還可以用來限制哪些客戶可以訪問服務(wù)。例如赵讯，數(shù)據(jù)庫的API可以通過訪問限制來確庇龋客戶端使用合適的數(shù)據(jù)訪問權(quán)限。
應(yīng)用程序通常使用用戶名和密碼來進(jìn)行認(rèn)證边翼。這種方法有兩個主要的問題：
客戶端需要保存用戶名和密碼鱼响，這使得賬戶信息可能被泄露，而密碼機制則是出了名的脆弱的讯私。
管理每個組件的用戶名和密碼增加了復(fù)雜性和管理開銷以及配置錯誤的風(fēng)險热押。
OAuth2.0協(xié)議（RFC6749）引入了基于令牌進(jìn)行訪問控制的概念來解決這些問題。在OAuth斤寇，授權(quán)服務(wù)器給客戶特定的令牌來提供特定的訪問權(quán)限桶癣。
如下圖所示，對于OAuth控制服務(wù)：
客戶端向授權(quán)服務(wù)請求對待訪問服務(wù)的認(rèn)證令牌（1）娘锁；
授權(quán)服務(wù)校驗身份驗證憑據(jù)牙寞，如果有效返回訪問令牌（2）；
客戶端在所有對服務(wù)端的請求中攜帶訪問令牌（5）莫秆；
對每一個請求间雀，服務(wù)端通過授權(quán)服務(wù)檢查令牌的合法性（6）；
授權(quán)服務(wù)對被訪問服務(wù)提供和令牌相關(guān)聯(lián)的一組權(quán)限（7）镊屎；
服務(wù)端使用這組權(quán)限來決定每個請求的操作權(quán)限惹挟，執(zhí)行相應(yīng)的動作然后給客戶端返回響應(yīng)數(shù)據(jù)（8）；
除了在每個請求中傳遞令牌缝驳，為了安全性還會給令牌設(shè)置生命周期连锯。當(dāng)令牌過期后，客戶端使用一個刷新令牌來請求一個新的訪問令牌用狱。
** 授權(quán)認(rèn)證設(shè)計模式 **
下面給出了授權(quán)認(rèn)證設(shè)計模式的要點：
優(yōu)點：
提高安全性运怖；
細(xì)粒度的服務(wù)訪問控制；
適合場景：
對于所有客戶端和服務(wù)端之間的請求夏伊；
云應(yīng)用成熟度評估
云應(yīng)用成熟度模型提供了一個簡單的方法來評估應(yīng)用程序的云成熟度水平摇展，正如Richardson成熟度模型用來評估REST API的成熟度一樣。成熟度模型為提高應(yīng)用程序在云中的可靠性溺忧、彈性以及擴展性提供了演進(jìn)路標(biāo)咏连。
下表列出了四個層次盯孙，Level 3表明最高的成熟度層次，Level0表明應(yīng)用程序還不是云感知的祟滴。
成熟度0：虛擬化級
Level 0 是最低的成熟度層次镀梭。一個用程序只要正常運行在虛級化資源上（例如虛機）上就算是Level 0。應(yīng)用程序的實例從某一鏡像中啟動踱启，或者利用腳本動態(tài)啟動。這種程序往往耦合緊密研底，各組件之間顯式的依賴于彼此埠偿。
成熟度1：松耦合級
Level 1 在 Level 0 的基礎(chǔ)上引入松耦合的要求。松耦合意味著組件不需要和彼此緊密地依賴榜晦。如果一個組件故障了冠蒋，其它組件不受影響，整個應(yīng)用程序依舊能夠正常的工作乾胶。松耦合的組件之間往往通過異步交互抖剿，能讓應(yīng)用程序更容易擴展。
松耦合的另一方面要求組件間提供的接口與具體實現(xiàn)解耦识窿，服務(wù)可以透明地從一種實現(xiàn)變更到另一種實現(xiàn)或者同時支持多種不同的實現(xiàn)斩郎。
將計算和存儲分離也有利于實現(xiàn)松耦合。通過將計算和存儲分離喻频，應(yīng)用程序不再受低層存儲機制的影響缩宜，使得存儲可以獨立地不受計算資源約束地去擴展。這對于Level 2中應(yīng)用程序可以運行在不同云基礎(chǔ)設(shè)施上的能力來說至關(guān)重要甥温。這里將計算和存儲解耦锻煌，不僅僅指服務(wù)所消費和管理的數(shù)據(jù)存儲，還包括log和配置數(shù)據(jù)等各種存儲機制姻蚓。
成熟度2：抽象級
該層次引入應(yīng)用程序可以運行在不同云計算基礎(chǔ)設(shè)施上的能力宋梧。這是個挑戰(zhàn)，因為現(xiàn)今主要的云計算平臺對于相同服務(wù)的接口和相同虛機鏡像的格式都是不同的狰挡。這限制了云計算應(yīng)用程序可以在不同云提供商的平臺上運行遷移捂龄。工程師必須實現(xiàn)一層云隔離抽象層，使得應(yīng)用程序?qū)嵗梢赃\行在任何虛擬化基礎(chǔ)設(shè)施上且功能正常圆兵。這是個額外的工作跺讯，需要仔細(xì)評估成本/受益。這項工作帶來的收益是應(yīng)用程序不再和供應(yīng)商的特定接口綁定殉农，避免了供應(yīng)商鎖定刀脏，為運行時服務(wù)遷移提供了可能性。
除了與基礎(chǔ)設(shè)施解耦超凳，Level 2級別的應(yīng)用程序不應(yīng)該依賴特定的服務(wù)實例的有效性愈污，完全和其它服務(wù)的故障是隔離的耀态。應(yīng)用程序和它們的用戶對于應(yīng)用程序的組件故障是無感知的，一種實現(xiàn)的方式是采用Netflix在基于亞馬遜云計算平臺上實現(xiàn)的電路開關(guān)（Circuit Breaker）設(shè)計模式暂雹。
最后首装，因為服務(wù)實例隨時可能故障，所以其它實例要能夠啟動并替代故障實例杭跪。這可以通過設(shè)計無狀態(tài)服務(wù)來實現(xiàn)仙逻。
成熟度3：自適應(yīng)級
Level 3 表示應(yīng)用程序被設(shè)計得充分符合云計算環(huán)境的特有特征。這一層次的應(yīng)用程序可以部分或者全部地從一個云環(huán)境無縫地遷移到另一個云環(huán)境涧尿，沒有任何服務(wù)的中斷系奉。這要求它們具備所有前一級成熟度的能力要求。云中的某種“主控程序”可以控制應(yīng)用程序的編排和遷移姑廉，決定何時將應(yīng)用程序遷移到何地缺亮。例如，應(yīng)用程序可以將一部分從一個云環(huán)境遷移到另一個云環(huán)境中以便降低在高峰值負(fù)載時的資源租賃成本或者由于環(huán)境不穩(wěn)定帶來的服務(wù)質(zhì)量退化桥言。
Level 3 級別的應(yīng)用程序可以充分利用云的彈性和可擴展性萌踱，根據(jù)負(fù)載動態(tài)的實例伸縮。應(yīng)用程序可以通過增加實例水平擴展号阿，也可以通過增加虛擬CPU或者內(nèi)存縱向擴展并鸵。應(yīng)用程序需要提供元數(shù)據(jù)绅你，使得基礎(chǔ)設(shè)施可以對特定服務(wù)的擴展做出合適決定穆刻。
運維策略
本節(jié)包含云計算應(yīng)用程序的關(guān)鍵運維策略。運維策略指應(yīng)用程序如何部署和操作逢勾，以及與別的系統(tǒng)組件進(jìn)行交互扰柠。運維策略重點關(guān)注整系統(tǒng)全生命周期端到端的使用過程粉铐。
確保冗余
應(yīng)用程序組件、虛機卤档、網(wǎng)絡(luò)蝙泼、存儲以及其它云基礎(chǔ)設(shè)計都有可能發(fā)生故障。在運維時考慮冗余劝枣，可以降低這些故障帶來的影響汤踏。例如，如果云環(huán)境部署在多個地理地區(qū)舔腾，應(yīng)用程序和它依賴的組件可以在多個地區(qū)進(jìn)行冗余溪胶，如果某一個地區(qū)發(fā)生了故障，業(yè)務(wù)可以被重鏡像到正常的區(qū)域稳诚，保證了業(yè)務(wù)的持續(xù)性哗脖。
使用緩存
緩存是一個在傳統(tǒng)系統(tǒng)以及基于云環(huán)境的系統(tǒng)中都廣泛使用的技術(shù)。通過將服務(wù)經(jīng)常使用的數(shù)據(jù)在服務(wù)本地緩存可以提高系統(tǒng)性能，同樣可以提高容錯性才避，降低網(wǎng)絡(luò)帶寬消耗橱夭。當(dāng)云服務(wù)提供商針對網(wǎng)絡(luò)帶寬統(tǒng)計計費時，緩存可以節(jié)省運維成本桑逝。
安全訪問API
安全API訪問保證應(yīng)用和服務(wù)只被有權(quán)限的客戶端進(jìn)行訪問棘劣。如早先解釋的，不能保證部署在云上的服務(wù)是安全的楞遏。一個解決方法是在每個服務(wù)前面加設(shè)一個API管理代理茬暇。這不僅僅用來限制訪問，還可以認(rèn)證以及記錄API被哪些客戶端如何使用寡喝。Netflix使用這種方法限制核心共享服務(wù)的訪問而钞。利用這種方式，Netflix確保服務(wù)訪問層僅僅路由自己開發(fā)的組件發(fā)送的請求拘荡。
分階段部署
在大的分布式系統(tǒng)中，軟件升級可能因為bug撬陵、副作用或者未預(yù)見的兼容性問題導(dǎo)致不可知的問題珊皿。當(dāng)系統(tǒng)變得更大、更動態(tài)以及更復(fù)雜巨税，更需要減少這類事情的發(fā)生蟋定。在敏捷開發(fā)實踐中，不同團(tuán)隊更小更頻繁地發(fā)布也會增加這種風(fēng)險草添。
一種控制風(fēng)險的方式是小范圍的升級并且仔細(xì)監(jiān)控新版本的行為驶兜。新和舊的版本并存，避免新版本搞掛整個系統(tǒng)远寸。如果小范圍的部署成功抄淑，則可以在更大范圍內(nèi)部署新實例的虛機，同時老版本的虛機繼續(xù)運行以支持容錯驰后。如果新的版本失敗了肆资，則請求被簡單地重鏡像到老版本實例上。如果新的版本最終一切成功灶芝，則老版本的虛機實例可以被關(guān)閉下線郑原。
預(yù)防區(qū)域性故障
按照區(qū)域?qū)⒃瀑Y源進(jìn)行分組，每個區(qū)域獨立并與其它區(qū)域故障隔離夜涕。亞馬遜就將其EC2按照地理位置進(jìn)行了區(qū)域劃分犯犁。從亞馬遜的云服務(wù)中斷歷史可以看出，中斷往往會影響整個地區(qū)女器。因此有必要在云應(yīng)用部署時考慮彈性以避免區(qū)域性的故障酸役。例如，Netflix將其全部服務(wù)在不同區(qū)域進(jìn)行冗余，如果一個區(qū)域故障了簇捍，另一個區(qū)域可以接管失敗的區(qū)域繼續(xù)處理業(yè)務(wù)只壳。這需要數(shù)據(jù)進(jìn)行跨區(qū)域的同步。
應(yīng)用程序在區(qū)域間可以部署成主備或者雙活模式暑塑。主備模式下吼句，應(yīng)用程序的實例在兩個區(qū)域都運行，但是只有一個處于激活態(tài)事格，一個全局的負(fù)載均衡器負(fù)責(zé)決定將客戶請求發(fā)送到哪一個處理點惕艳。
在雙活模式下，部署在兩個位置的應(yīng)用程序都處于激活態(tài)驹愚，同時運行远搪，處理不同用戶的請求。如果一個地區(qū)故障了逢捺，全局負(fù)載均衡器負(fù)責(zé)將所有負(fù)載重鏡像到仍然正常的區(qū)域谁鳍。雙活模式提高了云資源的利用率，并且可以由離用戶較近的服務(wù)處理相應(yīng)用戶的請求劫瞳。
減少區(qū)域間時延
如果云環(huán)境地理位置分布較遠(yuǎn)倘潜，或者一個數(shù)據(jù)中心被分割到多個區(qū)域，網(wǎng)絡(luò)延遲將會成為一個關(guān)鍵因素志于。
對于需要低時延的服務(wù)涮因，盡量將它們部署在同一區(qū)域。一個挑戰(zhàn)是云上部署的應(yīng)用程序并不知道其物理位置伺绽。仔細(xì)地對數(shù)據(jù)進(jìn)行分析可以洞察一些應(yīng)用在云中的物理位置特征养泡，但是要知道，這些會隨著時間發(fā)生變化奈应，超出應(yīng)用所有者的控制澜掩。
高帶寬消耗服務(wù)云外部署
考慮將數(shù)據(jù)存儲到哪里可以降低數(shù)據(jù)傳輸開銷。例如杖挣，亞馬遜對于EC2和外部公共網(wǎng)絡(luò)間的數(shù)據(jù)傳輸進(jìn)行計費输硝。對于某些應(yīng)用程序，這筆開銷可能會非常昂貴程梦。將數(shù)據(jù)存儲在云外点把，例如CDN上，可以大大降低成本屿附。
對依賴進(jìn)行抽象
避免建立客戶和服務(wù)間的靜態(tài)依賴郎逃。例如，應(yīng)用程序可能依賴于存儲服務(wù)挺份，但是隨著時間推移褒翰，接口、實現(xiàn)以及存儲服務(wù)的位置都可能發(fā)生變化。例如應(yīng)用程序可能遷移到一個新的云服務(wù)提供商优训，它的等價基礎(chǔ)設(shè)施服務(wù)的接口以及地址等都不同朵你。對API進(jìn)行管理，對底層服務(wù)的實現(xiàn)進(jìn)行抽象揣非，或者采用更加松耦合的REST API抡医，可以讓組件彼此獨立地進(jìn)行演進(jìn)。
總結(jié)
當(dāng)技術(shù)持續(xù)快速演進(jìn)早敬，開發(fā)者需要持續(xù)地提升自己的技能 - 學(xué)習(xí)以及采用新的技術(shù)來進(jìn)行架構(gòu)設(shè)計和開發(fā)忌傻，以構(gòu)建更加魯邦的云應(yīng)用程序。為了成功的提升云應(yīng)用的能力搞监，組織需要做如下事情：
為員工的開發(fā)能力培訓(xùn)進(jìn)行投資水孩，確保員工掌握構(gòu)建云計算應(yīng)用程序的技巧。
找出辦法琐驴，避免開發(fā)人員浪費大量時間從事低層次俘种、低價值的技術(shù)活動。
發(fā)布的大規(guī)模復(fù)雜應(yīng)用應(yīng)該是易于修改且可以容易和已有系統(tǒng)進(jìn)行集成的绝淡。
對開發(fā)者的建議
由于云計算領(lǐng)域特有的特征安疗，應(yīng)用程序開發(fā)者需要掌握建立分布式系統(tǒng)的設(shè)計原則和新的設(shè)計模式。這些原則和模式幫助云應(yīng)用程序具備彈性擴展够委、高容錯、以及更有效地進(jìn)行資源利用怖现。
本文描述的策略主要針對分布式系統(tǒng)的內(nèi)在挑戰(zhàn)茁帽。這些設(shè)計模式都是在大規(guī)模云應(yīng)用程序中被開發(fā)人員證明是有效的。毫無疑問屈嗤，當(dāng)開發(fā)人員面臨新的云環(huán)境挑戰(zhàn)潘拨，為了更優(yōu)雅的處理這些問題，他們會持續(xù)地創(chuàng)造出新的設(shè)計模式饶号。
云應(yīng)用成熟度模型則為開發(fā)者提供了評估他們云應(yīng)用成熟度的標(biāo)準(zhǔn)铁追，這可以為云應(yīng)用程序云成熟度演進(jìn)做決策。
云平臺需求
以下需求提給云計算提供商：
支持云計算的行業(yè)標(biāo)準(zhǔn)茫船，最好是開發(fā)標(biāo)準(zhǔn)或者是被廣泛支持的事實標(biāo)準(zhǔn)琅束。這些支持可以防止應(yīng)用程序鎖定到特定的云供應(yīng)商，以及讓應(yīng)用程序容易地在混合云環(huán)境中無縫運行算谈。
提供標(biāo)準(zhǔn)的鏡像涩禀，和其它云計算平臺所提供的鏡像保持一致。例如要開發(fā)一個私有云然眼，考慮創(chuàng)建的鏡像和亞馬遜EC2提供的鏡像一致艾船，如果應(yīng)用程序有計劃未來一部分移植到亞馬遜的云平臺上。
支持?jǐn)?shù)據(jù)的親和性（支持?jǐn)?shù)據(jù)的生產(chǎn)/消費者模式）。
使用標(biāo)準(zhǔn)的版本控制腳本去創(chuàng)建和配置虛擬機屿岂。
我們正處于一個由云計算引起的重大技術(shù)變革中践宴，促進(jìn)開發(fā)者和企業(yè)進(jìn)入一個真正的分布式技術(shù)的世界。技術(shù)人員有機會通過采用新的方法和技術(shù)開發(fā)適應(yīng)云計算特點的應(yīng)用程序爷怀，提供業(yè)務(wù)轉(zhuǎn)型的真正價值阻肩。ODCA（OPEN DATA CENTER ALLIANCE）希望本文為學(xué)習(xí)和研究面向云計算的應(yīng)用程序架構(gòu)技術(shù)的開發(fā)人員提供起點。ODCA認(rèn)為提升開發(fā)人員的開發(fā)技能霉撵，以滿足不斷增長的云應(yīng)用架構(gòu)的軟件需求磺浙，需要持續(xù)地教育和培訓(xùn)，使開發(fā)人員專注于技能發(fā)展以及工作領(lǐng)域的創(chuàng)新徒坡。
參考
“Architectural Patterns for High Availability”
www.infoq.com/presentations/Netflix-Architecture
C loud Architecture Patterns
www.amazon.com/Cloud-Architecture-Patterns-Using-Microsoft-ebook/dp/B009G8PYY4/
“ Cloud Characteristics, Principles and Design Patterns”
www.gartner.com/document/2081915
“ Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications”
http://msdn.microsoft.com/en-us/library/dn568099.aspx
“ Building Cloud-Aware Applications”
www.slideshare.net/cobiacomm/building-cloudaware-applications[slides 17, 18, 19, 31]
“ Searching for Cloud Architecture…”
http://blog.cobia.net/cobiacomm/2011/11/25/searching-for-cloud-architecture/
“ Maximizing Cloud Advantages through Cloud-Aware Applications”
N etwork Latency between U.S. cities (AT&T)
http://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html
“ The Fallacies of Distributed Computing Reborn: The Cloud Era – New Relic blog”
http://blog.newrelic.com/2011/01/06/the-fallacies-of-distributed-computing-reborn-the-cloud-era/
“ 5 Lessons We’ve Learned Using AWS” – Netflix Tech Blog
http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html
“ Optimizing the Netflix API” – Ben Christensen
http://benjchristensen.com/2013/04/30/optimizing-the-netflix-api/
“ Architecting Applications for the Cloud: Best Practices” – Jinesh Varia, Amazon Technical Evangelist
http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
“ Lessons from Distill” – Michael Forhan, AppFirst
www.appfirst.com/blog/lessons-from-distill/
“ Understanding Security with Patterns” – Prof. Peter Sommerlad, Tutorial T39 @ OOPSLA 2006
http://wiki.hsr.ch/PeterSommerlad/files/T39-Sommerlad.pdf
“ How it Works” (Circuit Breaker implementation in Hysterix open source library) – Netflix
https://github.com/Netflix/Hystrix/wiki/How-it-Works
N etflix Shares Cloud Load Balancing and Failover Tool: Eureka! - Netflix Tech Blog
http://techblog.netflix.com/2012/09/eureka.html
“ Dystopia as a Service” – Adrian Cockcroft, Netflix
www.slideshare.net/adrianco/dystopia-as-a-service
“ Netflix and Open Source”
附錄A：術(shù)語表
略撕氧。見原文！
附錄B：云計算反模式
云計算的反模式指一組應(yīng)該被避免的在云上不好的設(shè)計實踐喇完。下面列出的反模式限制了應(yīng)用程序很好的發(fā)揮云計算的優(yōu)勢：
復(fù)雜配置伦泥。避免不必要的復(fù)雜繁瑣的配合設(shè)置。如果不需要熱插拔或者動態(tài)配置文件锦溪，就依靠持久配置不脯。如果應(yīng)用程序靠持久配置就可以，那么可以在持續(xù)集成環(huán)境將配置在應(yīng)用程序編譯構(gòu)建階段注入刻诊。這樣就避免了建立配置服務(wù)器的麻煩防楷。不會出現(xiàn)所有的服務(wù)都去請求配置服務(wù)器造成配置服務(wù)器陷入拒絕服務(wù)狀態(tài)。
復(fù)雜的依賴则涯。避免應(yīng)用程序依賴不必要的庫复局。這種依賴會導(dǎo)致應(yīng)用程序過大從而使得鏈接、加載等過程變長粟判。為了減少依賴亿昏，使用工具生成現(xiàn)有的依賴關(guān)系，只包括那些在應(yīng)用程序部署到云中的所必須的依賴档礁。
管理共享狀態(tài)角钩。避免在啟動時檢索應(yīng)用程序的狀態(tài)，這會導(dǎo)致延遲從而讓應(yīng)用程序不能快速地處理傳入的請求呻澜。
附錄C：安全訪問控制
訪問控制技術(shù)提供了一組限制系統(tǒng)訪問權(quán)限的配置機制递礼。基于角色的控制（RBAC）和基于特性的控制（ABAC）屬于云平臺上針對組件進(jìn)行訪問控制的設(shè)計模式羹幸。
RBAC也稱為基于角色的安全宰衙。RBAC針對角色定制不同層級的權(quán)限。每個角色賦予一個和角色安全水平相關(guān)的訪問授權(quán)睹欲。反過來供炼，角色和權(quán)限被分配給一個或者多個主題一屋，一個主題可以是一個人或者自治的代理（例如一個自動提供創(chuàng)建和部署計算資源的服務(wù)）。
ABAC也稱為基于特性的安全袋哼。ABAC模型相對較新冀墨，結(jié)合了主題、策略以及屬性來定義一個邏輯訪問控制涛贯。這個邏輯定義允許用戶更容易地定義復(fù)雜的訪問控制策略诽嘉。相反，RBAC則基于主題的當(dāng)前狀態(tài)以及對應(yīng)的角色弟翘，需要手動的更新策略虫腋。
附錄D：自動伸縮
自動伸縮控制計算資源的動態(tài)增加或者減少以匹配當(dāng)前的負(fù)載。伸縮機制依賴于對負(fù)載的監(jiān)控稀余。監(jiān)控使用高低門限（例如CPU利用率或者消息隊列長度）悦冀。當(dāng)門限過高或者過低超過預(yù)定義的門限，則會引起告警以觸發(fā)彈性伸縮睛琳。
許多的商業(yè)和開源軟件提供了IaaS和PaaS層的自動彈性伸縮解決方案盒蟆。每種解決方案的集成和自動化都不太一樣。以下是一些自動彈性伸縮的解決方案示例：
Amazon Auto Scaling
Azure Management Portal Scaler
Rackspace Auto Scale
Scalr
Eucalyptus Auto Scaling
RightScale Auto Scaling
附錄E：CAP理論
CAP理論由Eric Brewer提出师骗，它說明一個分布式系統(tǒng)不可能同時滿足以下三個特性：
一致性历等。通過任何節(jié)點的讀取都看到相同的數(shù)據(jù)（針對之前完成的寫入）。
可用性辟癌。任何時候都可以成功讀寫（應(yīng)答都有反應(yīng)）寒屯。
分區(qū)容錯性。隨意的消息丟失或者組件故障黍少，系統(tǒng)都可以繼續(xù)運行（容錯性）寡夹。
當(dāng)在云上實現(xiàn)一個數(shù)據(jù)存儲的時候，需要在可擴展性仍侥、性能和可靠性之間權(quán)衡。Brewer描述的這三個特性只能同時滿足兩個：CP鸳君、AP或者CA农渊。
附錄F：數(shù)據(jù)庫分片
數(shù)據(jù)庫分片（Data sharding）是一種將數(shù)據(jù)庫中表按照行進(jìn)行水平分區(qū)的設(shè)計原則。每個分片定義為一個shard或颊。整個數(shù)據(jù)庫跨越多個分布的服務(wù)器砸紊，服務(wù)器之間沒有任何共享。數(shù)據(jù)庫分片可以提高數(shù)據(jù)庫的性能以及提高可擴展性囱挑。數(shù)據(jù)分片也提高了吞吐量以及數(shù)據(jù)庫的存儲容量醉顽。
“Sharding”這個詞產(chǎn)生于Google關(guān)于Bigtable的研究報告，“Bigtable: A Distributed Storage System for Structured Data”平挑。
云計算應(yīng)用程序因為依賴大規(guī)模的數(shù)據(jù)所以天然適合做sharding游添。數(shù)據(jù)分片減少了整體的客戶端延遲系草，提高擴展性和吞吐量。
附錄G：數(shù)據(jù)復(fù)制
數(shù)據(jù)復(fù)制指為數(shù)據(jù)存儲創(chuàng)建多個冗余版本唆涝。復(fù)制的數(shù)據(jù)需要在冗余資源之間保持一致性找都。數(shù)據(jù)復(fù)制提高了系統(tǒng)的可靠性，容錯性以及在數(shù)據(jù)源故障或者不可訪問時的數(shù)據(jù)可用性廊酣。如果數(shù)據(jù)源故障了能耻，云應(yīng)用可以平滑的切換到備份的數(shù)據(jù)源，保證了數(shù)據(jù)的一致性和可用性亡驰。
多份冗余的數(shù)據(jù)模型可以提供不一樣的持久化機制（例如：數(shù)據(jù)庫晓猛，磁盤存儲，或者文件存儲）凡辱。
附錄H：靜態(tài)內(nèi)容托管
Web應(yīng)用程序在處理動態(tài)頁面請求的時候會包含很多靜態(tài)內(nèi)容戒职。客戶端下載靜態(tài)內(nèi)容會產(chǎn)生較多的負(fù)載煞茫。云應(yīng)用應(yīng)該將靜態(tài)內(nèi)容和動態(tài)內(nèi)容分離帕涌，將靜態(tài)內(nèi)容分開存儲。
CDN（content delivery network续徽，內(nèi)容分發(fā)網(wǎng)絡(luò)）為靜態(tài)內(nèi)容提供了地理上分布的存儲服務(wù)能力蚓曼。客戶可以從離自己近的CDN上獲取靜態(tài)內(nèi)容钦扭，而云中只需要為客戶計算和發(fā)送動態(tài)內(nèi)容纫版。這樣可以提高整系統(tǒng)的吞吐量。
作者：MagicBowen
鏈接：http://www.reibang.com/p/5e6860e44611
來源：簡書
簡書著作權(quán)歸作者所有客情，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處其弊。
