** ODCA(Open Data Center Alliance)最佳實(shí)踐 **

簡介

為了更有效的利用云計(jì)算的潛力比默，企業(yè)必須從根本上改變開發(fā)和運(yùn)維的方式。在這種新的計(jì)算模式上采用新的開發(fā)方式才能更好地獲得云計(jì)算全方位的好處比然。在云計(jì)算下屈留，應(yīng)用程序的構(gòu)建谁尸、運(yùn)行和消費(fèi)方式都和以往大大不同晰赞，這些不同導(dǎo)致需要新的思考模式以及掌握新的設(shè)計(jì)模式才能取得最好的結(jié)果稼病，這些技術(shù)和傳統(tǒng)解決問題時(shí)的權(quán)衡方式有所不同。

本文檔為專注于應(yīng)用架構(gòu)和開發(fā)實(shí)踐的開發(fā)人員提供了一個(gè)視角：從多個(gè)層面構(gòu)建可以充分發(fā)揮云計(jì)算的獨(dú)特能力的應(yīng)用程序體系架構(gòu)掖鱼。

為了更有效的過渡到云計(jì)算然走，開發(fā)者需要：

• 了解基于云計(jì)算的新的設(shè)計(jì)范式，區(qū)別云和傳統(tǒng)的計(jì)算平臺(tái)在軟硬件上存在的基本差異戏挡。
• 熟悉和使用能夠構(gòu)建更好的云應(yīng)用的軟件設(shè)計(jì)模式芍瑞。
• 發(fā)展和完善技能，針對(duì)云計(jì)算的范式進(jìn)行轉(zhuǎn)型褐墅。

摘要

為了跟上日益普及的云計(jì)算拆檬，開發(fā)人員必須在開發(fā)基于云計(jì)算的應(yīng)用架構(gòu)時(shí)考慮云的基本特征。雖然開發(fā)人員很容易地將原來的分布式軟件遷移到云上妥凳，但是這種從物理到虛擬化（physical-to-virtual竟贯，P2V）的簡單移植并不能發(fā)揮出云計(jì)算的獨(dú)特能力。使用明確為云環(huán)境所設(shè)計(jì)的設(shè)計(jì)模式逝钥，可以讓軟件保持高水平的可靠性屑那、安全性和彈性。

本文為開發(fā)人員所寫：

• 總結(jié)了云計(jì)算應(yīng)用程序體系架構(gòu)的基本原理艘款；
• 介紹了云計(jì)算應(yīng)用程序的結(jié)構(gòu)原則持际；
• 提出了一些已經(jīng)被證明有效的云計(jì)算架構(gòu)的設(shè)計(jì)模式；
• 提出了云計(jì)算應(yīng)用程序的關(guān)鍵運(yùn)維原則哗咆，通過云應(yīng)用成熟度模型幫助企業(yè)進(jìn)行云應(yīng)用的演進(jìn)蜘欲。

開發(fā)人員、架構(gòu)師晌柬、CTO姥份、CIO等都可以從本文介紹的云應(yīng)用開發(fā)技術(shù)中受益！

目標(biāo)讀者

本文主要貢獻(xiàn)給軟件開發(fā)社區(qū)年碘，同時(shí)為任何在云上構(gòu)架殿衰、設(shè)計(jì)、實(shí)施盛泡、部署和運(yùn)維服務(wù)的人員提供有價(jià)值的信息闷祥。

目標(biāo)受眾有：

• 參與設(shè)計(jì)、開發(fā)和部署云應(yīng)用程序的軟件開發(fā)者傲诵；
• 為企業(yè)進(jìn)行云應(yīng)用設(shè)計(jì)和部署的企業(yè)決策者凯砍；
• 負(fù)責(zé)規(guī)劃、運(yùn)營和采購的企業(yè)IT組織拴竹；
• 致力于提高云平臺(tái)互操作API和云計(jì)算相關(guān)的標(biāo)準(zhǔn)和指南的標(biāo)準(zhǔn)組織悟衩；

術(shù)語

在本文檔中，“云應(yīng)用程序（cloud application）”這個(gè)詞指的是一組在云中托管的組件（components）的集合栓拜，這些組件連通著一些在設(shè)備或者瀏覽器中運(yùn)行的客戶端應(yīng)用（client app）座泳。例如惠昔，一個(gè)用戶可能使用iPad中的視頻播放器觀看電影，這依賴于在云中運(yùn)行的身份驗(yàn)證挑势、授權(quán)镇防、媒體流、媒體存儲(chǔ)潮饱、緩存和其它服務(wù)組件来氧，總的來說這些構(gòu)成了一個(gè)完整的“云應(yīng)用程序”。但是本文只關(guān)注于托管在云端的組件部分香拉。

應(yīng)用程序架構(gòu)的演進(jìn)

隨著計(jì)算機(jī)硬件啦扬、網(wǎng)絡(luò)以及設(shè)備從個(gè)人電腦到智能手機(jī)的變化，應(yīng)用程序架構(gòu)也隨之演進(jìn)凫碌。云計(jì)算是最近的改變應(yīng)用程序架構(gòu)演進(jìn)的力量扑毡。要了解云計(jì)算如何改變軟件架構(gòu)，需要看看在傳統(tǒng)的非云環(huán)境中軟件架構(gòu)是什么樣子的盛险。

分層體系架構(gòu)

分層體系架構(gòu)（見下圖）將應(yīng)用程序的功能分布在不同的層中僚楞。例如，在三層架構(gòu)中：

• 表示層提供用戶接口枉层；
• 中間層處理從客戶端過來的用戶請(qǐng)求泉褐，完成應(yīng)用的商業(yè)邏輯；
• 數(shù)據(jù)層提供應(yīng)用的數(shù)據(jù)存儲(chǔ)鸟蜡；

電子郵件就是典型的三層架構(gòu)膜赃。這種類型的應(yīng)用包含一個(gè)表示層客戶端，例如運(yùn)行在PC上的Outlook揉忘，一個(gè)中間層的消息服務(wù)器（Exchange Server）跳座，以及一個(gè)后端信息存儲(chǔ)。中間層以API的形式對(duì)外提供服務(wù)泣矛∑＞欤客戶端使用這些API和中間層通訊，基于一個(gè)應(yīng)用協(xié)議您朽，如互聯(lián)網(wǎng)信息訪問協(xié)議（IMAP）狂丝。中間層往往與多個(gè)后端服務(wù)進(jìn)行交互。在電子郵件系統(tǒng)中哗总，中間層可能與后端的目錄服務(wù)几颜、消息存儲(chǔ)、消息轉(zhuǎn)發(fā)代理等等進(jìn)行集成讯屈。

