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