混合云架構(gòu)將跨地理分布的公共云、私有云和本地基礎設施的多個環(huán)境匯集在一起??，作為一個單一的托管 IT 基礎設施。在基本層面上，這可能只是一家企業(yè)在其本地數(shù)據(jù)中心托管遺留應用程序——在公共云服務上調(diào)用一些API 。然而，這種初步實施并不是混合云基礎架構(gòu)的最佳旗艦用例。
最大潛力的混合云包括利用云實現(xiàn)基礎設施即服務 (IaaS)、平臺即服務 (PaaS) 和軟件即服務 (SaaS) 功能，能夠托管在本地、私有云和公共云以及邊緣環(huán)境的組合上運行應用程序，并具有無鎖定多云方法的靈活性。了解設計模式和要考慮的關鍵因素有助于提煉設計此類混合云架構(gòu)所涉及的復雜性。
最近，混合云方法通常涉及將一些服務從本地基礎設施遷移到公共或私有云，并且這些服務相互通信。即使構(gòu)建了一個新的應用程序以托管在公共云上，它也會遵循傳統(tǒng)的面向服務的架構(gòu) (SOA)。
但是，今天，基于微服務的架構(gòu)是混合云模型的核心。微服務是一種將應用程序分解為更小的組件或服務以便于部署的方法。這些微服務與 SOA 中的服務不同，因為它們有自己的技術(shù)堆棧并部署在容器中，容器是包含微服務及其依賴庫的輕量級可執(zhí)行文件。
容器是輕量級的，因為它們共享機器的操作系統(tǒng) (OS) 內(nèi)核，這意味著每個容器只包含微服務及其依賴項。任何操作系統(tǒng)依賴項都從容器所在的硬件共享。這種虛擬化允許微服務在任何本地或云環(huán)境中獨立部署。而自給自足性使得微服務與 SOA 有很大不同，更適合云部署，其中對彈性和靈活性的需求以優(yōu)化云資源是至關重要的。
容器化作為在任何環(huán)境中隔離進程的打包模型并不是一個新概念，但2013 年作為容器引擎出現(xiàn)的Docker創(chuàng)建了一個通用的打包結(jié)構(gòu)。此外，像Kubernetes這樣的容器編排平臺可以跨混合云環(huán)境自動部署 Docker 或任何其他符合開放容器倡議 (OCI) 標準的容器。
容器化的出現(xiàn)有助于真正利用混合云的優(yōu)勢，重點轉(zhuǎn)移到工作負載的輕松移植和服務在您選擇的云環(huán)境上的自動部署。幾年前，關于混合云架構(gòu)的討論中的關鍵問題集中在每個工作負載應該在哪個云或本地環(huán)境中運行，以及如何讓這些不同的環(huán)境相互通信。從本質(zhì)上講，托管位置和物理連接仍然是主要考慮因素。
例如，處理敏感數(shù)據(jù)的應用程序?qū)⑼泄茉谒接性粕稀；蛘撸y以實現(xiàn)現(xiàn)代化的遺留應用程序?qū)⒗^續(xù)存在于本地。同時，組織會將需要可擴展性的應用程序提升并轉(zhuǎn)移到公共云環(huán)境。然后，他們將建立虛擬專用網(wǎng)絡 (VPN) 隧道或消息流等通道，以促進環(huán)境之間的通信。
這些仍然是需要考慮的重要因素，但是對于容器化范例，重點已經(jīng)從物理位置和連接性轉(zhuǎn)移到將工作負載從一個環(huán)境無縫移動到另一個環(huán)境的靈活性。因此，無論是在私有云還是公共云中托管應用程序都不一定是一個嚴格的決定。如果該策略不起作用，則可以輕松地跨環(huán)境移動打包為容器的工作負載、擴大和縮小規(guī)模，甚至在不同環(huán)境中運行相同服務的實例。所有這一切促成了現(xiàn)代、高度可用且靈活的架構(gòu)，該架構(gòu)可提供高性能、資源效率和成本節(jié)約。
混合云架構(gòu)的設計和實施需要考慮很多因素，包括企業(yè)的業(yè)務目標、當前的技術(shù)格局、數(shù)字化轉(zhuǎn)型目標和安全考慮。由于這種具有多個混合云解決方案的架構(gòu)可能會很快變得復雜，因此利用 ops 工具進行集中、無縫和可擴展的云管理非常重要。以下是創(chuàng)建混合云戰(zhàn)略時需要考慮的一些因素。
對于大多數(shù)組織而言，混合云計算的想法始于現(xiàn)代化或?qū)⑵鋺贸绦驈谋镜剡w移到云端，有幾種方法可以執(zhí)行此操作：
企業(yè)運營團隊通過統(tǒng)一的控制平面管理他們的云環(huán)境，該控制平面提供跨環(huán)境的內(nèi)聚和一致的云運營體驗。它支持核心集群管理功能，如工作負載調(diào)度和編排、持續(xù)集成和部署 (CI/CD) 管道、日志記錄、遙測和聯(lián)合安全。目標是從應用程序團隊中抽象出各個云服務提供商 (CSP) 和運行時的底層復雜性，并為運營團隊提供一個通用接口來管理企業(yè)中的工作負載。
以下是統(tǒng)一控制平面的一些優(yōu)勢：
集中式API 網(wǎng)關和服務網(wǎng)格等架構(gòu)模式支持對路由、服務到服務通信、安全性、速率限制和可觀察性等云功能進行透明管理。
API網(wǎng)關 作為跨地域的統(tǒng)一前門，負責處理“南北”流量功能，包括：
另一方面，服務網(wǎng)格處理服務依賴項之間的“東西向”流量：
例如， Istio是一個開源服務網(wǎng)格層，它根據(jù)云管理員提供的預定義配置來指導服務之間的通信。它充當 Kubernetes 編排層的邊車，并與容器一起工作，對程序員和管理員來說是不可見的。
混合云架構(gòu)的復雜性需要在不同層采用多層方法來確保端到端的安全和保護。 IBM Cloud、Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud 等 CSP 有責任根據(jù)服務水平協(xié)議 (SLA) 對外圍層的任何調(diào)用進行身份驗證和授權(quán)，從而在企業(yè)應用程序周圍構(gòu)建防火墻。這包括拒絕服務保護和遵守隱私法規(guī)，如通用數(shù)據(jù)保護條例 (GDPR) 和健康保險流通與責任法案 (HIPAA)。
在本地基礎架構(gòu)中，可以使用 API 網(wǎng)關實現(xiàn)邊界安全，API 網(wǎng)關保護所有 API 端點。來自駐留在數(shù)據(jù)中心之外的 Web 服務或移動應用程序的任何調(diào)用都必須通過 API 網(wǎng)關進行驗證和路由。
云計算環(huán)境包含一個額外的安全層，其形式是在服務網(wǎng)格和編排平臺公開的 API 中定義的控制策略。這些策略確保只有安全調(diào)用才能轉(zhuǎn)發(fā)到 Kubernetes 節(jié)點，然后再轉(zhuǎn)發(fā)到微服務。
此外，微分段的概念——將環(huán)境劃分為不同的邏輯安全段以定義每個服務和工作負載的訪問控制策略——可用于在環(huán)境中運行的服務之間構(gòu)建和劃分安全級別。最后，加密策略作為額外的數(shù)據(jù)保護層。
在單個云區(qū)域中，可用性區(qū)域具有連接網(wǎng)絡中所有節(jié)點的專用光纖網(wǎng)絡，允許企業(yè)創(chuàng)建帶寬不受限制且網(wǎng)絡延遲低的高可用性架構(gòu)。然而，跨區(qū)域和多個云提供商的通信是通過公共互聯(lián)網(wǎng)路由的，并且以更高的延遲和潛在的故障為代價。
在混合云架構(gòu)中，底層提供者之間存在三種數(shù)據(jù)交換模式：
由于這些選項在傳輸速度、延遲、可靠性、SLA、復雜性和定價方面有所不同，因此在設計網(wǎng)絡連接層之前權(quán)衡限制和收益非常重要。
混合云意味著能夠?qū)⒐ぷ髫撦d從一個環(huán)境轉(zhuǎn)移到另一個環(huán)境，并擁有在任何云上運行的應用程序開發(fā)平臺。真正的云原生，不應該緊緊依賴任何特定的技術(shù)、平臺甚至CSP，企業(yè)應該對市場變化保持敏捷。
開源架構(gòu)支持這種統(tǒng)一的開發(fā)方法，開發(fā)人員可以管理其底層基礎架構(gòu)，而不管用于其實現(xiàn)的技術(shù)如何。開源不再處于邊緣地位，不再有使用它來獲得成本效益的利基、排他性受眾；由于其豐富的功能、質(zhì)量和基于社區(qū)的開發(fā)，它現(xiàn)在已成為主流并占據(jù)了中心位置。
正如Red Hat Report on The State of Enterprise Open Source所報告的那樣，即使在安全性等敏感領域，開源軟件現(xiàn)在也被視為一個不錯的選擇。安全性、質(zhì)量和對云原生架構(gòu)的支持是企業(yè)對開源表現(xiàn)出有意識的偏見的主要原因。
網(wǎng)站資訊
解決方案
服務支持
