多云通常被認為是企業(yè)的一個進化步驟，是企業(yè)從單一云平臺的起始階段走向多云產(chǎn)品的“***”方法。而各種因素決定了這一點。對于某些企業(yè)來說，需要平臺特定功能的工作負載的多樣性。對于其他企業(yè)來說，這是一個演變的過程，也可能是并購的結(jié)果。

[[227950]]

最近，人們看到企業(yè)選擇多云作為主要的云優(yōu)先策略。在某些情況下，其原因在于減少對單個供應(yīng)商的依賴，因為云計算平臺供應(yīng)商開始在其產(chǎn)品中增加更多的粘性。在其他情況下，則根據(jù)工作負載特性來優(yōu)化成本。在這兩個方面都有激烈的爭論，這與人們在硬件平臺上看到的爭論并沒有什么不同。

無論企業(yè)由于什么原因而選擇在多云環(huán)境下運行，它確實會帶來一些復(fù)雜性，如果不仔細管理，可能會偏離其采用多云策略實現(xiàn)成本節(jié)約的目標(biāo)，并降低其性能。

這就是為什么可視度如此重要的原因。但是，就像采用多云一樣，為了獲得業(yè)務(wù)可見性，需要改變數(shù)據(jù)集(除了本地網(wǎng)絡(luò)之外，還要測量廣域網(wǎng)、互聯(lián)網(wǎng)、云計算和SaaS提供商的健康狀況和性能)。以下將分析與多云部署相關(guān)的一些關(guān)鍵術(shù)語，解釋為什么傳統(tǒng)的可視性方法在云端方面的不足，并探索獲取多云操作可見性所需的方法。

混合云與多云

混合云通常是指現(xiàn)有傳統(tǒng)數(shù)據(jù)中心的組合，其中一些服務(wù)是從云中使用的。如今的大多數(shù)應(yīng)用程序都是混合的，因為它們使用一個或多個基于API的外部服務(wù)，無論是用于身份驗證、付款還是物流。如果企業(yè)的內(nèi)部托管的應(yīng)用程序調(diào)用Azure AD或Okta進行身份驗證，則可以有效地運行混合云。如果企業(yè)網(wǎng)站有PayPal或Visa付款小工具，那么所使用的是混合云。

隨著應(yīng)用程序被霧化成其組成服務(wù)并僅通過結(jié)構(gòu)化API調(diào)用進行通信，可以分別定位和縮放每個組件。這使得像AWS這樣的基礎(chǔ)設(shè)施和平臺服務(wù)非常誘人。因此，雖然某些核心資產(chǎn)和功能可能仍然存在，但企業(yè)可以獨立擴展無狀態(tài)組件，并讓它們駐留在距離用戶更近的云中。

VMware公司是企業(yè)云中的行業(yè)主導(dǎo)者，并且通過與亞馬遜公司合作提供可行的混合云服務(wù)。AWS上的VMware Cloud使企業(yè)可以輕松地將虛擬機工作負載和虛擬網(wǎng)絡(luò)擴展到Amazon云平臺，同時仍然通過vSphere管理所有內(nèi)容。

另一方面，多云是指將企業(yè)的內(nèi)部部署數(shù)據(jù)中心與兩家或兩家以上云計算供應(yīng)商結(jié)合使用。

而多云包括任何類型的外部云提供，例如IaaS、PaaS或SaaS。這是一個更復(fù)雜的環(huán)境，具有多個基礎(chǔ)平臺，每個平板都有自己的編排習(xí)慣。這里的目標(biāo)是讓成本經(jīng)濟性和***組合決定工作負載的位置。從管理的角度來看，企業(yè)正在處理一個難以預(yù)測的程度和變化速度，這可能是一個挑戰(zhàn)。此外，企業(yè)的呼叫流程現(xiàn)在包含更多的排列組合，這使得性能調(diào)整和故障排除特別復(fù)雜。

微服務(wù)API

微服務(wù)架構(gòu)已經(jīng)流行了很多年，它已經(jīng)從根本上改變了新的應(yīng)用程序的構(gòu)建方式。Uber是主要運行在微服務(wù)生態(tài)系統(tǒng)上的一個很好的示例。Uber依靠第三方API進行映射、支付、通知和電話。這些API中的每一個都可能進一步依賴于其他后端API。因此，每當(dāng)乘客乘坐Uber時，需要多個API流，云計算服務(wù)和網(wǎng)絡(luò)路徑才能正常工作，以便搭車回家。

