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

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

　　選擇一款混合云模型

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

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

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

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

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

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

　　考慮工作流

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

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

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

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

　　在后一種情況下，緩存DBMS將會被存儲在該模型中，從而日后具有可用性。在前一種情況下，可以一直采用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í)例就會變得非常容易�；�于DNS的負(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)或者具體化后的組件存儲在不同的組件模型中，那么該組件也許就不會具備訪問數(shù)據(jù)模型的權(quán)限。

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