混合云架構(gòu)將跨地理分布的公共云、私有云和本地基礎(chǔ)設(shè)施的多個(gè)環(huán)境匯集在一起??，作為一個(gè)單一的托管 IT 基礎(chǔ)設(shè)施。在基本層面上，這可能只是一家企業(yè)在其本地?cái)?shù)據(jù)中心托管遺留應(yīng)用程序——在公共云服務(wù)上調(diào)用一些API 。然而，這種初步實(shí)施并不是混合云基礎(chǔ)架構(gòu)的最佳旗艦用例。

最大潛力的混合云包括利用云實(shí)現(xiàn)基礎(chǔ)設(shè)施即服務(wù) (IaaS)、平臺即服務(wù) (PaaS) 和軟件即服務(wù) (SaaS) 功能，能夠托管在本地、私有云和公共云以及邊緣環(huán)境的組合上運(yùn)行應(yīng)用程序，并具有無鎖定多云方法的靈活性。了解設(shè)計(jì)模式和要考慮的關(guān)鍵因素有助于提煉設(shè)計(jì)此類混合云架構(gòu)所涉及的復(fù)雜性。

現(xiàn)代混合云架構(gòu)的基本要素

最近，混合云方法通常涉及將一些服務(wù)從本地基礎(chǔ)設(shè)施遷移到公共或私有云，并且這些服務(wù)相互通信。即使構(gòu)建了一個(gè)新的應(yīng)用程序以托管在公共云上，它也會(huì)遵循傳統(tǒng)的面向服務(wù)的架構(gòu) (SOA)。

但是，今天，基于微服務(wù)的架構(gòu)是混合云模型的核心。微服務(wù)是一種將應(yīng)用程序分解為更小的組件或服務(wù)以便于部署的方法。這些微服務(wù)與 SOA 中的服務(wù)不同，因?yàn)樗鼈冇凶约旱募夹g(shù)堆棧并部署在容器中，容器是包含微服務(wù)及其依賴庫的輕量級可執(zhí)行文件。

容器是輕量級的，因?yàn)樗鼈児蚕頇C(jī)器的操作系統(tǒng) (OS) 內(nèi)核，這意味著每個(gè)容器只包含微服務(wù)及其依賴項(xiàng)。任何操作系統(tǒng)依賴項(xiàng)都從容器所在的硬件共享。這種虛擬化允許微服務(wù)在任何本地或云環(huán)境中獨(dú)立部署。而自給自足性使得微服務(wù)與 SOA 有很大不同，更適合云部署，其中對彈性和靈活性的需求以優(yōu)化云資源是至關(guān)重要的。

容器化作為在任何環(huán)境中隔離進(jìn)程的打包模型并不是一個(gè)新概念，但2013 年作為容器引擎出現(xiàn)的Docker創(chuàng)建了一個(gè)通用的打包結(jié)構(gòu)。此外，像Kubernetes這樣的容器編排平臺可以跨混合云環(huán)境自動(dòng)部署 Docker 或任何其他符合開放容器倡議 (OCI) 標(biāo)準(zhǔn)的容器。

容器化范式對混合云的影響

容器化的出現(xiàn)有助于真正利用混合云的優(yōu)勢，重點(diǎn)轉(zhuǎn)移到工作負(fù)載的輕松移植和服務(wù)在您選擇的云環(huán)境上的自動(dòng)部署。幾年前，關(guān)于混合云架構(gòu)的討論中的關(guān)鍵問題集中在每個(gè)工作負(fù)載應(yīng)該在哪個(gè)云或本地環(huán)境中運(yùn)行，以及如何讓這些不同的環(huán)境相互通信。從本質(zhì)上講，托管位置和物理連接仍然是主要考慮因素。

例如，處理敏感數(shù)據(jù)的應(yīng)用程序?qū)⑼泄茉谒接性粕稀；蛘撸y以實(shí)現(xiàn)現(xiàn)代化的遺留應(yīng)用程序?qū)⒗^續(xù)存在于本地。同時(shí)，組織會(huì)將需要可擴(kuò)展性的應(yīng)用程序提升并轉(zhuǎn)移到公共云環(huán)境。然后，他們將建立虛擬專用網(wǎng)絡(luò) (VPN) 隧道或消息流等通道，以促進(jìn)環(huán)境之間的通信。

這些仍然是需要考慮的重要因素，但是對于容器化范例，重點(diǎn)已經(jīng)從物理位置和連接性轉(zhuǎn)移到將工作負(fù)載從一個(gè)環(huán)境無縫移動(dòng)到另一個(gè)環(huán)境的靈活性。因此，無論是在私有云還是公共云中托管應(yīng)用程序都不一定是一個(gè)嚴(yán)格的決定。如果該策略不起作用，則可以輕松地跨環(huán)境移動(dòng)打包為容器的工作負(fù)載、擴(kuò)大和縮小規(guī)模，甚至在不同環(huán)境中運(yùn)行相同服務(wù)的實(shí)例。所有這一切促成了現(xiàn)代、高度可用且靈活的架構(gòu)，該架構(gòu)可提供高性能、資源效率和成本節(jié)約。

設(shè)計(jì)混合云架構(gòu)時(shí)的主要考慮因素

混合云架構(gòu)的設(shè)計(jì)和實(shí)施需要考慮很多因素，包括企業(yè)的業(yè)務(wù)目標(biāo)、當(dāng)前的技術(shù)格局、數(shù)字化轉(zhuǎn)型目標(biāo)和安全考慮。由于這種具有多個(gè)混合云解決方案的架構(gòu)可能會(huì)很快變得復(fù)雜，因此利用 ops 工具進(jìn)行集中、無縫和可擴(kuò)展的云管理非常重要。以下是創(chuàng)建混合云戰(zhàn)略時(shí)需要考慮的一些因素。

現(xiàn)代化戰(zhàn)略

對于大多數(shù)組織而言，混合云計(jì)算的想法始于現(xiàn)代化或?qū)⑵鋺?yīng)用程序從本地遷移到云端，有幾種方法可以執(zhí)行此操作：

• 直接遷移：啟動(dòng)現(xiàn)代化的最常見方法之一，直接遷移是將整個(gè)應(yīng)用程序從本地遷移到云環(huán)境。這涉及更改底層硬件以利用安全且可擴(kuò)展的云計(jì)算資源和基礎(chǔ)設(shè)施服務(wù)。當(dāng)沒有足夠的時(shí)間進(jìn)行重構(gòu)或重新架構(gòu)時(shí)，這是一個(gè)方便的選擇。
• 重構(gòu)：與其將完整的單體應(yīng)用程序遷移到云端——這不僅耗時(shí)而且可能是不必要的——最好確定一兩個(gè)服務(wù)（沒有合規(guī)性或緊急性能改進(jìn)需求的東西），重構(gòu)它們（例如，添加膠水代碼以公開 REST API，因?yàn)橐郧暗姆?wù)接口可以與特定平臺緊密耦合）并部署在云端。這種分階段的移動(dòng)提供了將少量流量路由到云上的新實(shí)例的機(jī)會(huì)，以獲得測試和學(xué)習(xí)的機(jī)會(huì)，并最終將服務(wù)的所有實(shí)例移動(dòng)到云中。
• 重構(gòu)：最后，還有一種最復(fù)雜的方法，將所有系統(tǒng)組件分解為單一職責(zé)的微服務(wù)，這些微服務(wù)是模塊化的，并且具有獨(dú)立的生產(chǎn)路徑和容器化。這涉及完全重寫并且是一個(gè)昂貴的過程，但它也使回報(bào)最大化。

統(tǒng)一控制平面

企業(yè)運(yùn)營團(tuán)隊(duì)通過統(tǒng)一的控制平面管理他們的云環(huán)境，該控制平面提供跨環(huán)境的內(nèi)聚和一致的云運(yùn)營體驗(yàn)。它支持核心集群管理功能，如工作負(fù)載調(diào)度和編排、持續(xù)集成和部署 (CI/CD) 管道、日志記錄、遙測和聯(lián)合安全。目標(biāo)是從應(yīng)用程序團(tuán)隊(duì)中抽象出各個(gè)云服務(wù)提供商 (CSP) 和運(yùn)行時(shí)的底層復(fù)雜性，并為運(yùn)營團(tuán)隊(duì)提供一個(gè)通用接口來管理企業(yè)中的工作負(fù)載。

以下是統(tǒng)一控制平面的一些優(yōu)勢：

• 利用跨虛擬機(jī)、容器或無服務(wù)器部署的動(dòng)態(tài)工作負(fù)載放置策略。
• 盡享輕松加入更多提供商或邊緣位置的能力。
• 構(gòu)建功能即服務(wù) (FaaS)等 PaaS 功能，這些功能具有高可用性并可跨不同的云實(shí)施工作。
• 集中合規(guī)管理。

API 網(wǎng)關(guān)和服務(wù)網(wǎng)格

集中式API 網(wǎng)關(guān)和服務(wù)網(wǎng)格等架構(gòu)模式支持對路由、服務(wù)到服務(wù)通信、安全性、速率限制和可觀察性等云功能進(jìn)行透明管理。

API網(wǎng)關(guān)?作為跨地域的統(tǒng)一前門，負(fù)責(zé)處理“南北”流量功能，包括：

• 用戶認(rèn)證與授權(quán)
• 節(jié)流和速率限制
• 交通管理
• API生命周期管理
• 云安全防護(hù)欄
• 邊緣分析

另一方面，服務(wù)網(wǎng)格處理服務(wù)依賴項(xiàng)之間的“東西向”流量：

• 集群中的安全服務(wù)到服務(wù)通信
• 具有負(fù)載平衡、路由規(guī)則、重試、故障轉(zhuǎn)移、災(zāi)難恢復(fù)和故障注入的流量管理
• 集群內(nèi)所有流量的指標(biāo)、日志和跟蹤遙測，包括集群出口和入口
• 分布式可追溯性以檢測跨服務(wù)邊界的請求流
• 自動(dòng)發(fā)現(xiàn)服務(wù)