這是IT組織以前從未處理過的復(fù)雜程度。當(dāng)一切正常時，其復(fù)雜性并不明顯，但故障時對于故障排除來說非常復(fù)雜。

一個很好的例子就是最近的AWS停機中斷。從基礎(chǔ)設(shè)施的角度來看，AWS云服務(wù)的電力中斷很小，系統(tǒng)恢復(fù)的時間相當(dāng)短。但是，在初始事件發(fā)生后的幾個小時內(nèi)，依靠AWS Direct Connect進行后端數(shù)據(jù)流的應(yīng)用程序仍然失效。其中包括Atlassian，Slack和Twilio在內(nèi)的許多應(yīng)用程序和服務(wù)，其提供者未能考慮其多個云平臺之間隱藏的依賴關(guān)系。

2017年3月2日的停電事件，影響亞馬遜AWS-East Region(Ashburn)地區(qū)的一小部分服務(wù)，很快就成為AWS Direct Connect用戶面臨的主要問題。ThousandEyes透露，超過240項關(guān)鍵服務(wù)感受到了停電的影響。

一般來說，云計算和互聯(lián)網(wǎng)面臨的挑戰(zhàn)之一是缺乏可見性。許多傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控工具都依賴于簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)、流量或數(shù)據(jù)包捕獲等技術(shù)。所有這些都需要對構(gòu)成數(shù)據(jù)中心的服務(wù)器、交換機、防火墻和路由器進行某種級別的特權(quán)訪問。這些都不能用于IaaS或PaaS服務(wù)。企業(yè)無法在Microsoft Azure內(nèi)部竊聽，或者從亞馬遜的數(shù)據(jù)中心傳輸流記錄。因此，企業(yè)已習(xí)慣于將云計算看作是一個黑盒子，隱藏在隱形外衣之下。

這種方法不適用于單個云平臺或混合云，它當(dāng)然不適用于多云基礎(chǔ)設(shè)施。路徑組合的數(shù)量隨著云平臺的數(shù)量而有序地增加。這些路徑中的每一條都有許多不可預(yù)測的因素。因此企業(yè)的風(fēng)險增加了數(shù)量級。那么就不能繼續(xù)把這些云平臺當(dāng)成黑匣子，那么將有什么選擇?

云計算沒有遮掩

一些云服務(wù)商提供他們自己的網(wǎng)絡(luò)可見性解決方案，例如，在Microsoft Azure中，企業(yè)可以通過ExpressRoute連接將其企業(yè)域從網(wǎng)絡(luò)可視化到Azure內(nèi)部的虛擬網(wǎng)絡(luò)(VNet)。但是，這并不能為企業(yè)提供完整的端到端圖片，其中包括外部相關(guān)性。當(dāng)然，這種解決方案只針對Azure，并不提供有關(guān)其他云計算或傳統(tǒng)數(shù)據(jù)中心的信息。采用多云策略，隨著工作負載的移動，企業(yè)的可見性解決方案需要遵循資源，而不管其位于何處。

那么怎么能做到這一點?有一些主動監(jiān)控技術(shù)使用特殊的儀器化應(yīng)用程序調(diào)用來了解應(yīng)用程序可用性和響應(yīng)時間，以及用于交付這些應(yīng)用程序的底層網(wǎng)絡(luò)和云計算基礎(chǔ)設(shè)施。這不需要來自云計算基礎(chǔ)設(shè)施的任何特權(quán)信息，因此可以是云計算和供應(yīng)商不可知的。在通常情況下，所有這些都是資源的目標(biāo)URL。

而這是ThousandEyes公司采取的方法，運營一組全球范圍的軟件代理，執(zhí)行互聯(lián)網(wǎng)感知網(wǎng)絡(luò)監(jiān)控。ThousandEyes公司通過互聯(lián)網(wǎng)從多個有利位置監(jiān)控關(guān)鍵服務(wù)，并通過算法將數(shù)據(jù)關(guān)聯(lián)起來以了解服務(wù)影響。因此，企業(yè)能夠確定依賴于AWS Direct Connect的超過240項關(guān)鍵服務(wù)受到2017年3月2日停電的影響。

云端沒有穩(wěn)定狀態(tài)。所有的IaaS和PaaS供應(yīng)商都大量使用devops和自動化工具，所以變化迅速發(fā)生，無需事先通知。與此同時，多線程部署通常使用容器化和自動化服務(wù)，如Kubernetes將工作負載轉(zhuǎn)移到***云平臺。在這個瞬息萬變的世界中，企業(yè)需要可持續(xù)的可見性來反映應(yīng)用程序交付路徑中的變化，以便為其提供完整的***視圖。