分層體系架構(gòu)中的每一個(gè)組件通常都運(yùn)行在各自獨(dú)立的服務(wù)器上蛋哭，層之間通過靜態(tài)配置其依賴的服務(wù)器主機(jī)名來進(jìn)行互通。這種分層架構(gòu)往往比單體架構(gòu)（monolithic architecture：即不做分層涮母，把整個(gè)應(yīng)用構(gòu)建在一起）有更多的優(yōu)勢(shì)谆趾。分層架構(gòu)中每一個(gè)組件都可以獨(dú)立運(yùn)行并且層之間可以提供負(fù)載均衡以便獲得更好的性能和可靠性躁愿。因?yàn)橹虚g層通過網(wǎng)絡(luò)API的方式進(jìn)行訪問，所以多個(gè)客戶端可以共享一個(gè)中間層服務(wù)器沪蓬。每個(gè)層都可以獨(dú)立開發(fā)彤钟，只要接口和數(shù)據(jù)保持兼容。

在多層架構(gòu)中怜跑，服務(wù)的部署是靜態(tài)的样勃。層之間的依賴通過上電時(shí)的配置文件進(jìn)行描述吠勘。例如：一個(gè)郵件客戶端通過配置文件知道郵件服務(wù)器的主機(jī)名和IP性芬，客戶端無法動(dòng)態(tài)發(fā)現(xiàn)離自己最近的郵件服務(wù)器，它必須通過已知的主機(jī)名直接連接到服務(wù)器剧防。

多數(shù)的web應(yīng)用都是分層體系架構(gòu)的例子植锉。一個(gè)網(wǎng)絡(luò)服務(wù)器向用戶的網(wǎng)頁瀏覽器分發(fā)應(yīng)用代碼和內(nèi)容，用戶側(cè)使用JavaScript代碼為用戶提供交互式體驗(yàn)峭拘。中間層的服務(wù)器上往往運(yùn)行Java俊庇、Ruby on Rails或者PHP等代碼為前端用戶交付動(dòng)態(tài)內(nèi)容，反過來中間層需要與后端的數(shù)據(jù)庫服務(wù)進(jìn)行通信鸡挠。

基于虛擬化環(huán)境的分層體系架構(gòu)

許多企業(yè)已經(jīng)將他們的應(yīng)用遷移到自己的數(shù)據(jù)中心的虛擬化基礎(chǔ)設(shè)施上辉饱。在虛擬化環(huán)境中，應(yīng)用組件是部署在虛擬機(jī)上而非傳統(tǒng)的物理硬件上拣展。虛擬化可以讓計(jì)算資源更有效的被利用彭沼，通過自動(dòng)化手段減少資源供應(yīng)時(shí)間和成本，從而提高效率备埃。

在虛擬化環(huán)境中姓惑，應(yīng)用的部署和配置和其在物理數(shù)據(jù)中心是相同的，例如都是通過靜態(tài)配置來構(gòu)建的按脚。然而于毙，虛擬化可以讓應(yīng)用程序更高效的擴(kuò)展，因?yàn)樾碌膽?yīng)用組件實(shí)例可以按需創(chuàng)建和配置辅搬。這種動(dòng)態(tài)性可以通過基于虛擬化的負(fù)載均衡和虛擬IP（VIPs）來實(shí)現(xiàn)唯沮。分層架構(gòu)中的每一層都可以獨(dú)立的進(jìn)行擴(kuò)展，而對(duì)其它層是透明的堪遂。

云應(yīng)用架構(gòu)

為云創(chuàng)建應(yīng)用程序時(shí)烂翰，開發(fā)人員可以不改變他們?cè)瓉砑軜?gòu)應(yīng)用程序的方式。例如：一個(gè)開發(fā)人員可以簡單地把一個(gè)分層架構(gòu)的應(yīng)用部署到云基礎(chǔ)設(shè)施上蚤氏，特別是使用基礎(chǔ)設(shè)施即服務(wù)（IaaS）甘耿，可以方便地把原來基于獨(dú)立服務(wù)器的應(yīng)用組件直接移植到對(duì)應(yīng)的虛機(jī)（VM）上。然而竿滨，這種P2V的方式佳恬，并不能很好的讓應(yīng)用程序發(fā)揮云的獨(dú)特功能捏境。傳統(tǒng)分層架構(gòu)，通常和特定的基礎(chǔ)設(shè)施位置毁葱，例如服務(wù)器名稱垫言、IP地址、以及網(wǎng)絡(luò)服務(wù)配置等強(qiáng)耦合倾剿。這種方式使得它基本難以在云上進(jìn)行快速的多虛機(jī)或多實(shí)例自動(dòng)擴(kuò)展筷频。為了更有效的發(fā)揮云的全方位能力，開發(fā)人員必須在架構(gòu)設(shè)計(jì)的時(shí)候全面考慮云環(huán)境特點(diǎn)前痘，包括彈性凛捏、自服務(wù)、和多租戶等芹缔。下圖對(duì)別了傳統(tǒng)的分層架構(gòu)和基于云架構(gòu)應(yīng)用的差異坯癣。

traditional-vs-cloud.png

一般情況下，使用云平臺(tái)的應(yīng)用程序需要滿足分布式系統(tǒng)的約束要求最欠。Peter Deutsch在1994年描述了開發(fā)人員在開發(fā)分布式系統(tǒng)時(shí)經(jīng)常犯的8大謬誤示罗。這些謬誤適用于跨網(wǎng)絡(luò)的分布式服務(wù)系統(tǒng)，包括今天的云架構(gòu)應(yīng)用芝硬。針對(duì)這些謬誤蚜点，Peter Deutsch提出了一些構(gòu)建分布式系統(tǒng)的原則和最佳實(shí)踐，這些最佳實(shí)踐可以有效指導(dǎo)如何進(jìn)行基于云架構(gòu)特點(diǎn)的應(yīng)用架構(gòu)設(shè)計(jì)拌阴。

云應(yīng)用架構(gòu)原則

本節(jié)總結(jié)了云計(jì)算應(yīng)用架構(gòu)的基本原則绍绘。下表列出了影響應(yīng)用程序如何組織、編碼以及用戶交互方式的結(jié)構(gòu)性原則皮官。后面的章節(jié)還總結(jié)了整個(gè)云系統(tǒng)的部署脯倒、操作以及與其它系統(tǒng)組件進(jìn)行交互的運(yùn)維原則。

這些原則適應(yīng)于云計(jì)算應(yīng)用架構(gòu)的不同時(shí)間階段捺氢，原則中標(biāo)記為高優(yōu)先級(jí)的屬于開發(fā)云計(jì)算應(yīng)用時(shí)強(qiáng)烈推薦的藻丢，低優(yōu)先級(jí)相對(duì)來說重要性下降。

