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

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

分布式部署模式

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

分層混合模式

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

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

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

分區多云模式

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

實現跨多個云環境的工作負載可移植性和一致性的工具增加了開發、測試和運維的工作。可移植性性是有代價的，為了使可移植性最大化，一般會考慮容器和K8S。

云分析模式

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

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

邊云混合模式

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

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

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

冗余部署模式

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

混合環境模式

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

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

業務連續性混合模式

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

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

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

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

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

一句話小結

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

那么——

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

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