本文要點(diǎn)
在向云端遷移時(shí)，如果使用的是以架構(gòu)為中心的方法，那么并不會提供用戶想象中的優(yōu)點(diǎn)。
盡可放心使用那些無需自己管理架構(gòu)的甲方云服務(wù)。
在規(guī)劃故障時(shí)，確?？紤]了應(yīng)用故障、服務(wù)故障、架構(gòu)故障和設(shè)施故障。
認(rèn)真考慮所需的服務(wù)規(guī)模，充分利用云所提供的彈性，一些時(shí)候，還需要考慮能節(jié)約費(fèi)用的長效合同。
最近我參與了一個(gè)企業(yè)IT資產(chǎn)組合向云端的遷移，其中包括了基礎(chǔ)架構(gòu)和應(yīng)用。我注意到我們過分注重于基礎(chǔ)架構(gòu)方面，而忽視了云端對應(yīng)用本身的影響。在我看來，應(yīng)用架構(gòu)在云時(shí)代扮演著更重要的角色。根據(jù)自己在云端實(shí)施方面的經(jīng)驗(yàn)，我提出了一些專注于應(yīng)用程序架構(gòu)的原則。遵循這些原則，將有助于用戶真正地獲得云計(jì)算的優(yōu)勢。如果你僅依賴于以基礎(chǔ)架構(gòu)為中心的方法，那么遷移到云端將只會是又一次轉(zhuǎn)變，而非轉(zhuǎn)型。
松耦合。云使得我們可以按需擴(kuò)展和縮小容量。但這只有當(dāng)我們的系統(tǒng)（或子系統(tǒng)）是無狀態(tài)時(shí)才可以實(shí)現(xiàn)。系統(tǒng)（或子系統(tǒng)）應(yīng)是松耦合的，這樣各個(gè)部分可以根據(jù)各自的負(fù)載需求分別進(jìn)行縮放。
如果應(yīng)用程序和Web服務(wù)器是松耦合的，那么兩者均可獨(dú)立地縮放。要實(shí)現(xiàn)這一點(diǎn)，需使用云原生的負(fù)載均衡器或隊(duì)列機(jī)制。這允許系統(tǒng)縮放到任意規(guī)模，去除了依賴約束。此外，在混合云場景中，隊(duì)列機(jī)制是連接系統(tǒng)的最好選擇之一。
單一職責(zé)的服務(wù)器。這個(gè)概念是我從面向?qū)ο缶幊讨薪梃b而來的。一般來說，我們傾向于將一臺服務(wù)器用于多個(gè)目的。然而，云使得我們可以創(chuàng)建不同規(guī)模的服務(wù)器，從非常小到非常大。反過來，這使得我們可在指定的服務(wù)器上僅部署一個(gè)代碼庫或可執(zhí)行單元。通過這樣的做法，一個(gè)應(yīng)用程序組件的更改就不會影響到其它任何組件。要實(shí)現(xiàn)上述模式，請遵循藍(lán)綠部署（Blue-Green Deployment）方法，確保對一個(gè)組件的部署不會造成其它組件的停機(jī)。
自動部署。云使我們具備了按需提供資源的能力。但是除非我們可以做到無需任何手動干預(yù)就在動態(tài)配置的基礎(chǔ)架構(gòu)上運(yùn)行應(yīng)用程序，我們才能充分利用這種能力。這意味著我們不能交互式登錄到服務(wù)器去部署應(yīng)用，應(yīng)該使用編程的方式去應(yīng)用配置和設(shè)置。換句話說，應(yīng)禁用主機(jī)登錄，通過云提供商提供的腳本或API完成所有的配置和設(shè)置。
使用本地云服務(wù)。許多云實(shí)施依然專注于將云主要用作“基礎(chǔ)架構(gòu)即服務(wù)”（IaaS）的托管模式。在自治（Self-managed）模式中，定義用于橫向和縱向擴(kuò)展的觸發(fā)器是我們自身的職責(zé)。對于許多原生云服務(wù)，云提供商負(fù)責(zé)底層硬件設(shè)施的橫向和縱向擴(kuò)展。云服務(wù)提供商負(fù)責(zé)硬件的配置、構(gòu)建和設(shè)置、復(fù)制，以及一些情況下的軟件打補(bǔ)丁和集群擴(kuò)展。云的真正優(yōu)勢所在，只能通過使用原生云服務(wù)實(shí)現(xiàn)。
例如，使用AWS Lambda、Azure Functions、SQS或類似的原生云（Cloud Native）服務(wù)，就可以擺脫對基礎(chǔ)架構(gòu)的定義。將這個(gè)工作交給云提供商！使用托管數(shù)據(jù)庫服務(wù)，例如AWS RDS，DynamoDB或Azure DocumentDB，避免使用自治的數(shù)據(jù)庫。這種做法存在一個(gè)缺點(diǎn)，它會將應(yīng)用程序綁定到相應(yīng)的云平臺。事實(shí)上，如果使用了云互操作（Cloud Interoperability）模型，就無法充分地利用云。這類似于不同的操作系統(tǒng)以自身的方式提供了類似的功能（例如，文件系統(tǒng)訪問，網(wǎng)絡(luò)，編解碼器等），每個(gè)云提供商都對通用的功能給出了自身獨(dú)有的建議方法。
將本地存儲看做是臨時(shí)存儲。作為擴(kuò)展或部署實(shí)驗(yàn)的組成部分，托管在云虛擬機(jī)上的應(yīng)用可隨時(shí)丟棄。重要的是，應(yīng)用不會在虛擬機(jī)本地存儲任何值。虛擬機(jī)的本地存儲應(yīng)被視為臨時(shí)存儲。它會與虛擬機(jī)一并丟棄。在傳統(tǒng)方法中，應(yīng)用將配置、日志文件、圖像等存儲在本地存儲中。然而，需要改變這種做法，任何持久信息都應(yīng)轉(zhuǎn)移到一個(gè)持久的服務(wù)上，實(shí)現(xiàn)數(shù)據(jù)塊或?qū)ο蟮拇鎯ΑＴ茟?yīng)用程序應(yīng)支持藍(lán)綠部署，這只有在當(dāng)前執(zhí)行的代碼沒有綁定到本地存儲時(shí)才可能實(shí)現(xiàn)。
設(shè)計(jì)應(yīng)始終針對故障。在云中，我們不知道應(yīng)用運(yùn)行所在的位置。硬件會易于出現(xiàn)故障，軟件更新和補(bǔ)丁也會易于出錯(cuò)。最好是在架構(gòu)和設(shè)計(jì)時(shí)，就考慮到對應(yīng)用故障的處理，而不是去考慮并力圖實(shí)現(xiàn)穩(wěn)健性。穩(wěn)健性是永遠(yuǎn)也不可能實(shí)現(xiàn)的。消除單點(diǎn)故障（SPOF，Single Point Of Failure），逐層構(gòu)建彈性。這樣，即使底層硬件發(fā)生故障，應(yīng)用也可正常運(yùn)行。