結(jié)構(gòu)原則

本節(jié)詳細(xì)介紹了云計(jì)算應(yīng)用程序的結(jié)構(gòu)原則摄乒。這些原則用來指導(dǎo)應(yīng)用程序如何組織悠反、編碼以及與最終用戶進(jìn)行交互。

容忍失敗

在一個(gè)大規(guī)模的云環(huán)境中馍佑，應(yīng)用程序運(yùn)行的基礎(chǔ)設(shè)施容易由于某些固定類型的故障導(dǎo)致無法正常工作斋否。這里潛在的安全漏洞包含計(jì)算、網(wǎng)絡(luò)或者存儲(chǔ)的硬件失敗拭荤，或者組件及服務(wù)的軟件錯(cuò)誤茵臭，或者由于某個(gè)反應(yīng)遲鈍的組件導(dǎo)致的網(wǎng)絡(luò)失敗，或者瞬間網(wǎng)絡(luò)連接的中斷等等舅世。為了適應(yīng)這些類型的故障旦委，應(yīng)用程序的架構(gòu)設(shè)計(jì)必須能夠無縫地處理它們并且通過降低性能層次或者優(yōu)雅的功能降級(jí)而無干擾地繼續(xù)運(yùn)行奇徒。

松耦合可以最大限度地減少組件之間的依賴關(guān)系，使組件被替換而不影響別人缨硝。例如摩钙，我們很可能決定將key-value存儲(chǔ)用一個(gè)更高性能和可靠性的實(shí)現(xiàn)來替換。松耦合同時(shí)提供了一種管理失敗和延遲的方式查辩，一個(gè)給定的組件可能會(huì)失敗胖笛，但是由于不靜態(tài)綁定到固定的實(shí)例，可以將失敗的組件進(jìn)行動(dòng)態(tài)替換避免了應(yīng)用程序從失敗中恢復(fù)所需要做的操作宜岛。

開發(fā)人員經(jīng)常忽視對(duì)網(wǎng)絡(luò)可靠性問題進(jìn)行彈性設(shè)計(jì)的重要性长踊。此類型的失敗是很難檢測(cè)以及優(yōu)雅處理的。例如谬返，如果關(guān)鍵數(shù)據(jù)由于訪問數(shù)據(jù)庫失敗而未能寫入之斯，這時(shí)代碼如何優(yōu)雅地去處理該問題日杈？可能有人爭論說如果網(wǎng)絡(luò)掛掉了后果如此嚴(yán)重遣铝，那么最簡單的辦法就是應(yīng)用程序返回失敗，讓用戶后續(xù)再次嘗試莉擒。照他們使用移動(dòng)設(shè)備的經(jīng)驗(yàn)酿炸，用戶應(yīng)該知道網(wǎng)絡(luò)不是100%的可靠。但是在云計(jì)算中忽略對(duì)失敗的彈性設(shè)計(jì)涨冀，會(huì)導(dǎo)致大型分布式應(yīng)用中單點(diǎn)失敗的級(jí)聯(lián)填硕，最終造成整個(gè)系統(tǒng)服務(wù)的失敗，而不僅僅只對(duì)某一個(gè)用戶帶來不便鹿鳖。

在某些場(chǎng)景下扁眯，間歇性故障是可以接受的状原。通過網(wǎng)絡(luò)負(fù)載均衡功能可以減少多種類型的失敗克懊，提高彈性和性能两曼。然而芽偏，在某些情況下未能優(yōu)雅地處理網(wǎng)絡(luò)問題可能產(chǎn)生不能接受的用戶體驗(yàn)蛹稍。想象一下如果由于遠(yuǎn)端的服務(wù)的網(wǎng)絡(luò)中斷導(dǎo)致旋轉(zhuǎn)門無法確認(rèn)乘客的車票讓乘客無法入站踪蹬。再想象一下一個(gè)游戲無法啟動(dòng)是由于不能和排名服務(wù)建立連接（該服務(wù)并是不游戲啟動(dòng)的必須條件）搀暑。這些不可接受的后果假褪，以及由于網(wǎng)絡(luò)問題導(dǎo)致的級(jí)聯(lián)后果歼疮，使得架構(gòu)師必須考慮系統(tǒng)的整體視圖杂抽。

“系統(tǒng)必須在存在失敗的情況下也能夠持續(xù)響應(yīng)，分布式系統(tǒng)要設(shè)計(jì)的可以容忍其所依賴的其它系統(tǒng)的失敗韩脏。
如果系統(tǒng)down了缩麸，我們可以降低對(duì)客戶的響應(yīng)質(zhì)量，但是還應(yīng)該能夠響應(yīng)赡矢。如果我們系統(tǒng)的搜索部分變得緩慢杭朱，但是流媒體還是應(yīng)該繼續(xù)正常工作愚屁。”

• John Ciancutti, Netflix Tech Blog: “5 Lessons We’ve Learned Using AWS”

對(duì)云計(jì)算所設(shè)計(jì)的應(yīng)用程序必須可以以多種形式容忍基礎(chǔ)設(shè)施的失敗痕檬。

法則： 做一個(gè)悲觀主義者霎槐，當(dāng)基于云做架構(gòu)設(shè)計(jì)時(shí)，必須假設(shè)所有事情都可能失敗梦谜。換句話說丘跌，總是在設(shè)計(jì)、實(shí)現(xiàn)以及部署中考慮如何使得應(yīng)用程序可以從失敗中自動(dòng)恢復(fù)過來唁桩。
特別是闭树，認(rèn)為你的硬件將會(huì)故障。認(rèn)為機(jī)器會(huì)發(fā)生當(dāng)機(jī)荒澡，認(rèn)為應(yīng)用程序會(huì)發(fā)生故障报辱，認(rèn)為某一天會(huì)遭受信令風(fēng)暴，認(rèn)為你的軟件會(huì)隨著時(shí)間發(fā)生失敗单山。做一個(gè)悲觀主義者碍现，你可以在每次設(shè)計(jì)的時(shí)候都去考慮恢復(fù)策略，這可以讓你的系統(tǒng)整體設(shè)計(jì)的更好米奸。
如果你意識(shí)到事情會(huì)隨著時(shí)間推移而失敗昼接，把這種思想融入到你的架構(gòu)設(shè)計(jì)中，建立機(jī)制來通過一個(gè)可擴(kuò)展的架構(gòu)在災(zāi)難爆發(fā)之前進(jìn)行失敗處理悴晰，你將最終建立一個(gè)適合云的容錯(cuò)架構(gòu)慢睡。

• Jinesh Varia, Technology Evangelist, Amazon: “Architecting for the Cloud: Best Practices”

容忍延遲

云應(yīng)用程序通常運(yùn)行在一個(gè)多租戶、共享的環(huán)境中铡溪。由于同環(huán)境中其它應(yīng)用產(chǎn)生的負(fù)載通常會(huì)讓網(wǎng)絡(luò)的響應(yīng)時(shí)間和延遲變得不穩(wěn)定漂辐。云應(yīng)用必須設(shè)計(jì)的能夠妥善處理時(shí)延。云應(yīng)用的開發(fā)者需要為時(shí)延專門進(jìn)行彈性設(shè)計(jì)棕硫。由于基礎(chǔ)設(shè)施故障導(dǎo)致的連接時(shí)延通常會(huì)有多種形式髓涯，包括：

• 網(wǎng)絡(luò)擁塞或者網(wǎng)絡(luò)分區(qū)；
• 對(duì)基礎(chǔ)設(shè)施中的共享資源出現(xiàn)競(jìng)爭請(qǐng)求饲帅；
• 存儲(chǔ)系統(tǒng)出現(xiàn)I/O帶寬飽和复凳；
• 共享服務(wù)出現(xiàn)軟件故障；
• DoS攻擊導(dǎo)致服務(wù)失敗或者資源枯竭灶泵；

移動(dòng)應(yīng)用程序（mobile application）的開發(fā)人員已經(jīng)開發(fā)了用于解決不可靠網(wǎng)絡(luò)連接的技術(shù)育八，這些技術(shù)同樣適應(yīng)于云。例如：

• 用隊(duì)列緩存請(qǐng)求赦邻。實(shí)現(xiàn)一個(gè)請(qǐng)求隊(duì)列和重試機(jī)制來確保請(qǐng)求不會(huì)丟失髓棋，這樣可以保證應(yīng)用程序不會(huì)出現(xiàn)崩潰。不需要在所有情況下都進(jìn)行重傳，例如按声，如果下次應(yīng)用程序主動(dòng)向服務(wù)poll數(shù)據(jù)時(shí)數(shù)據(jù)是有效的膳犹，那么可以允許某次請(qǐng)求超時(shí)。而對(duì)于寫入請(qǐng)求則不應(yīng)該進(jìn)行丟棄签则。
• 優(yōu)雅地處理失敗须床。如果失敗發(fā)生了，需要溫和地處理它渐裂。例如豺旬，不要因?yàn)橐粋€(gè)服務(wù)響應(yīng)慢而導(dǎo)致應(yīng)用程序阻塞，相反可以返回響應(yīng)表明請(qǐng)求的處理進(jìn)度柒凉。

延遲是所有分布式網(wǎng)絡(luò)系統(tǒng)的一個(gè)重要性能指標(biāo)族阅。光的速度決定了兩個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)之間的最小時(shí)延。在最好的情況下膝捞，一個(gè)運(yùn)行在舊金山和另一個(gè)運(yùn)行在紐約之間的服務(wù)通訊延遲是13.8ms坦刀，或者往返27.6ms。在現(xiàn)實(shí)中蔬咬，延遲比這個(gè)還要高鲤遥，由于網(wǎng)絡(luò)鏈接降低信號(hào)傳播速度、網(wǎng)絡(luò)協(xié)議棧開銷以及網(wǎng)絡(luò)交換機(jī)和擁塞引起的時(shí)延计盒。根據(jù)AT&T的測(cè)量渴频，在舊金山和紐約之間的時(shí)延有70ms芽丹。

延遲隨著時(shí)間會(huì)發(fā)生變化北启，這些取決于網(wǎng)絡(luò)流量和路由。當(dāng)應(yīng)用托管在第三方云基礎(chǔ)設(shè)施上拔第，這時(shí)開發(fā)者是缺少控制權(quán)的咕村，云提供商的網(wǎng)絡(luò)情況以及其他用戶如何使用云都是不透明的。由于數(shù)據(jù)中心中流量的情況非常復(fù)雜較難控制蚊俺，所以云環(huán)境中的延遲變化會(huì)非常明顯懈涛。

“AWS被設(shè)計(jì)為共享資源的模型。其中包括硬件泳猬、網(wǎng)絡(luò)以及存儲(chǔ)等都是多租戶的批钠。這樣網(wǎng)絡(luò)的吞吐是在不同層次間變化的。你要么愿意放棄任何特定的任務(wù)執(zhí)行得封，要么就在AWS下管理好你的資源避免多租戶對(duì)你的影響埋心。”

• John Ciancutti, Netflix Tech Blog: “5 Lessons We’ve Learned Using AWS”

分布式系統(tǒng)中往往具有大量節(jié)點(diǎn)忙上，延遲可能會(huì)由服務(wù)之間的依賴進(jìn)行累積拷呆，例如A依賴于B，B依賴于C，這樣一個(gè)深的依賴棧會(huì)導(dǎo)致響應(yīng)延遲大而且難以擴(kuò)展茬斧。定位及解決這些服務(wù)依賴可以改善性能腰懂。當(dāng)在云中架構(gòu)應(yīng)用時(shí)，開發(fā)者需要減少服務(wù)的嵌套層次项秉，并確保依賴于時(shí)間的任務(wù)不會(huì)穿越較深的服務(wù)棧绣溜。例如，數(shù)據(jù)存儲(chǔ)的API提供了一個(gè)寫入操作保證提交操作最終可以寫完成娄蔼。應(yīng)用發(fā)出寫命令后就可以繼續(xù)處理其它任務(wù)而不用等寫入存儲(chǔ)完成涮毫，應(yīng)用在這期間要能夠處理存儲(chǔ)數(shù)據(jù)和程序狀態(tài)不一致的問題，否則贷屎，就會(huì)引起用戶的二義性罢防。

減少網(wǎng)絡(luò)請(qǐng)求的數(shù)量有利于管理時(shí)延。設(shè)計(jì)交互較少的協(xié)議唉侄，盡量一次獲得所需的數(shù)據(jù)咒吐，而不是多次交互積累數(shù)據(jù)。例如：不要一次請(qǐng)求用戶的ZIP碼属划，一次請(qǐng)求用戶的電話號(hào)碼恬叹，改成在一次請(qǐng)求中獲取所有用戶聯(lián)系信息。

“在Netflix的數(shù)據(jù)中心中同眯，我們的網(wǎng)絡(luò)容量很大绽昼，速度很快而且高可靠，所以我們?cè)O(shè)計(jì)了很多和遠(yuǎn)端系統(tǒng)頻繁交互的協(xié)議API须蜗。而AWS網(wǎng)絡(luò)中時(shí)延變化幅度很大硅确，這時(shí)我們就必須從結(jié)構(gòu)上考慮盡量減少網(wǎng)絡(luò)交互，即使我們已經(jīng)是一個(gè)高分布式系統(tǒng)菱农。”

