隨著云計算的深入應(yīng)用，對于軟件架構(gòu)師而言，需要具備獨具特色的API設(shè)計思想，因為這會對混合云部署的效率和抉擇產(chǎn)生重要的影響。
大多數(shù)企業(yè)和軟件架構(gòu)師都意識到，不是所有應(yīng)用程序都可以移動到公共云中，因此，混合云設(shè)計就顯得至關(guān)重要。許多人都不太了解API設(shè)計對公共云部署選擇和效率會帶來如此重要的影響。API設(shè)計過程中，通過設(shè)定參數(shù)以及管理狀態(tài)和工作量而解決組件模型和工作流的最優(yōu)化問題。為了建立效果較佳的API，我們選定了一種混合模型來實現(xiàn)最初的目標和記錄應(yīng)用程序工作流量，同時，API設(shè)計也可以有助于狀態(tài)管理和負載平衡。
選擇一款混合云模型
當每一個人都在使用混合云的時候，那么就有多種混合模型可供選擇，當然，任何一款A(yù)PI都有它的特殊問題。多數(shù)計劃實施混合云的企業(yè)都已經(jīng)采用了Web前端混合模型，并將用戶訪問應(yīng)用程序的部分轉(zhuǎn)移到了公共云中，但是，其中轉(zhuǎn)移數(shù)據(jù)需要經(jīng)過數(shù)據(jù)中心的處理。
排名第二受追捧的模型就是云簇模型，在高負荷或者傳輸失敗的時候，補充數(shù)據(jù)中心資源就會希望獲得公共云資源。第三大混合模型是卸載分析模型，在云應(yīng)用被用于分析包括大數(shù)據(jù)在內(nèi)的歷史數(shù)據(jù)時，該模型得以應(yīng)用。
我們需要知道的是，哪些模型需要受到支持，一家公司如何排列這些模型的優(yōu)先順序。我們需要記住設(shè)為目標的混合模型，最好從最重要的一個開始，因此，需要設(shè)置整體API策略。
重新回顧API設(shè)計決策
通常，分析混合API選擇的第一步是評估應(yīng)用程序的工作流量。避免陷入現(xiàn)有組件模型中；API設(shè)計應(yīng)當總是以業(yè)務(wù)流程流作為開始環(huán)節(jié)，最好是從企業(yè)架構(gòu)模型中選取流程。要做到這一點，我們需要在每一個業(yè)務(wù)流程之間都添加一種數(shù)據(jù)庫訪問流。這種結(jié)合會讓你決定在混合模型互動活動中信息的流動方向。
從已有的經(jīng)驗來看，當一組獨立組件負責訪問數(shù)據(jù)庫信息時，或者至少是集中而不是分散在整個工作流中的組件負責數(shù)據(jù)庫訪問時，云應(yīng)用就會成為最有效的工具。當組件轉(zhuǎn)移動中時需要跨越混合云模型的數(shù)據(jù)庫訪問邊界，那么著將會有時間的限制，但是，這種情況下有時會出現(xiàn)性能問題。通過數(shù)據(jù)庫集中訪問設(shè)置，會形成一種總結(jié)應(yīng)用程序數(shù)據(jù)庫需求的虛擬記錄。
考慮工作流
架構(gòu)師在尋找支持Web前端模型的工具時就應(yīng)該構(gòu)建一種在云中可以支持用戶交互活動以及GUI 的應(yīng)用程序。Web前端可以通過數(shù)據(jù)接觸到應(yīng)用程序匝道組件，隨后建立數(shù)據(jù)庫內(nèi)容。多數(shù)訪問核心任務(wù)數(shù)據(jù)庫的應(yīng)用程序都會運行這種內(nèi)部組件。
在混合分析模型中也可以采用同樣的方法。在大多數(shù)情況下，應(yīng)用程序云部分將會接收和驗證查詢內(nèi)容，然后，將其分派到應(yīng)用程序匝道中，在這里可以訪問到真實的數(shù)據(jù)庫。如果，在云或者一些查詢中，可能托管抽象的或者概述性的數(shù)據(jù)庫時，那么云DBMS與核心DBMS之間獨立的查詢語句將會由分析應(yīng)用程序的云部分完成。
在多種決策中進行抉擇
這些持續(xù)支持云全部內(nèi)容和匝道組件的API需將全面的用戶需求信息發(fā)到匝道組件中，并反饋需求結(jié)果，這樣API可以得到較佳的RESTful。一旦匝道組件達到閥值時，我們將會采取兩種策略——通過交易數(shù)據(jù)模型保護其他組件或者選擇保存模型中的一部分。
在后一種情況下，緩存DBMS將會被存儲在該模型中，從而日后具有可用性。在前一種情況下，可以一直采用RESTful API，但是在需要支持特殊數(shù)據(jù)元素的每個組件中，最好是考慮使用SOA模型，這樣可以獲取到每個組件所需的數(shù)據(jù)文件。
混合云簇模型較為復(fù)雜，因為其假設(shè)為，組件可以進出基于當前負載和數(shù)據(jù)中心資源的云。在這一個模塊中，狀態(tài)管理十分重要，之前關(guān)于交易數(shù)據(jù)模型的探討也可以應(yīng)用到狀態(tài)管理中，同時也可以作為多組件案例中分配工作的一種方法。
大多數(shù)架構(gòu)師都認為，如果API是處于RESTful狀態(tài)，那么動態(tài)地移動或者水平伸縮組件實例就會變得非常容易。基于DNS的負載均衡同樣能夠解決數(shù)據(jù)中心與云之間的故障轉(zhuǎn)移。如果交易數(shù)據(jù)中心掌控了某一狀態(tài)，那么為了達到運行的條件，就不得不將該狀態(tài)傳遞到組件案例中。如果數(shù)據(jù)模型不是特別大，那么最好是選取整個模型而不是挑選個別參數(shù)進行檢驗。如果被移動或者具體化后的組件存儲在不同的組件模型中，那么該組件也許就不會具備訪問數(shù)據(jù)模型的權(quán)限。
D1Net評論：
總而言之，在設(shè)計混合云API時，最好要記住，應(yīng)用靈活性以及資源有效性都可能引起這一模塊的變化。也就是說，最佳的方案是具有高度靈活性的，同時，獨立的交易數(shù)據(jù)模型可能是實現(xiàn)靈活性以及降低API變化風險的最佳途徑，而且，這種變化是需要耗費昂貴的成本和大量的時間才能夠完成的。
京公網(wǎng)安備 11010502049343號