Linux 容器輕鬆應對性能工程
應用程序的性能決定了軟體能多快完成預期任務。這回答有關應用程序的幾個問題,例如:
- 峰值負載下的響應時間
- 與替代方案相比,它易於使用,受支持的功能和用例
- 運營成本(CPU 使用率、內存需求、數據吞吐量、帶寬等)
該性能分析的價值超出了服務負載所需的計算資源或滿足峰值需求所需的應用實例數量的估計。性能顯然與成功企業的基本要素掛鉤。它揭示了用戶的總體體驗,包括確定什麼會拖慢客戶預期的響應時間,通過設計滿足帶寬要求的內容交付來提高客戶粘性,選擇最佳設備,最終幫助企業發展業務。
問題
當然,這是對業務服務的性能工程價值的過度簡化。為了理解在完成我剛剛所描述事情背後的挑戰,讓我們把它放到一個真實的稍微有點複雜的場景中。
現實世界的應用程序可能託管在雲端。應用程序可以利用非常大(或概念上是無窮大)的計算資源。在硬體和軟體方面的需求將通過雲來滿足。從事開發工作的開發人員將使用雲交付功能來實現更快的編碼和部署。雲託管不是免費的,但成本開銷與應用程序的資源需求成正比。
除了 搜索即服務 (SaaS)、 平台即服務 (PaaS)、 基礎設施即服務 (IaaS)以及 負載平衡即服務 (LBaaS)之外,當雲端管理託管程序的流量時,開發人員可能還會使用這些快速增長的雲服務中的一個或多個:
- 安全即服務 (SECaaS),可滿足軟體和用戶的安全需求
- 數據即服務 (DaaS),為應用提供了用戶需求的數據
- 登錄即服務 (LaaS),DaaS 的近親,提供了日誌傳遞和使用的分析指標
- 搜索即服務 (SaaS),用於應用程序的分析和大數據需求
- 網路即服務 (NaaS),用於通過公共網路發送和接收數據
雲服務也呈指數級增長,因為它們使得開發人員更容易編寫複雜的應用程序。除了軟體複雜性之外,所有這些分散式組件的相互作用變得越來越多。用戶群變得更加多元化。該軟體的需求列表變得更長。對其他服務的依賴性變大。由於這些因素,這個生態系統的缺陷會引發性能問題的多米諾效應。
例如,假設你有一個精心編寫的應用程序,它遵循安全編碼實踐,旨在滿足不同的負載要求,並經過徹底測試。另外假設你已經將基礎架構和分析工作結合起來,以支持基本的性能要求。在系統的實現、設計和架構中建立性能標準需要做些什麼?軟體如何跟上不斷變化的市場需求和新興技術?如何測量關鍵參數以調整系統以獲得最佳性能?如何使系統具有彈性和自我恢復能力?你如何更快地識別任何潛在的性能問題,並儘早解決?
進入容器
軟體容器以微服務設計或面向服務的架構(SoA)的優點為基礎,提高了性能,因為包含更小的、自足的代碼塊的系統更容易編碼,對其它系統組件有更清晰、定義良好的依賴。測試更容易,包括圍繞資源利用和內存過度消耗的問題比在宏架構中更容易確定。
當擴容系統以增加負載能力時,容器應用程序的複製快速而簡單。安全漏洞能更好地隔離。補丁可以獨立版本化並快速部署。性能監控更有針對性,測量更可靠。你還可以重寫和「改版」資源密集型代碼,以滿足不斷變化的性能要求。
容器啟動快速,停止也快速。它比虛擬機(VM)有更高效資源利用和更好的進程隔離。容器沒有空閑內存和 CPU 閑置。它們允許多個應用程序共享機器,而不會丟失數據或性能。容器使應用程序可移植,因此開發人員可以構建並將應用程序發送到任何支持容器技術的 Linux 伺服器上,而不必擔心性能損失。容器生存在其內,並遵守其集群管理器(如 Cloud Foundry 的 Diego、Kubernetes、Apache Mesos 和 Docker Swarm)所規定的配額(比如包括存儲、計算和對象計數配額)。
容器在性能方面表現出色,而即將到來的 「serverless」 計算(也稱為 功能即服務 (FaaS))的浪潮將擴大容器的優勢。在 FaaS 時代,這些臨時性或短期的容器將帶來超越應用程序性能的優勢,直接轉化為在雲中託管的間接成本的節省。如果容器的工作更快,那麼它的壽命就會更短,而且計算量負載純粹是按需的。
作者簡介:
Garima 是 Red Hat 的工程經理,專註於 OpenShift 容器平台。在加入 Red Hat 之前,Garima 幫助 Akamai Technologies&MathWorks Inc. 開創了創新。
via: https://opensource.com/article/17/2/performance-container-world
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive