十年前，面向服務架構突然出現在IT舞臺上，而且許多公司已經在SOA應用上進行了大量的投資。很明顯，云計算的成功取決于它能夠給現有的SOA實現增加價值的能力。調查顯示，花在基于SOA原則的應用上的企業IT美元比花在“單片”應用上的要多。不甚清楚的是SOA可能是云的理想伙伴，使之大于它的所有部分的總和。

SOA系統中的應用程序不同于基于模塊化和編排組合而成的應用;他們建立于模塊化元素，這些元素是根據用戶，甚至是個別工人的特殊的工作流需求組合而成的。這通常是通過“工作流引擎”，有時稱為消息或服務總線完成的。

SOA應用設計托管在多任務的操作系統上，而且現在的大部分服務或消息總線技術都將會支持服務集群。因此，在企業SOA數據中心中，“云計算”已經生效這是一個事實，每一個SOA系統組件都是“即服務”的元素。促使SOA應用真正與云兼容，尤其是與混合云，關系到SOA能做什么與云需要什么之間的平衡關系。

預防基于SOA云的失敗

在云中創建SOA的最大問題，是大多數公司希望在混合云應用中的動態負載均衡，尤其是對于核心的，關鍵任務的SOA應用。有兩個元素促使負載均衡工作：當需要時創建額外的組件實例，并隨著負載的改變或發生失敗，在這些組件中平衡應用流量。

如果負載均衡在數據中心的使用中已經改變，在這些改變之后它有可能創建云實例，使它們看起來像是數據中的擴展。這允許你繼續使用現有的負載均衡策略。盡管如此，如果數據中心的能力消失，那么負載均衡的改變也會消失，云中的故障轉移也會失效。如果負載均衡做為云或網絡服務實施，那么它就可以支持混合云SOA的實現——即使數據中失敗。

有時候，SOA服務總線或“工作流引擎”將會在多個主機上動態產生應用組件的額外實例，從而提升性能或對失敗做出響應。這種情況下，要與云服務供應商協商，確保服務總線接口與公有云服務兼容。如果不能把服務總線應用實例流程直接連接到云管理接口上，并啟動云組件的話，你可能不得不使用開發腳本或DevOps工具，來加速必要的公有云資源，然后讓服務總線使用他們。

當使用任何一種云服務來創建彈性擴展的私有SOA資源池時，評估供應商延遲應用的影響很重要。無論公有云資源是直接通過工作流引擎激活的，還是通過DevOps的，都有一個激活的階段，這時資源將不可用，這將會影響生產率。延遲對工作負載溢出應用的影響較小，因為你可以簡單的調整新資源要求的需求水平。然而，這種調整可能會導致加速那些因需求減少而不需要的公有云資源。準備備用的服務或有現成的服務水平協議(SLA)來減少云資源的供應時間可能是最佳解決方案。

選擇與SOA兼容的公有云廠商

根據本地用于運行您的SOA應用程序的操作系統和中間件的不同，對于公共云托管組件你可以有多種選擇。你惠普、IBM、微軟和甲骨文這樣的公司有平臺即服務(PaaS)的選擇，這與他們的服務器和中間件工具相兼容。所以如果你使用來自這些廠商的SOA軟件，那么第一件事是評估使用來自同一個公司的云服務的利益和成本。

如果那不可能或你希望探索更廣的選擇，那么基礎設備即服務(IaaS)可能會是一個不錯的方向。記住，對IaaS公共云處理你當前的SOA組件，IaaS設備像必須包括你使用的操作系統和中間件。確保你的IaaS云供應商能夠支持你的操作系統和中間件，并確保與公有云使用的兼容的許可。

大體上說，管理員需要認識到SOA和“RESTful”或“Web接口”是不同的東西。大部分的SOA應用包含編排和工作流、及在基本Web服務中缺席的安全和合規元素?，F在大多數云應用更多是基于RESTful接口，而不是SOA，因此給后者假定前者的經驗教訓是有風險的。認真探索此問題，而且在做出生產承諾之前一定要徹底試運行測試。

關于作者：

Tom Nolle是CIMI集團的總裁，CIMI是自1982年以來專門從事電信和數據通訊的戰略咨詢公司。