隨著云計(jì)算的深入應(yīng)用，對(duì)于軟件架構(gòu)師而言，需要具備獨(dú)具特色的API設(shè)計(jì)思想，因?yàn)檫@會(huì)對(duì)混合云部署的效率和抉擇產(chǎn)生重要的影響。

大多數(shù)企業(yè)和軟件架構(gòu)師都意識(shí)到，不是所有應(yīng)用程序都可以移動(dòng)到公共云中，因此，混合云設(shè)計(jì)就顯得至關(guān)重要。許多人都不太了解API設(shè)計(jì)對(duì)公共云部署選擇和效率會(huì)帶來(lái)如此重要的影響。API設(shè)計(jì)過(guò)程中，通過(guò)設(shè)定參數(shù)以及管理狀態(tài)和工作量而解決組件模型和工作流的最優(yōu)化問(wèn)題。為了建立效果較佳的API，我們選定了一種混合模型來(lái)實(shí)現(xiàn)最初的目標(biāo)和記錄應(yīng)用程序工作流量，同時(shí)，API設(shè)計(jì)也可以有助于狀態(tài)管理和負(fù)載平衡。

選擇一款混合云模型

當(dāng)每一個(gè)人都在使用混合云的時(shí)候，那么就有多種混合模型可供選擇，當(dāng)然，任何一款A(yù)PI都有它的特殊問(wèn)題。多數(shù)計(jì)劃實(shí)施混合云的企業(yè)都已經(jīng)采用了Web前端混合模型，并將用戶(hù)訪(fǎng)問(wèn)應(yīng)用程序的部分轉(zhuǎn)移到了公共云中，但是，其中轉(zhuǎn)移數(shù)據(jù)需要經(jīng)過(guò)數(shù)據(jù)中心的處理。

排名第二受追捧的模型就是云簇模型，在高負(fù)荷或者傳輸失敗的時(shí)候，補(bǔ)充數(shù)據(jù)中心資源就會(huì)希望獲得公共云資源。第三大混合模型是卸載分析模型，在云應(yīng)用被用于分析包括大數(shù)據(jù)在內(nèi)的歷史數(shù)據(jù)時(shí)，該模型得以應(yīng)用。

我們需要知道的是，哪些模型需要受到支持，一家公司如何排列這些模型的優(yōu)先順序。我們需要記住設(shè)為目標(biāo)的混合模型，最好從最重要的一個(gè)開(kāi)始，因此，需要設(shè)置整體API策略。

重新回顧API設(shè)計(jì)決策

通常，分析混合API選擇的第一步是評(píng)估應(yīng)用程序的工作流量。避免陷入現(xiàn)有組件模型中；API設(shè)計(jì)應(yīng)當(dāng)總是以業(yè)務(wù)流程流作為開(kāi)始環(huán)節(jié)，最好是從企業(yè)架構(gòu)模型中選取流程。要做到這一點(diǎn)，我們需要在每一個(gè)業(yè)務(wù)流程之間都添加一種數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)流。這種結(jié)合會(huì)讓你決定在混合模型互動(dòng)活動(dòng)中信息的流動(dòng)方向。

從已有的經(jīng)驗(yàn)來(lái)看，當(dāng)一組獨(dú)立組件負(fù)責(zé)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)信息時(shí)，或者至少是集中而不是分散在整個(gè)工作流中的組件負(fù)責(zé)數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)時(shí)，云應(yīng)用就會(huì)成為最有效的工具。當(dāng)組件轉(zhuǎn)移動(dòng)中時(shí)需要跨越混合云模型的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)邊界，那么著將會(huì)有時(shí)間的限制，但是，這種情況下有時(shí)會(huì)出現(xiàn)性能問(wèn)題。通過(guò)數(shù)據(jù)庫(kù)集中訪(fǎng)問(wèn)設(shè)置，會(huì)形成一種總結(jié)應(yīng)用程序數(shù)據(jù)庫(kù)需求的虛擬記錄。

考慮工作流

