|
新聞中心
當(dāng)前位置：網(wǎng)站首頁 > 新聞中心
企業(yè)需關(guān)注云計算中的應(yīng)用程序可擴(kuò)展性
云計算可以無限擴(kuò)展，并不意味著應(yīng)用程序中的每個組件都應(yīng)該這樣。當(dāng)運(yùn)營商不參與設(shè)計和測試時，團(tuán)隊(duì)可能就會浪費(fèi)資金，并降低應(yīng)用程序的性能。在應(yīng)用程序投入生產(chǎn)時，再去修復(fù)可擴(kuò)展性問題已為時過晚。相反，需要關(guān)注開發(fā)和運(yùn)營合作伙伴關(guān)系以及集成測試。
云計算的可擴(kuò)展性使用戶能夠隨著負(fù)載的增加而擴(kuò)大資源消耗，但是普遍的資源增長是不夠的。并非應(yīng)用程序的所有組件都需要相同的乘法運(yùn)算，并且其擴(kuò)展不會造成緊張的組件的負(fù)面后果。智能擴(kuò)展只會增加支持重載應(yīng)用程序組件的資源。運(yùn)營團(tuán)隊(duì)需要在設(shè)計流程的早期就開發(fā)人員與應(yīng)用程序可擴(kuò)展性進(jìn)行溝通，并確定組件的啟動時間和方式。這些團(tuán)隊(duì)?wèi)?yīng)該通過集成測試一起工作，以確保應(yīng)用程序在擴(kuò)展以滿足需求時保持性能和可靠性。應(yīng)用程序可擴(kuò)展性是棘手的業(yè)務(wù)
此示例顯示了擴(kuò)展資源可能出現(xiàn)的問題：不同分支機(jī)構(gòu)的兩名工作人員幾乎同時開始交易，以銷售某種東西。交易服務(wù)檢查庫存，銷售產(chǎn)品并輸入訂單。而在云中，同一應(yīng)用程序的兩個實(shí)例為這兩名工作人員提供支持。每個實(shí)例檢查庫存，以找到產(chǎn)品和訂單，但在第二種情況下，其庫存水平不反映第一個訂單正在處理的事實(shí)。
彈性擴(kuò)展會創(chuàng)建不可預(yù)知數(shù)量的應(yīng)用程序組件實(shí)例，并且這些實(shí)例不一定能夠彼此識別。獨(dú)立組件擴(kuò)展對這種沖突構(gòu)成了主要挑戰(zhàn)，但傳統(tǒng)實(shí)踐通常只處理雙倍或N + 1冗余組件。云爆發(fā)是通過容器托管、虛擬化和私有云工具實(shí)現(xiàn)的，云擴(kuò)展可以來自公共云自動縮放功能和混合云管理器。有數(shù)百種工具可以實(shí)現(xiàn)突發(fā)和擴(kuò)展，而這些工具通常不會期望組件知道云爆發(fā)過程。
IT運(yùn)營團(tuán)隊(duì)跟蹤哪些工作負(fù)載處于高度或過度利用狀態(tài)，以及托管資源應(yīng)擴(kuò)展以適應(yīng)需求，但如果應(yīng)用程序組件不能有效擴(kuò)展，操作無法確保應(yīng)用程序的可擴(kuò)展架構(gòu)。 DevOps的一個宗旨是將開發(fā)人員對應(yīng)用程序部署和管理的要求轉(zhuǎn)化為運(yùn)營術(shù)語。那么將什么轉(zhuǎn)化成運(yùn)營需求，即云計算環(huán)境中的可擴(kuò)展性?對于應(yīng)用程序可擴(kuò)展性和基礎(chǔ)設(shè)施靈活性，應(yīng)該通過運(yùn)營為開發(fā)者提供哪些具體的細(xì)節(jié)?
開發(fā)人員在應(yīng)用程序擴(kuò)展中的角色
應(yīng)用程序開發(fā)人員必須了解軟件使用的場景。并非每一筆交易都具有沖突的風(fēng)險，只有那些試圖更新相關(guān)數(shù)據(jù)庫元素的服務(wù)。某些應(yīng)用程序需要具備防火墻來確保與給定事務(wù)關(guān)聯(lián)的所有消息都轉(zhuǎn)到相同的處理組件。有些還需要狀態(tài)控??制，以便它們像功能組件或微服務(wù)一樣運(yùn)行?？s放組件的場景感知也可以解決性能和功能方面的問題。
這些是只有開發(fā)人員才能解決的問題。IT運(yùn)營可以擴(kuò)展可用的云資源來支持軟件組件，但不能保證應(yīng)用程序的性能會更好。開發(fā)人員必須知道如何設(shè)計應(yīng)用程序可擴(kuò)展性以及哪些組件需要它。如果沒有預(yù)期或有用的情況下增加對擴(kuò)展的支持，將會增加開發(fā)成本和時間，并且可能會降低應(yīng)用程序性能。當(dāng)組件跨多個應(yīng)用程序共享時，其問題尤其嚴(yán)重。一個開發(fā)團(tuán)隊(duì)不一定知道使用相同組件的其他組件。
部署范圍和集成測試
在軟件開始生產(chǎn)時，任何嘗試解決應(yīng)用程序可擴(kuò)展性問題的嘗試都是無效的，而且在許多情況下完全不切實(shí)際。相反，在開發(fā)早期就提出可擴(kuò)展性假設(shè)的運(yùn)營反饋意見，然后在生產(chǎn)之前驗(yàn)證它們。在應(yīng)用程序開發(fā)周期中，最方便的階段是集成測試。
開發(fā)人員以各種方式創(chuàng)建可擴(kuò)展架構(gòu)。例如，微服務(wù)和基于容器的體系結(jié)構(gòu)自然會鼓勵獨(dú)立擴(kuò)展。一旦開發(fā)人員了解如何擴(kuò)展，以及如何與IT運(yùn)營商討論如何確定組件的可能部署參數(shù)是合適的：在數(shù)據(jù)中心內(nèi)部，數(shù)據(jù)中心和云計算之間，云計算提供商之間，或在一個云提供商的平臺中。
應(yīng)用程序必須擴(kuò)展的基礎(chǔ)設(shè)施范圍確定了組件對網(wǎng)絡(luò)連接傳輸延遲的敏感程度，新實(shí)例的啟動延遲以及其他實(shí)際性能因素。如果可擴(kuò)展性的開發(fā)目標(biāo)不能在運(yùn)營中得到滿足，那么開發(fā)計劃或部署計劃必須進(jìn)行調(diào)整。網(wǎng)絡(luò)連接、部署的合規(guī)性和治理，甚至云計算提供商的選擇都可能發(fā)生變化。
集成測試是開發(fā)人員和運(yùn)營專家第一次查看與組件化應(yīng)用程序相關(guān)的信息流，并檢查可擴(kuò)展性如何影響應(yīng)用程序性能和穩(wěn)定性。測試人員將各個應(yīng)用程序組件組合起來，以評估它們在實(shí)際工作流程中的工作方式集成測試可能會暴露孤立應(yīng)用程序組件中的擴(kuò)展問題，以及更高級別的問題。集成測試必須盡可能模仿實(shí)際的生產(chǎn)部署。
功能開發(fā)人員和應(yīng)用程序所有者往往會忘記部署的組件必須進(jìn)行負(fù)載平衡并連接到工作流程中。運(yùn)營旨在以優(yōu)化托管資源、網(wǎng)絡(luò)連接性和其他注意事項(xiàng)的方式部署應(yīng)用程序，但是當(dāng)更新數(shù)據(jù)庫不受運(yùn)營控制時。一旦應(yīng)用程序已經(jīng)建立，管理工具就沒有什么區(qū)別了。如果最佳部署方案不夠好，則無法對其進(jìn)行重新制作以掩蓋不適合的體系結(jié)構(gòu)。那就有些為時過晚了。
將集成測試作為未來生產(chǎn)系統(tǒng)的試驗(yàn)場，并從該測試環(huán)境中培養(yǎng)開發(fā)/運(yùn)營伙伴關(guān)系，以應(yīng)對應(yīng)用程序自身成長時的挑戰(zhàn)。
|