• John Ciancutti, Netflix Tech Blog: “5 Lessons We’ve Learned Using AWS”

這種方式也有一定局限性循未，那就是在單一響應(yīng)中增加有效負(fù)荷，提高了對(duì)帶寬的占用的妖。

另一種解決方案是使用節(jié)點(diǎn)間或者節(jié)點(diǎn)上的緩存。利用緩存嫂粟，可以減少網(wǎng)絡(luò)上請(qǐng)求的數(shù)量。緩存的另一個(gè)好處是如果所依賴的節(jié)點(diǎn)由于網(wǎng)絡(luò)問題變得不可靠赋元，如果設(shè)計(jì)得當(dāng)，服務(wù)借助緩存中的數(shù)據(jù)仍然可以繼續(xù)運(yùn)行搁凸。

安全

無論應(yīng)用是否在網(wǎng)絡(luò)上開放，安全都無處不在护糖！企業(yè)和公共網(wǎng)絡(luò)環(huán)境中的連接越來越多褥芒，應(yīng)用和服務(wù)也越來越變得對(duì)外開放。應(yīng)用中的數(shù)據(jù)傳輸需要被加密嫡良，包括在存儲(chǔ)時(shí)也應(yīng)該是密文的锰扶。應(yīng)用需要實(shí)現(xiàn)安全認(rèn)證和授權(quán)訪問控制，開發(fā)者需要掌握安全編碼的一些實(shí)踐寝受。

在有防火墻保護(hù)的數(shù)據(jù)中心坷牛，開發(fā)者認(rèn)為網(wǎng)絡(luò)是相對(duì)安全的，所以在數(shù)據(jù)中心中的通訊不用加密很澄，只需要關(guān)注和用戶客戶端程序或者web瀏覽器之間的安全通訊京闰。但是對(duì)一個(gè)云托管應(yīng)用程序，應(yīng)用程序和后端組件之間沒有防火墻保護(hù)甩苛，即使這些組件不需要對(duì)外部開放蹂楣，由于本身處于一個(gè)多租戶環(huán)境中，安全也是沒有保證的讯蒲。如果網(wǎng)絡(luò)是不能信任的痊土，那么開發(fā)者就必須對(duì)應(yīng)用程序的通訊以及開放的API進(jìn)行安全設(shè)計(jì)。

即使在私有云下部署的應(yīng)用程序墨林，開發(fā)者也不應(yīng)該低估安全的重要性赁酝，因?yàn)閼?yīng)用程序很可能日后過度到公有云或者混合云上。安全設(shè)計(jì)應(yīng)該作為全流程的考慮萌丈，而不應(yīng)該只是一種事后補(bǔ)充赞哗。

• 傳輸數(shù)據(jù)安全。分布式應(yīng)用依賴網(wǎng)絡(luò)來發(fā)送請(qǐng)求以及接受響應(yīng)辆雾。數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)耐暾院桶踩孕枰槐Ｗo(hù)。正如在公共互聯(lián)網(wǎng)上傳輸敏感信息要使用安全協(xié)議一樣月劈，開發(fā)者在云環(huán)境中也應(yīng)該采用同樣的方法度迂。網(wǎng)絡(luò)安全協(xié)議猜揪，如SSL和HTTPS用于防止網(wǎng)絡(luò)監(jiān)聽以及中間人攻擊±靶祝基本上云上的所有網(wǎng)絡(luò)通信都應(yīng)該有安全保護(hù)。
• API訪問控制褐缠。應(yīng)用組件和服務(wù)暴漏的API必須被保護(hù)风瘦。通過使用API管理解決手段万搔，例如使用OAuth來授權(quán)和控制對(duì)API的方式。利用這些技術(shù)昧谊，開發(fā)人員可以控制API和它的消費(fèi)者之間的溝通酗捌，只對(duì)認(rèn)證的客戶授權(quán)。不幸的是API管理并不是大多數(shù)公共云所提供的標(biāo)準(zhǔn)特性馅巷，開發(fā)者必須自行實(shí)現(xiàn)自己的安全訪問控制（類似OAuth）钓猬。
• 數(shù)據(jù)存儲(chǔ)安全撩独。如果網(wǎng)絡(luò)是不安全的，那么通過網(wǎng)絡(luò)訪問進(jìn)行數(shù)據(jù)存儲(chǔ)也是有風(fēng)險(xiǎn)的澳迫。應(yīng)該程序需要保證敏感數(shù)據(jù)寫入存儲(chǔ)時(shí)是加密的橄登。云服務(wù)商可以提供存儲(chǔ)加密服務(wù)讥此，以保證存儲(chǔ)數(shù)據(jù)被第三方訪問的安全性。但是如果秘鑰是由云提供商保管卒稳，那么可能會(huì)保護(hù)不足充坑。尤其需要保護(hù)個(gè)人身份信息，確保信用卡信息以及敏感的個(gè)人健康信息不被泄露捻爷。

只有在網(wǎng)絡(luò)通訊、API訪問和數(shù)據(jù)都在控制之下茵休，應(yīng)用程序才能在云中安全的運(yùn)行榕莺。

位置無關(guān)

云托管應(yīng)用程序和傳統(tǒng)應(yīng)用最重要的一個(gè)區(qū)別可能就是在云中網(wǎng)絡(luò)拓?fù)淇隙ㄊ菚?huì)發(fā)生變化的棵介。例如，云運(yùn)營商可能會(huì)動(dòng)態(tài)改變網(wǎng)絡(luò)路由以減少擁塞唠雕。一個(gè)共享的服務(wù)可能會(huì)被移動(dòng)到另一個(gè)區(qū)域的新虛擬機(jī)上岩睁，或者由于云的擁塞導(dǎo)致應(yīng)用程序的組件被重新分布到多個(gè)云提供商的網(wǎng)絡(luò)上揣云。

如果對(duì)應(yīng)用程序的配置進(jìn)行了地址硬編碼，這將會(huì)使應(yīng)用程序非常脆弱刘莹，不能很好地適應(yīng)變化焚刚，并會(huì)限制應(yīng)用程序自動(dòng)彈性伸縮的能力矿咕。