例如， Istio是一個(gè)開源服務(wù)網(wǎng)格層，它根據(jù)云管理員提供的預(yù)定義配置來指導(dǎo)服務(wù)之間的通信。它充當(dāng) Kubernetes 編排層的邊車，并與容器一起工作，對程序員和管理員來說是不可見的。

安全

混合云架構(gòu)的復(fù)雜性需要在不同層采用多層方法來確保端到端的安全和保護(hù)。?IBM Cloud、Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud 等 CSP 有責(zé)任根據(jù)服務(wù)水平協(xié)議 (SLA) 對外圍層的任何調(diào)用進(jìn)行身份驗(yàn)證和授權(quán)，從而在企業(yè)應(yīng)用程序周圍構(gòu)建防火墻。這包括拒絕服務(wù)保護(hù)和遵守隱私法規(guī)，如通用數(shù)據(jù)保護(hù)條例 (GDPR) 和健康保險(xiǎn)流通與責(zé)任法案 (HIPAA)。

在本地基礎(chǔ)架構(gòu)中，可以使用 API 網(wǎng)關(guān)實(shí)現(xiàn)邊界安全，API 網(wǎng)關(guān)保護(hù)所有 API 端點(diǎn)。來自駐留在數(shù)據(jù)中心之外的 Web 服務(wù)或移動(dòng)應(yīng)用程序的任何調(diào)用都必須通過 API 網(wǎng)關(guān)進(jìn)行驗(yàn)證和路由。

云計(jì)算環(huán)境包含一個(gè)額外的安全層，其形式是在服務(wù)網(wǎng)格和編排平臺公開的 API 中定義的控制策略。這些策略確保只有安全調(diào)用才能轉(zhuǎn)發(fā)到 Kubernetes 節(jié)點(diǎn)，然后再轉(zhuǎn)發(fā)到微服務(wù)。

此外，微分段的概念——將環(huán)境劃分為不同的邏輯安全段以定義每個(gè)服務(wù)和工作負(fù)載的訪問控制策略——可用于在環(huán)境中運(yùn)行的服務(wù)之間構(gòu)建和劃分安全級別。最后，加密策略作為額外的數(shù)據(jù)保護(hù)層。

網(wǎng)絡(luò)連接

在單個(gè)云區(qū)域中，可用性區(qū)域具有連接網(wǎng)絡(luò)中所有節(jié)點(diǎn)的專用光纖網(wǎng)絡(luò)，允許企業(yè)創(chuàng)建帶寬不受限制且網(wǎng)絡(luò)延遲低的高可用性架構(gòu)。然而，跨區(qū)域和多個(gè)云提供商的通信是通過公共互聯(lián)網(wǎng)路由的，并且以更高的延遲和潛在的故障為代價(jià)。

在混合云架構(gòu)中，底層提供者之間存在三種數(shù)據(jù)交換模式：

• 互聯(lián)網(wǎng)上的公共 IP 地址（由于共享帶寬導(dǎo)致高延遲）
• VPN 等托管服務(wù)（更可預(yù)測的延遲和更高的安全性）
• 通過公共存在點(diǎn) (POP) 的專用互連（CSP 提供的昂貴選項(xiàng)，但延遲最小，安全性最高）

由于這些選項(xiàng)在傳輸速度、延遲、可靠性、SLA、復(fù)雜性和定價(jià)方面有所不同，因此在設(shè)計(jì)網(wǎng)絡(luò)連接層之前權(quán)衡限制和收益非常重要。

開發(fā)平臺對開源的偏見

混合云意味著能夠?qū)⒐ぷ髫?fù)載從一個(gè)環(huán)境轉(zhuǎn)移到另一個(gè)環(huán)境，并擁有在任何云上運(yùn)行的應(yīng)用程序開發(fā)平臺。真正的云原生，不應(yīng)該緊緊依賴任何特定的技術(shù)、平臺甚至CSP，企業(yè)應(yīng)該對市場變化保持敏捷。

開源架構(gòu)支持這種統(tǒng)一的開發(fā)方法，開發(fā)人員可以管理其底層基礎(chǔ)架構(gòu)，而不管用于其實(shí)現(xiàn)的技術(shù)如何。開源不再處于邊緣地位，不再有使用它來獲得成本效益的利基、排他性受眾；由于其豐富的功能、質(zhì)量和基于社區(qū)的開發(fā)，它現(xiàn)在已成為主流并占據(jù)了中心位置。

正如Red Hat Report on The State of Enterprise Open Source所報(bào)告的那樣，即使在安全性等敏感領(lǐng)域，開源軟件現(xiàn)在也被視為一個(gè)不錯(cuò)的選擇。安全性、質(zhì)量和對云原生架構(gòu)的支持是企業(yè)對開源表現(xiàn)出有意識的偏見的主要原因。