集成是幾乎所有的現(xiàn)代應(yīng)用開發(fā)計(jì)劃的必需元素。多年以來，SOA以及前端Web開發(fā)的經(jīng)驗(yàn)已經(jīng)就集成教育了策劃者和架構(gòu)師。早期的虛擬化經(jīng)驗(yàn)更多的擴(kuò)展了這一點(diǎn)，但是云打破了很多現(xiàn)代集成實(shí)踐，因此策劃者和架構(gòu)師需要通過詢問為何云是不同的來開始其云集成項(xiàng)目。隨后，他們需要在心里評估云集成計(jì)劃。對于大多數(shù)而言，關(guān)鍵的一點(diǎn)在于如何在云部署環(huán)境中調(diào)節(jié)應(yīng)用集成工具。

在早期的應(yīng)用中，開發(fā)者要么編寫整體的應(yīng)用，要么在一個(gè)通用的裝載映像中緊密耦合獨(dú)立的組件。大量的應(yīng)用仍舊以這種方式編寫，但是SOA和敏捷開發(fā)已經(jīng)開始鼓勵架構(gòu)師構(gòu)建獨(dú)立的功能組件，可以利用這些組件來組件應(yīng)用。隨著業(yè)務(wù)應(yīng)用同業(yè)務(wù)流程以及其它流程越來越多地集成，他們需要更為松散的耦合組件，簡單地消除單一的巨大裝載映像。

基于目錄的集成組件已經(jīng)成為一種規(guī)則。通過基于目錄的集成，一個(gè)組件注冊庫本身在某個(gè)地方，而且通過這個(gè)注冊可以分配并且發(fā)送工作。目錄可以相當(dāng)簡單，比如DNS,或者是一個(gè)基于功能瀏覽的注冊庫，理論上SOA UDDI就是。不過在所有情況下，這個(gè)目錄都被期望在首次使用時(shí)創(chuàng)建一個(gè)加載組件或者觸發(fā)器組件加載的鏈接。

云計(jì)算從兩方面對這些造成了挑戰(zhàn)。首先云假定了一種高水平的動態(tài)資源分配。組件可以放到云中的任何地方，而且如何接觸到這個(gè)組件的問題邊界很少，同時(shí)過去你可以假設(shè)所有的一切都至少在一個(gè)固定的數(shù)據(jù)中心中存放。第二，云的原則目標(biāo)之一就是通過組件實(shí)例的可擴(kuò)展管理靈活性和性能。這也意味著，很多組件必須實(shí)時(shí)共享工作或者故障恢復(fù)。通常創(chuàng)建集成到組件的鏈接的過程并不是瞬時(shí)的，而且在延遲階段，事務(wù)處理可能受到牽連。

滿足這些挑戰(zhàn)的關(guān)鍵是評估云計(jì)算，識別集成痛點(diǎn)所在。首先，要關(guān)注任何地方的組件可以在加載或者故障恢復(fù)情況下云資源化。此外，要關(guān)注云組件被云提供商重新分配以響應(yīng)問題的情況。任何這樣的場景都需要一些同其他組件和工作流的特殊集成處理。

云用戶表示更加偏愛基于DNS的負(fù)載均衡，將其作為工作到云的組件的一種方式，可以實(shí)現(xiàn)故障恢復(fù)或者水平擴(kuò)展。在可擴(kuò)咱的情況下，基于DNS的負(fù)載均衡允許同當(dāng)下的組件連接工作，同時(shí)增加一個(gè)新的，因此QoE伴隨的唯一風(fēng)險(xiǎn)就是組件失敗，這也是大部分公司要接受的。如果任何的宕機(jī)時(shí)間都無法忍受，那么至少通過任何點(diǎn)的兩個(gè)可用組件副本和通過DNS集成來解決。

基于DNS的負(fù)載均衡的問題在于并不支持組件瀏覽（沒有WSDL）而且可能導(dǎo)致工作流到組件的狀態(tài)問題。如果出于這兩個(gè)原因沒有可能使用基于DNS的負(fù)載均衡，下一個(gè)最佳的戰(zhàn)略就是依賴于UDDI和WSDL或者BPEL來在組件之間進(jìn)行選擇。如果管理組件鏈接的應(yīng)用控制流程無法為云端轉(zhuǎn)移組件負(fù)責(zé)，就會出現(xiàn)潛在的問題。如果轉(zhuǎn)一個(gè)組件改變了地址，組件就會處于未鏈接狀態(tài)。亞馬遜的解決方案是彈性IP地址，讓靜態(tài)URL引用動態(tài)組件。這種地址轉(zhuǎn)換的方法也可以用在私有云中。

亞馬遜彈性IP地址模型展示了云集成的一個(gè)基本事實(shí)。有兩種形式的“組件移動性”:一是必須識別出獨(dú)立的組件作為分立的元素可以鏈接到工作流中，另一個(gè)是識別出通過云流程創(chuàng)建的繼承組件副本，而非通過應(yīng)用流程儲藏間。如果你接受URL是邏輯組件移動和物理組件位置之間的邊界的原則的話，用標(biāo)準(zhǔn)化集成工具（包括DevOps或者CAMP）調(diào)節(jié)這種組合更容易。

集成工具應(yīng)該用于將組件帶到一起，因?yàn)楣ぷ髁鞅仨氈苯油鋯为?dú)接觸。這個(gè)工具的目標(biāo)就是直接同URL工作，并期望這個(gè)URL隨后可以通過獨(dú)立的后端集成流程匹配資源。

以地址組件改變時(shí)通過資源管理器調(diào)用工具為條件，在一個(gè)集成工具中通過URL管理地址表達(dá)是可行的。關(guān)鍵問題在于不是管理這種改變，而是管理處理中的事物改變產(chǎn)生的影響。允許任何靜態(tài)的流來改變基礎(chǔ)中流是非常危險(xiǎn)的。會導(dǎo)致所謂的“結(jié)束時(shí)期”.因此在改變URL的目標(biāo)地址之前，這對于靜態(tài)工作流來報(bào)告處理中的事物的失敗可能是最佳的方式。

安全和法規(guī)遵從是任何集成列表上最后的元素。工作流可能呈現(xiàn)為相對有狀態(tài)的、末端安全和法規(guī)遵從問題，但是就算組件鏈接可以導(dǎo)致問題，應(yīng)用安全審計(jì)可能會發(fā)現(xiàn)。組件彈性帶來了多種機(jī)遇，引出了非真正的組件版本。最終，云端需要更多的集成工作來確保工作流通過彈性資源使用來維持，你需要更多的內(nèi)容來檢查你的組件正常處理，保證你將唯一合適且真實(shí)的元素帶入到你的工作流中。