在云環(huán)境下服務(wù)或者組件的實(shí)例會(huì)隨著時(shí)間而變化，要充分利用云環(huán)境的能力雌团，應(yīng)用程序不能假設(shè)哪些請(qǐng)求應(yīng)該由哪些固定的服務(wù)進(jìn)行響應(yīng)士聪，以及不能假設(shè)這些服務(wù)的網(wǎng)絡(luò)位置剥悟。隨著負(fù)載的增加，新的實(shí)例被彈性伸縮創(chuàng)建出來以處理負(fù)載略板。云服務(wù)供應(yīng)商提供自動(dòng)彈性伸縮功能慈缔，用來根據(jù)負(fù)載監(jiān)控和開發(fā)人員制定的規(guī)則添加或者刪除服務(wù)實(shí)例。針對(duì)自動(dòng)彈性伸縮瓤檐，負(fù)載均衡需要負(fù)責(zé)分發(fā)負(fù)載到新的實(shí)例上或者讓有問題的實(shí)例下線挠蛉。

開發(fā)人員應(yīng)該設(shè)計(jì)應(yīng)用程序的架構(gòu)來支持云的動(dòng)態(tài)特性肄满。一些最佳實(shí)踐如下：、

• 不應(yīng)該有硬編碼的配置信息（例如服務(wù)的靜態(tài)IP地址）掰担〈ィ可以實(shí)現(xiàn)一個(gè)發(fā)現(xiàn)服務(wù)横媚，應(yīng)用組件可以向它動(dòng)態(tài)查詢給定服務(wù)的地址。
• 應(yīng)用組件應(yīng)該是無狀態(tài)的恢口，對(duì)應(yīng)用程序的當(dāng)前狀態(tài)一無所知穷躁。這時(shí)一個(gè)實(shí)例由于彈性伸縮被銷毀不會(huì)有任何數(shù)據(jù)損失问潭。相反，當(dāng)一個(gè)新的實(shí)例被啟動(dòng)時(shí)梳虽，它不應(yīng)該決定當(dāng)前的程序狀態(tài)灾茁。
• 應(yīng)用程序可以使用例如HTTPS這類協(xié)議谷炸，讓組件間松耦合旬陡。
• 應(yīng)用程序應(yīng)該在設(shè)計(jì)上利用云基礎(chǔ)設(shè)施提供的自動(dòng)彈性伸縮功能描孟。

在運(yùn)維上砰左，考慮下面的建議：

• 利用API代理去屏蔽最終的API接口，使消費(fèi)者免受API接口的變化青抛。

彈性擴(kuò)展

彈性是云計(jì)算的基本原則蜜另。彈性使得應(yīng)用程序能夠根據(jù)負(fù)載的變化自動(dòng)伸縮嫡意。這種可擴(kuò)展性使得對(duì)基礎(chǔ)設(shè)施的利用率更高。應(yīng)用程序必須進(jìn)行專門設(shè)計(jì)才可以支持靈活的可伸縮性此迅。簡單地把應(yīng)用部署到云上并不會(huì)獲得彈性擴(kuò)展的能力耸序，為了得到該能力組件需要設(shè)計(jì)的小鲁猩，并且無狀態(tài)。

面向服務(wù)架構(gòu)/組合能力

動(dòng)態(tài)發(fā)現(xiàn)的能力使得應(yīng)用程序可以動(dòng)態(tài)定位組件搅窿，而不是靜態(tài)綁定到某一固定實(shí)例上隙券。這種能力對(duì)于云中的組件來說十分重要娱仔，因?yàn)樵谠浦写嬖诟鞣N各樣的組件實(shí)例，故障是常見的薪铜，所以隨時(shí)會(huì)有新的實(shí)例彈出來恩溅。通過這種發(fā)現(xiàn)能力，新的組件啟動(dòng)無需更改任何配置就可以處理負(fù)載脚乡。

將應(yīng)用程序分解為許多職責(zé)單一的組件奶稠，有利于重用、彈性伸縮以及支持敏捷開發(fā)竹握。例如辆飘，將原來單一的消息存儲(chǔ)組件拆分成更小的消息處理組件、消息檢索組件和消息查詢組件等芹关。通過這種方法侥衬，對(duì)消息查詢組件的改進(jìn)可以不影響其余消息組件的代碼跑芳。

可管理性設(shè)計(jì)

在云環(huán)境中，應(yīng)用程序依賴于基礎(chǔ)設(shè)施和云服務(wù)提供商所管理的服務(wù)怀樟。通常情況下坡倔，提供商的目標(biāo)與開發(fā)人員的目標(biāo)一致罪塔，都想要提供可靠的服務(wù)和保證其高可用。然而瘩缆，提供商并不為開發(fā)人員的程序負(fù)責(zé)佃蚜。提供商專注于整個(gè)共享云服務(wù)的整體可用性着绊。例如归露，云提供商可能關(guān)閉某些服務(wù)剧包，故意讓網(wǎng)絡(luò)分區(qū)以隔離故障往果，或者在排除故障的過程中故意讓基礎(chǔ)設(shè)施出現(xiàn)錯(cuò)誤。所有這些都會(huì)影響到開發(fā)人員的應(yīng)用程序堕油。不幸的是肮之，應(yīng)用程序的所有者并不會(huì)擁有云管理員的控制權(quán)限，也不會(huì)獲得像在自己的數(shù)據(jù)中心中運(yùn)維團(tuán)隊(duì)的運(yùn)維細(xì)節(jié)攀圈，也沒有對(duì)云基礎(chǔ)設(shè)施的解決方案和升級(jí)方案的發(fā)言權(quán)赘来。

鑒于云管理員并不會(huì)為開發(fā)人員的應(yīng)用程序來管理和優(yōu)化基礎(chǔ)設(shè)施凯傲，所以應(yīng)用程序的所有者需要自行對(duì)其管理。這要求開發(fā)人員了解云基礎(chǔ)設(shè)施中正在發(fā)生什么幌缝。一種方式是編寫代碼探測(cè)及可視化云基礎(chǔ)設(shè)施內(nèi)部的問題涵卵，例如緩慢的請(qǐng)求或者服務(wù)超時(shí)荒叼。通過這些確保應(yīng)用程序的所有者可以獲得管理和監(jiān)控?cái)?shù)據(jù)，以便對(duì)基礎(chǔ)設(shè)施中的錯(cuò)誤主動(dòng)響應(yīng)坏晦。

監(jiān)控程序可以讓程序行為的各個(gè)方面可視化昆婿，包括性能、故障睁冬、資源消耗以及用戶事務(wù)等多律。這些監(jiān)控?cái)?shù)據(jù)可以讓應(yīng)用程序更容易維護(hù)，以及在高度動(dòng)態(tài)的環(huán)境中進(jìn)行問題定位。這些數(shù)據(jù)應(yīng)該被記錄下來以便定位人員分析問題帮碰，或者分析用戶行為以提高應(yīng)用程序的用戶體驗(yàn)殉挽。

與基礎(chǔ)設(shè)施解耦

