當(dāng)我們?cè)谡f(shuō)云架構(gòu)的時(shí)候，通常指的并不是云平臺(tái)的自身架構(gòu)，而是基于云平臺(tái)的軟件系統(tǒng)基礎(chǔ)架構(gòu)。云平臺(tái)的自身架構(gòu)滿足了很多通用層面的需求，例如對(duì)象存儲(chǔ)，彈性主機(jī)，虛擬網(wǎng)絡(luò)等等，只有云服務(wù)廠商的工程師才會(huì)涉及。對(duì)于一般企業(yè)中的工程師而言， 鑒于云服務(wù)的各種優(yōu)勢(shì)，基于云平臺(tái)構(gòu)建軟件系統(tǒng)才是工作的內(nèi)容之一，尤其是面向混合云的基礎(chǔ)架構(gòu)才是云架構(gòu)的關(guān)鍵要素。

無(wú)論是公有云和私有云的融合，還是多個(gè)公有云的混合環(huán)境，其基礎(chǔ)架構(gòu)模式分為兩種：分布式部署模式和冗余部署模式。在決定合適的架構(gòu)時(shí)需要考慮的5個(gè)相關(guān)方面: 變更的敏捷性、規(guī)模的伸縮性、網(wǎng)絡(luò)拓?fù)溥x擇、安全性和可靠性。

分布式部署模式

當(dāng)我們需要利用云服務(wù)的某些特性、屬性或功能時(shí)，這些模式最為有用。

分層混合模式

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

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

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

分區(qū)多云模式

如果關(guān)注可移植性，那么這種模式提供了將工作負(fù)載從一個(gè)云平臺(tái)轉(zhuǎn)移到另一個(gè)云平臺(tái)的能力。該模式的優(yōu)勢(shì)是鎖定風(fēng)險(xiǎn)并進(jìn)行緩解，能夠從每個(gè)供應(yīng)商挑選最佳功能并完成監(jiān)管。

實(shí)現(xiàn)跨多個(gè)云環(huán)境的工作負(fù)載可移植性和一致性的工具增加了開發(fā)、測(cè)試和運(yùn)維的工作?？梢浦残孕允怯写鷥r(jià)的，為了使可移植性最大化，一般會(huì)考慮容器和K8S。

云分析模式

一般地，企業(yè)架構(gòu)通常由事務(wù)系統(tǒng)和分析系統(tǒng)組成。事務(wù)系統(tǒng)用于執(zhí)行每天的財(cái)務(wù)、銷售、庫(kù)存、定價(jià)等操作，而分析系統(tǒng)通常由于變化的性質(zhì)和速度不同而與其他系統(tǒng)解耦。

此模式的核心思想是在云中擁有分析工作負(fù)載，并在需要時(shí)反饋數(shù)據(jù)。云存儲(chǔ)可以使用數(shù)據(jù)湖來(lái)實(shí)現(xiàn)，并通過(guò)BOS引入流量。

邊云混合模式

有些時(shí)候，我們的業(yè)務(wù)不可能能100% 的依賴于連接，比如車輛間的連接性，工廠的可用性服務(wù)水平超過(guò)了現(xiàn)場(chǎng)鏈接的能力，商店需要處理關(guān)鍵事務(wù)并且鏈路的宕機(jī)是不可能的。

面對(duì)這些挑戰(zhàn)，邊云混合模式通過(guò)在網(wǎng)絡(luò)邊緣運(yùn)行時(shí)間敏感和關(guān)鍵業(yè)務(wù)的本地工作負(fù)載，同時(shí)使用云處理所有其他類型的工作負(fù)載。在邊云混合模式的設(shè)置中，互聯(lián)網(wǎng)連接是一個(gè)非關(guān)鍵組件，只用于管理的目的和同步或上傳數(shù)據(jù)，通常是異步的，但不涉及時(shí)間敏感或關(guān)鍵業(yè)務(wù)的事務(wù)。

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

冗余部署模式

當(dāng)需要為整個(gè)架構(gòu)增加容量或彈性時(shí)，這些模式非常有用。

混合環(huán)境模式

在這種模式中，公共云環(huán)境用于開發(fā)、測(cè)試和 UAT，然后生產(chǎn)環(huán)境使用私有云。使用這種架構(gòu)的原因一般包括：監(jiān)管限制、第三方許可證的使用，而這些許可證阻止了云中的生產(chǎn)工作負(fù)載。如果想要首先替換較低的環(huán)境，或者在需要時(shí)輕松地創(chuàng)建和關(guān)閉環(huán)境，那么這種模式可以很好地工作。

所有環(huán)境在功能上都是等價(jià)的，即架構(gòu)、 API 以及操作系統(tǒng)和庫(kù)的版本都是等價(jià)的，并且系統(tǒng)在不同環(huán)境中的行為是相同的。但是，性能測(cè)試需要在本地實(shí)現(xiàn)。

業(yè)務(wù)連續(xù)性混合模式

在這種模式下，災(zāi)備環(huán)境在云中實(shí)現(xiàn)，提供了能夠?yàn)閯?chuàng)建災(zāi)難恢復(fù)環(huán)境并將其關(guān)閉的成本效益。另外，在觸發(fā)災(zāi)備的情況下，使用IaaS可以更快地創(chuàng)建災(zāi)備環(huán)境，從而減少實(shí)際的恢復(fù)時(shí)間。

另一種替代方法是將生產(chǎn)環(huán)境放在一個(gè)程序中，然后故障轉(zhuǎn)移到另一個(gè)程序中，但是，這種方法不太常見，因?yàn)橥ǔ？梢栽谝粋€(gè)程序中實(shí)現(xiàn)可用性需求。

面向業(yè)務(wù)爆發(fā)的混合云模式

如果應(yīng)用程序的工作負(fù)載突然增加，不可預(yù)測(cè)，并且不希望在大部分時(shí)間里為某些密集的工作負(fù)載期間提供過(guò)多的服務(wù)，這種模式可能是一種選擇，對(duì)于可以向上和向下擴(kuò)展的前端無(wú)狀態(tài)應(yīng)用特別適合。

面向業(yè)務(wù)爆發(fā)的混合云模式使用一個(gè)私有計(jì)算環(huán)境進(jìn)行基線負(fù)載，并在需要額外容量時(shí)暫時(shí)爆發(fā)到云中。這種模式保留了基礎(chǔ)的內(nèi)部投資，而且不需要維持全年的額外容量。

一句話小結(jié)

這些混合云架構(gòu)模式的決策是復(fù)雜的，通常會(huì)涉及到幾個(gè)不同情況的關(guān)注程度，每種情況都需要全面的權(quán)衡分析，甚至可以使用多種模式來(lái)實(shí)現(xiàn)企業(yè)的解決方案。

那么——

如何進(jìn)行混合云的架構(gòu)決策？

如何保持架構(gòu)的可持續(xù)性呢？