Abstract：
Key words :
虛擬化是這樣的一個術語，用來組件化物理資源，從而促進應用之間或用戶之間的共享，包括在云端。面向服務架構(SOA)提供了高度組件化的應用程序，這些程序的功能可以混合及匹配來適應工作人員的需求。這樣的結果是，這是應用程序式的虛擬化。隨著應用程序和資源虛擬化的同時進行，出現了一個問題是：應用程序生命周期管理 (ALM)原則怎樣通過一組合理的實踐同時擊中這兩者，并向著實現操作穩定性的目標前進?
在ALM原則中實現穩定性
SOA模型和虛擬化/云計算模型的目標都在靈活性和敏捷性上，而且兩者都打破了過去的傳統的單片應用程序和服務器結構。但是沒有應用程序是部署在真空中，甚至是虛擬的或基于云的應用程序有一個基礎的模型，它定義了他們的組件和托管他們的資源池之間的關系。虛擬世界中的SOA和ALM通過考慮新的虛擬應用程序部署模型開始的，而且真實服務器和虛擬應用程序部署模型之間的最大區別是網絡連接。這是SOA AML需要調解的問題。
在傳統的應用程序中，部署是分配應用程序給服務器這的事情，解析服務器的IP后允許應用程序訪問。服務器通常是網絡上一個數據中心局域網，通過VPN或互聯網進行訪問。當SOA應用程序部署時，主要不同是SOA組件化將會在組件之間創建水平的的通道。在數據中心中，基于虛擬化的數據中心，這種新水平通道仍然是在數據中心局域網中進行的，而且網絡性不太可能是主要的因素。這簡化了應用程序的測試和籌劃。
管理水平通道的挑戰
當虛擬化擴展到多個數據中心時，隨著云的應用，問題就是組件化創建的水平通道有更多的不穩定網絡連接。在真正的云應用程序中，托管的組件可以廣泛的分布，性能的不同會被擴大從而影響工作人員的QoE,甚至會引起應用程序的失敗。這意味著工作分配必須在部署中首先優化，然后在所有的ALM中進行測試，這樣軟件的版本經過驗證后，可以進行下一階段的更高級的產品。
當使用高速鏈接(比如光纖，或100G的以太網)在數據中心創建云時，性能風險會因為組件托管不同而不同，將會變小。當云計算是私有和公有的混合云，涉及到了多個公有云，或者是托管在地理位置不同的資源測試流程將會在性能上反映出潛在的大的變化。最大的不同將會出現在沒有連接到共同的虛擬局域網上，而且每個獨立IP子網絡都有不同的廣域網的云中。
除了云網絡的本質外，SOA將要在水平通道上創建變量的范圍與組件之間的工作流的范圍有關。廣泛使用消息和服務總線的應用程序更有可能受組件托管的位置的不同的影響，而不是那些有少量的組件，但是集成而不是編排的應用程序。
當SOA應用程序更有可能對水平通道性能敏感時，那么第一個目標就是在網絡層減少這種敏感，作為項目設計的一部分。這可以通過確保SOA組件之間相互托管在本地完成，這意味著有共同的數據中心。集成的和共同托管的兩個SOA應用程序的位置不實際，那么就試圖把組件分配到數據中心去，通過避免不同位置之間的高容量水平通道的方式。這要通過使用提供的工具和可靠的策略完成，不管是從商業的腳本包還是DevOps工具。
驗證策略限制條件
一旦組件化的托管計劃完成，ALM流程必須驗證這一計劃每一層次的策略限制條件，但這也不能足夠確保應用程序的穩定性。應用程序測試與變量連接延遲從而建立一個合理的向上邊界的性能問題是很重要的，實際的應用程序條件測試來違反這一邊界，來作為ALM周期的一部分。隨著應用程序進入最后階段這尤其的重要。網絡QoS可以用不同的工具測試，而且在一些情況下，一些手邊的應用程序或管理系統可能允許它被監測。使用簡單的管理工具來解析記錄組件地址路徑，從而研究當IP子網絡不匹配的情況。這將是一個暗示，云計算已經轉移組件的主機到了一個新位置，這時性能可能是一個問題。
廣泛的分布式SOA應用程序可能在用戶到應用程序的連接中也承受著大量的不確定性。這相當的真實，當應用程序托管在地理位置不同 的公有云資源上。例如，為也確保主機從一個位置到另一個位置的過渡，并且通過在移動到新位置時擱淺一些組件在某個地方，而不影響性能，ALM應該也要測試過渡流程，再一次地在產品準備階段關注測試。這將會保證可能出現在生產中的情況在變成一個問題之前能充分地解決。
此內容為AET網站原創，未經授權禁止轉載。