與基礎(chǔ)設(shè)施解耦是一個(gè)一貫推薦的軟件工程實(shí)踐。在云環(huán)境中使用云供應(yīng)商提供的特有接口會(huì)導(dǎo)致軟件鎖定到固定的云供應(yīng)商一死，這會(huì)導(dǎo)致軟件難以或者不可能運(yùn)行在其它云平臺(tái)上傻唾。通過建立一個(gè)基礎(chǔ)設(shè)施抽象層，可以讓你更換底層服務(wù)的實(shí)現(xiàn)時(shí)無需重新應(yīng)用程序的代碼伪煤。

在數(shù)據(jù)中心中抱既，異構(gòu)性是很普遍的扁誓。一個(gè)應(yīng)用服務(wù)可能運(yùn)行在Linux虛擬機(jī)上，同時(shí)依賴一個(gè)運(yùn)行在windows服務(wù)器上的數(shù)據(jù)庫捷泞。開發(fā)人員根據(jù)它們開發(fā)和運(yùn)行的需求來選擇應(yīng)用的平臺(tái)肚邢，系統(tǒng)工程師通常在異構(gòu)的環(huán)境中為不同類型的服務(wù)提供標(biāo)準(zhǔn)的配置。

云環(huán)境經(jīng)常是多種多樣的贱纠，它們提供一組虛擬機(jī)鏡像响蕴，預(yù)先配置了特定的操作系統(tǒng)和軟件。不幸的是辖试，默認(rèn)的鏡像可能并不符合應(yīng)用程序的要求罐孝。例如肥缔，一個(gè)Windows鏡像可能并沒有滿足SQL Server要求的操作系統(tǒng)補(bǔ)丁。依賴于某一鏡像可能會(huì)導(dǎo)致不可移植性改艇，因?yàn)椴煌铺峁┥讨g的鏡像可能會(huì)存在不一致坟岔。這種鏡像間微小的差異看似問題不大，但是卻很可能引起應(yīng)用程序運(yùn)行時(shí)錯(cuò)誤承疲。

針對(duì)鏡像的不一致化問題的解決方案是為應(yīng)用提供自定義鏡像纪隙，有以下一些可以采用的方式：

• 在確定的環(huán)境下扛或，根據(jù)組件的需要提供精確化自定義的虛擬機(jī)鏡像；
• 提供一個(gè)通用鏡像悲伶，然后根據(jù)啟動(dòng)時(shí)的配置讓鏡像自行定制麸锉；
• 提供一組與應(yīng)用程序匹配的基礎(chǔ)設(shè)施配置的首選項(xiàng)舆声，提供給管理員以便他可以為應(yīng)用程序定制合適的基礎(chǔ)設(shè)施配置柳爽；

運(yùn)行時(shí)自配置可以讓應(yīng)用通過類型patch的方式讓實(shí)例保持最新的配置磷脯，甚至可以個(gè)性化配置娩脾。例如柿赊，實(shí)例從標(biāo)準(zhǔn)的Linux鏡像啟動(dòng)，然后進(jìn)行安全配置加載诡蜓，之后更新特定版本的Java奥邮，隨后配置與Java版本適合的容器，每一個(gè)配置都在前一個(gè)的基礎(chǔ)上動(dòng)態(tài)進(jìn)行。這種運(yùn)行時(shí)配置的缺點(diǎn)則是它會(huì)在彈性伸縮的時(shí)候加長實(shí)例的啟動(dòng)時(shí)間覆旱，造成性能上的影響扣唱。

由于廣泛采用TCP作為互聯(lián)網(wǎng)的標(biāo)準(zhǔn)傳輸協(xié)議，將下層的網(wǎng)絡(luò)異質(zhì)性進(jìn)行了屏蔽炼彪。應(yīng)用層的協(xié)議如HTTP又提供了進(jìn)一步的抽象正歼。流行的REST模式建立在HTTP之上，提供了一套方便的通過JSON或者XML更輕量級(jí)數(shù)據(jù)傳輸協(xié)議進(jìn)行資源描述的方式喜爷。REST的一個(gè)缺點(diǎn)則是在發(fā)送和接收格式里面缺少API的標(biāo)準(zhǔn)設(shè)計(jì)檩帐，例如可以將API的版本放在資源路徑中（例如：/api/v1/user）另萤，或者當(dāng)做請(qǐng)求參數(shù)（/api/user?version=1），或者作為報(bào)文的包頭資源（Accept: application/json;apiversion=1）

應(yīng)用程序在跨不同API提供者的時(shí)候不能讓API的設(shè)計(jì)不一致泛源。使用標(biāo)準(zhǔn)協(xié)議如HTTP/HTTPS，開發(fā)人員應(yīng)該建立類似REST的API毒嫡，使得他們的API保持一致性且易用使用兜畸。這種標(biāo)準(zhǔn)化的程度將越來越重要碘梢，最終將發(fā)現(xiàn)和消費(fèi)的方式進(jìn)行模式化定義，而不是被硬編碼進(jìn)程序中肛鹏。

租賃設(shè)計(jì)

除非最初目標(biāo)就是作為一個(gè)SaaS應(yīng)用恩沛，否則大多數(shù)企業(yè)應(yīng)用程序不會(huì)將租賃作為其設(shè)計(jì)的一部分雷客。然而，最佳實(shí)踐建議對(duì)于云計(jì)算應(yīng)用程序來說理解和處理租賃模式是一個(gè)不可或缺的組成部分皱卓〔看考慮一組用戶想要使用你的應(yīng)用程序服務(wù)，但是他們的數(shù)據(jù)由于安全性必須被隔離掐禁，這會(huì)為你的程序帶來哪些潛在的影響穆桂。

使最終用戶自服務(wù)

許多企業(yè)應(yīng)用程序需要某種類型的授權(quán)融虽，當(dāng)用戶請(qǐng)求接入的時(shí)候會(huì)給用戶按照特定的角色分配權(quán)限。這時(shí)會(huì)發(fā)生一些配置過程般又，創(chuàng)建一類包含用戶訪問信息的賬戶。對(duì)于客戶端應(yīng)用程序茴迁，用戶使用自注冊(cè)工具提供個(gè)人信息堕义。同樣的，用戶開始期望企業(yè)應(yīng)用程序也有相同的能力洒擦。

帶寬感知

在設(shè)計(jì)云應(yīng)用程序的時(shí)候很容易假設(shè)帶寬不是問題怕膛。對(duì)于單個(gè)請(qǐng)求來說，負(fù)載和可用帶寬比起來確實(shí)微不足道掸茅。但是對(duì)于云計(jì)算中的大規(guī)模應(yīng)用程序柠逞，每秒成千上萬的請(qǐng)求穿越許多服務(wù)板壮，消耗的帶寬非常可觀。

