一文弄清混合云架構模式

當我們在說云架構的時候，通常指的并不是云平臺的自身架構，而是基于云平臺的軟件系統基礎架構。云平臺的自身架構滿足了很多通用層面的需求，例如對象存儲，彈性主機，虛擬網絡等等，只有云服務廠商的工程師才會涉及。對于一般企業中的工程師而言， 鑒于云服務的各種優勢，基于云平臺構建軟件系統才是工作的內容之一，尤其是面向混合云的基礎架構才是云架構的關鍵要素。

無論是公有云和私有云的融合，還是多個公有云的混合環境，其基礎架構模式分為兩種：分布式部署模式和冗余部署模式。在決定合適的架構時需要考慮的5個相關方面: 變更的敏捷性、規模的伸縮性、網絡拓撲選擇、安全性和可靠性。

(資料圖片)

分布式部署模式

當我們需要利用云服務的某些特性、屬性或功能時，這些模式最為有用。

敏捷性	伸縮性	網絡拓撲	安全性	可靠性
分層混合模式	前端受益于CI/CD的流水線	前端受益于彈性縮放	由網關控制的Mesh	VPN隧道	后端或許成為瓶頸
分區多云模式	CI/CD完全融合，并保證標準化	能夠按需縮放	由網關控制的Mesh	VPN隧道	需要額外保證通信的可靠性
云分析模式	采用一致性過程	能夠按需縮放	根據數據的收發/切換來變更拓撲，并采用API網關進行控制	TLS	訂閱/發布機制實現可靠性集成
邊云混合模式	確保邊和云之間的標準化	邊緣計算之外的按需縮放	雙向網關控制	VPN隧道和TLS	跨邊界的可靠性驗證

分層混合模式

經典的分層通常由前端和后端應用程序組成。前端處理終端用戶/客戶，消費者或他們的組合。一般地，前端是無狀態的，在這種情況下，性能和靈活性對于處理不可預測的工作負載是非常重要的。另外，通常還要處理大量的變化，因此可以從敏捷思維中受益。后端根據監管要求安全地存儲數據，并且應該不那么頻繁地進行更改。

這種架構模式的思想是遷移每個應用程序，首先選擇一個不太復雜的應用程序，然后逐個進行。一般地，有6種云遷移策略，通常稱為“6R”：主機更新、平臺更新、重新購買、重構、保留、停服。因此，需要針對每種情況做出架構決策。遷移之后，它們通過 API 網關訪問后端，這個網關集中關注交叉問題，如安全性、速率限制、 API 策略等。

如果正處于遷移過程的中期，而公司不能承諾同時完成所有工作時，這是一個很好的模式，除非情況很簡單，否則總是如此。

分區多云模式

如果關注可移植性，那么這種模式提供了將工作負載從一個云平臺轉移到另一個云平臺的能力。該模式的優勢是鎖定風險并進行緩解，能夠從每個供應商挑選最佳功能并完成監管。

實現跨多個云環境的工作負載可移植性和一致性的工具增加了開發、測試和運維的工作?？梢浦残孕允怯写鷥r的，為了使可移植性最大化，一般會考慮容器和K8S。

云分析模式

一般地，企業架構通常由事務系統和分析系統組成。事務系統用于執行每天的財務、銷售、庫存、定價等操作，而分析系統通常由于變化的性質和速度不同而與其他系統解耦。

此模式的核心思想是在云中擁有分析工作負載，并在需要時反饋數據。云存儲可以使用數據湖來實現，并通過BOS引入流量。

邊云混合模式

有些時候，我們的業務不可能能100% 的依賴于連接，比如車輛間的連接性，工廠的可用性服務水平超過了現場鏈接的能力，商店需要處理關鍵事務并且鏈路的宕機是不可能的。

面對這些挑戰，邊云混合模式通過在網絡邊緣運行時間敏感和關鍵業務的本地工作負載，同時使用云處理所有其他類型的工作負載。在邊云混合模式的設置中，互聯網連接是一個非關鍵組件，只用于管理的目的和同步或上傳數據，通常是異步的，但不涉及時間敏感或關鍵業務的事務。

另外，CI/CD的實踐在邊緣環境和云之間保持一致也是明智的選擇。

冗余部署模式

當需要為整個架構增加容量或彈性時，這些模式非常有用。

敏捷性	伸縮性	網絡拓撲	安全性	可靠性
混合環境模式	保證公私有云間的處理流程相同	按需創建/刪除環境	鏡像拓撲	公私有云間沒有通信	生產環境在私有云中
業務持續性模式	面對故障，CI/CD仍然有效	按需創建/銷毀災備環境	數據備份的切換以及鏡像拓撲	VPN隧道和TLS	最小化在不同環境中運行的系統之間的依賴性
面向業務爆發的混合云模式	保證公私有云間的處理流程相同	按需縮放	網格化	VPN隧道和TLS	跨邊界的可靠性驗證

混合環境模式

在這種模式中，公共云環境用于開發、測試和 UAT，然后生產環境使用私有云。使用這種架構的原因一般包括：監管限制、第三方許可證的使用，而這些許可證阻止了云中的生產工作負載。如果想要首先替換較低的環境，或者在需要時輕松地創建和關閉環境，那么這種模式可以很好地工作。

所有環境在功能上都是等價的，即架構、 API 以及操作系統和庫的版本都是等價的，并且系統在不同環境中的行為是相同的。但是，性能測試需要在本地實現。

業務連續性混合模式

在這種模式下，災備環境在云中實現，提供了能夠為創建災難恢復環境并將其關閉的成本效益。另外，在觸發災備的情況下，使用IaaS可以更快地創建災備環境，從而減少實際的恢復時間。

另一種替代方法是將生產環境放在一個程序中，然后故障轉移到另一個程序中，但是，這種方法不太常見，因為通?？梢栽谝粋€程序中實現可用性需求。

面向業務爆發的混合云模式

如果應用程序的工作負載突然增加，不可預測，并且不希望在大部分時間里為某些密集的工作負載期間提供過多的服務，這種模式可能是一種選擇，對于可以向上和向下擴展的前端無狀態應用特別適合。

面向業務爆發的混合云模式使用一個私有計算環境進行基線負載，并在需要額外容量時暫時爆發到云中。這種模式保留了基礎的內部投資，而且不需要維持全年的額外容量。

一句話小結

這些混合云架構模式的決策是復雜的，通常會涉及到幾個不同情況的關注程度，每種情況都需要全面的權衡分析，甚至可以使用多種模式來實現企業的解決方案。

那么——

如何進行混合云的架構決策？

如何保持架構的可持續性呢？

《持續架構實踐》一書或許可以提供一些真正的幫助。

【關聯閱讀】

軟件架構的10個質量屬性

端邊云協同：從云到邊緣

淺析面向云架構的SLA

面向數據架構的云演變

IoT云服務連接性的方式

在傳感器與云之間

10行Python代碼的詞云

理解一下混合云

架構軟件工程的未來（精要版）

軟件架構的10個常見模式

回顧Bob大叔的簡潔架構

解讀六邊形架構

老曹眼中的面向數據架構

從應用架構看大數據

架構大數據應用

關鍵詞： 工作負載 混合模式 可移植性