架構(gòu)師在尋找支持Web前端模型的工具時(shí)就應(yīng)該構(gòu)建一種在云中可以支持用戶(hù)交互活動(dòng)以及GUI 的應(yīng)用程序。Web前端可以通過(guò)數(shù)據(jù)接觸到應(yīng)用程序匝道組件，隨后建立數(shù)據(jù)庫(kù)內(nèi)容。多數(shù)訪(fǎng)問(wèn)核心任務(wù)數(shù)據(jù)庫(kù)的應(yīng)用程序都會(huì)運(yùn)行這種內(nèi)部組件。

在混合分析模型中也可以采用同樣的方法。在大多數(shù)情況下，應(yīng)用程序云部分將會(huì)接收和驗(yàn)證查詢(xún)內(nèi)容，然后，將其分派到應(yīng)用程序匝道中，在這里可以訪(fǎng)問(wèn)到真實(shí)的數(shù)據(jù)庫(kù)。如果，在云或者一些查詢(xún)中，可能托管抽象的或者概述性的數(shù)據(jù)庫(kù)時(shí)，那么云DBMS與核心DBMS之間獨(dú)立的查詢(xún)語(yǔ)句將會(huì)由分析應(yīng)用程序的云部分完成。

在多種決策中進(jìn)行抉擇

這些持續(xù)支持云全部?jī)?nèi)容和匝道組件的API需將全面的用戶(hù)需求信息發(fā)到匝道組件中，并反饋需求結(jié)果，這樣API可以得到較佳的RESTful。一旦匝道組件達(dá)到閥值時(shí)，我們將會(huì)采取兩種策略——通過(guò)交易數(shù)據(jù)模型保護(hù)其他組件或者選擇保存模型中的一部分。

在后一種情況下，緩存DBMS將會(huì)被存儲(chǔ)在該模型中，從而日后具有可用性。在前一種情況下，可以一直采用RESTful API，但是在需要支持特殊數(shù)據(jù)元素的每個(gè)組件中，最好是考慮使用SOA模型，這樣可以獲取到每個(gè)組件所需的數(shù)據(jù)文件。

混合云簇模型較為復(fù)雜，因?yàn)槠浼僭O(shè)為，組件可以進(jìn)出基于當(dāng)前負(fù)載和數(shù)據(jù)中心資源的云。在這一個(gè)模塊中，狀態(tài)管理十分重要，之前關(guān)于交易數(shù)據(jù)模型的探討也可以應(yīng)用到狀態(tài)管理中，同時(shí)也可以作為多組件案例中分配工作的一種方法。

大多數(shù)架構(gòu)師都認(rèn)為，如果API是處于RESTful狀態(tài)，那么動(dòng)態(tài)地移動(dòng)或者水平伸縮組件實(shí)例就會(huì)變得非常容易?；贒NS的負(fù)載均衡同樣能夠解決數(shù)據(jù)中心與云之間的故障轉(zhuǎn)移。如果交易數(shù)據(jù)中心掌控了某一狀態(tài)，那么為了達(dá)到運(yùn)行的條件，就不得不將該狀態(tài)傳遞到組件案例中。如果數(shù)據(jù)模型不是特別大，那么最好是選取整個(gè)模型而不是挑選個(gè)別參數(shù)進(jìn)行檢驗(yàn)。如果被移動(dòng)或者具體化后的組件存儲(chǔ)在不同的組件模型中，那么該組件也許就不會(huì)具備訪(fǎng)問(wèn)數(shù)據(jù)模型的權(quán)限。

D1Net評(píng)論：

總而言之，在設(shè)計(jì)混合云API時(shí)，最好要記住，應(yīng)用靈活性以及資源有效性都可能引起這一模塊的變化。也就是說(shuō)，最佳的方案是具有高度靈活性的，同時(shí)，獨(dú)立的交易數(shù)據(jù)模型可能是實(shí)現(xiàn)靈活性以及降低API變化風(fēng)險(xiǎn)的最佳途徑，而且，這種變化是需要耗費(fèi)昂貴的成本和大量的時(shí)間才能夠完成的。