正如前面提到的聊疲，云應(yīng)用程序運(yùn)行在共享的不受開發(fā)人員控制的網(wǎng)絡(luò)基礎(chǔ)設(shè)施上。雖然理論上可以預(yù)測(cè)應(yīng)用程序的帶寬占用率阱表，但是往往可用帶寬比預(yù)想的要小贡珊。與傳統(tǒng)的數(shù)據(jù)中心情況不同门岔，云上缺乏對(duì)網(wǎng)絡(luò)拓?fù)涞目刂疲_發(fā)人員不能假定他們的應(yīng)用組件之間通過高速交換直接連接在一起糠悯。

由于帶寬有限，所以需要盡量少用互艾，以下一些技術(shù)可以采用：

• 定義交互較少的協(xié)議；
• 僅針對(duì)需要的組件進(jìn)行精簡的答復(fù)阅悍；
• 通過使用緩存減少重復(fù)的請(qǐng)求节视；

對(duì)于帶寬要求很高的應(yīng)用程序悦昵，例如視頻流，最好將這些高帶寬部分移到云的外面寡痰。例如Netflix公司棋凳，將視頻緩存在內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）上而非亞馬遜的云端。然而贞滨，Netflix也在使用云中做視頻轉(zhuǎn)碼計(jì)算晓铆，利用云的彈性可以并行的進(jìn)行視頻編碼绰播，在這個(gè)過程中網(wǎng)絡(luò)帶寬利用相對(duì)較少，因?yàn)檫@個(gè)過程是非實(shí)時(shí)的链蕊，即使對(duì)計(jì)算限制帶寬也并不會(huì)對(duì)最終用戶的延遲感受造成影響谬泌。

資源消耗感知

云提供商有一個(gè)資源消耗的計(jì)費(fèi)模型，對(duì)于計(jì)算陪蜻、存儲(chǔ)囱皿、數(shù)據(jù)傳輸以及其它服務(wù)進(jìn)行收費(fèi)。開發(fā)人員設(shè)計(jì)應(yīng)用程序架構(gòu)的時(shí)候要盡可能降低成本嘱腥，例如減少網(wǎng)絡(luò)中的數(shù)據(jù)傳輸規(guī)模，采用許多減少成本的技術(shù)橱脸，例如緩存等等添诉。

最小化傳輸開銷

傳輸成本主要有兩個(gè)方面：

• 在數(shù)據(jù)傳輸過程中的打包和解包造成的時(shí)間和處理成本医寿；
• 傳遞數(shù)據(jù)的經(jīng)濟(jì)成本；

在傳統(tǒng)的數(shù)據(jù)中心中须眷，應(yīng)用程序的網(wǎng)絡(luò)流量不會(huì)被收費(fèi)沟突。然而，在云上所有類型的資源消耗都是要被收費(fèi)的扩劝，包含網(wǎng)絡(luò)數(shù)據(jù)傳輸棒呛。像亞馬遜之類的云提供商對(duì)數(shù)據(jù)傳輸采用關(guān)稅制度域携，根據(jù)數(shù)據(jù)傳輸?shù)脑春湍繕?biāo)地址進(jìn)行統(tǒng)計(jì)計(jì)費(fèi)。例如將應(yīng)用轉(zhuǎn)移到EC2上是免費(fèi)的，但是要再遷出來就是相當(dāng)昂貴的蒲凶。很多云提供商通過收取退出費(fèi)用將客戶鎖定到他們的平臺(tái)上。如果一個(gè)應(yīng)用程序產(chǎn)生大量的數(shù)據(jù)（例如支持用戶上傳內(nèi)容的應(yīng)用）宠默，遷移到其它云服務(wù)提供商的費(fèi)用可能會(huì)非常的高灵巧。

構(gòu)建云應(yīng)用程序的時(shí)候抹沪，開發(fā)人員應(yīng)該將數(shù)據(jù)傳輸?shù)某杀咀鳛樵O(shè)計(jì)的一個(gè)重要因素融欧。對(duì)于一個(gè)成功的分布式應(yīng)用程序來說數(shù)據(jù)傳輸是一個(gè)關(guān)鍵因素卦羡。開發(fā)人員應(yīng)該努力減少流量。例如Netflix將視頻存儲(chǔ)在EC2之外的CDN中是有道理的欠肾，CDN中的存儲(chǔ)和傳輸成本比在EC2中將數(shù)據(jù)發(fā)送到外部互聯(lián)網(wǎng)中的收費(fèi)開銷要少很多刺桃。數(shù)據(jù)傳輸成本對(duì)Netflix非常關(guān)鍵吸祟，以至于他們甚至研發(fā)了自己的CDN硬件并在經(jīng)營區(qū)域使用自己的CDN服務(wù)。

同樣封豪，打包和解包的成本也應(yīng)該被關(guān)注炒瘟。例如選擇數(shù)據(jù)壓縮以減少數(shù)據(jù)傳輸成本疮装，卻會(huì)增加額外的CPU開銷，處理壓縮數(shù)據(jù)產(chǎn)生的負(fù)載可能會(huì)需要更多的虛機(jī)實(shí)例導(dǎo)致成本增加刷袍。

一般情況下樊展，開發(fā)人員應(yīng)該創(chuàng)建資源消耗感知的應(yīng)用程序以便尋求應(yīng)用程序性能和成本之間的平衡。

“換句話說你需要一個(gè)監(jiān)控應(yīng)用雷酪，它需要設(shè)計(jì)的高效盡量不去影響被監(jiān)控服務(wù)的行為涝婉。另外關(guān)注你的監(jiān)控粒度，是每次API調(diào)用寞射，還是每百萬次锌钮，還是每CPU/hour？”

• Gartner. “Cloud Characteristics, Principles and Design Patterns.”

開發(fā)人員可以使用以下方式減少數(shù)據(jù)傳輸開銷：

• 減少負(fù)載大小
  • 提供的API只返回客戶需要的數(shù)據(jù)（“partial response"）策治；
  • 采用數(shù)據(jù)壓縮兰吟，但是權(quán)衡編解碼帶來的CPU成本；
• 減少數(shù)據(jù)傳輸次數(shù)
  • 緩存不可變數(shù)據(jù)履腋；
  • 避免頻繁交互的協(xié)議設(shè)計(jì)遵湖；
• 使用監(jiān)控
  • 跟蹤數(shù)據(jù)的傳輸過程定位潛在的優(yōu)化點(diǎn)晚吞；
  • 使用負(fù)載生成工具人工產(chǎn)生流量去檢驗(yàn)優(yōu)化帶來的影響；

MagicBowen （e.bowen.wang@icloud.com） 翻譯迁沫， 未完待續(xù)...