在應用程序投入生產時，再去修復可擴展性問題已為時過晚。相反，需要關注開發和運營合作伙伴關系以及集成測試。

 

云計算的可擴展性使用戶能夠隨著負載的增加而擴大資源消耗，但是普遍的資源增長是不夠的。并非應用程序的所有組件都需要相同的乘法運算，并且其擴展不會造成緊張的組件的負面后果。智能擴展只會增加支持重載應用程序組件的資源。運營團隊需要在設計流程的早期就開發人員與應用程序可擴展性進行溝通，并確定組件的啟動時間和方式。這些團隊應該通過集成測試一起工作，以確保應用程序在擴展以滿足需求時保持性能和可靠性。

 

 

此示例顯示了擴展資源可能出現的問題：不同分支機構的兩名工作人員幾乎同時開始交易，以銷售某種東西。交易服務檢查庫存，銷售產品并輸入訂單。而在云中，同一應用程序的兩個實例為這兩名工作人員提供支持。每個實例檢查庫存，以找到產品和訂單，但在第二種情況下，其庫存水平不反映第一個訂單正在處理的事實。

 

彈性擴展會創建不可預知數量的應用程序組件實例，并且這些實例不一定能夠彼此識別。獨立組件擴展對這種沖突構成了主要挑戰，但傳統實踐通常只處理雙倍或N + 1冗余組件。云爆發是通過容器托管、虛擬化和私有云工具實現的，云擴展可以來自公共云自動縮放功能和混合云管理器。有數百種工具可以實現突發和擴展，而這些工具通常不會期望組件知道云爆發過程。

 

IT運營團隊跟蹤哪些工作負載處于高度或過度利用狀態，以及托管資源應擴展以適應需求，但如果應用程序組件不能有效擴展，操作無法確保應用程序的可擴展架構。 DevOps的一個宗旨是將開發人員對應用程序部署和管理的要求轉化為運營術語。那么將什么轉化成運營需求，即云計算環境中的可擴展性?對于應用程序可擴展性和基礎設施靈活性，應該通過運營為開發者提供哪些具體的細節?

 

 

應用程序開發人員必須了解軟件使用的場景。并非每一筆交易都具有沖突的風險，只有那些試圖更新相關數據庫元素的服務。某些應用程序需要具備防火墻來確保與給定事務關聯的所有消息都轉到相同的處理組件。有些還需要狀態控??制，以便它們像功能組件或微服務一樣運行。縮放組件的場景感知也可以解決性能和功能方面的問題。

 

這些是只有開發人員才能解決的問題。IT運營可以擴展可用的云資源來支持軟件組件，但不能保證應用程序的性能會更好。開發人員必須知道如何設計應用程序可擴展性以及哪些組件需要它。如果沒有預期或有用的情況下增加對擴展的支持，將會增加開發成本和時間，并且可能會降低應用程序性能。當組件跨多個應用程序共享時，其問題尤其嚴重。一個開發團隊不一定知道使用相同組件的其他組件。

 

 

在軟件開始生產時，任何嘗試解決應用程序可擴展性問題的嘗試都是無效的，而且在許多情況下完全不切實際。相反，在開發早期就提出可擴展性假設的運營反饋意見，然后在生產之前驗證它們。在應用程序開發周期中，最方便的階段是集成測試。

 

開發人員以各種方式創建可擴展架構。例如，微服務和基于容器的體系結構自然會鼓勵獨立擴展。一旦開發人員了解如何擴展，以及如何與IT運營商討論如何確定組件的可能部署參數是合適的：在數據中心內部，數據中心和云計算之間，云計算提供商之間，或在一個云提供商的平臺中。

 

應用程序必須擴展的基礎設施范圍確定了組件對網絡連接傳輸延遲的敏感程度，新實例的啟動延遲以及其他實際性能因素。如果可擴展性的開發目標不能在運營中得到滿足，那么開發計劃或部署計劃必須進行調整。網絡連接、部署的合規性和治理，甚至云計算提供商的選擇都可能發生變化。

 

集成測試是開發人員和運營專家第一次查看與組件化應用程序相關的信息流，并檢查可擴展性如何影響應用程序性能和穩定性。測試人員將各個應用程序組件組合起來，以評估它們在實際工作流程中的工作方式集成測試可能會暴露孤立應用程序組件中的擴展問題，以及更高級別的問題。集成測試必須盡可能模仿實際的生產部署。

 

功能開發人員和應用程序所有者往往會忘記部署的組件必須進行負載平衡并連接到工作流程中。運營旨在以優化托管資源、網絡連接性和其他注意事項的方式部署應用程序，但是當更新數據庫不受運營控制時。一旦應用程序已經建立，管理工具就沒有什么區別了。如果最佳部署方案不夠好，則無法對其進行重新制作以掩蓋不適合的體系結構。那就有些為時過晚了。

 

將集成測試作為未來生產系統的試驗場，并從該測試環境中培養開發/運營伙伴關系，以應對應用程序自身成長時的挑戰。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。