每日分享最新，最流行的軟體開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支援，跪求關注，點贊，留言。
當需要擴大/縮小規模時，時間就是金錢。看看使用 Render 擴充您的應用程式和服務是多麼容易。
作為軟體主管和功能開發人員，我親眼目睹了一個團隊學習了有關資源擴充和雲的重要一課。劇透警報：教訓是如果你不小心，縮放會變得昂貴！
該團隊認為他們别無選擇，隻能不斷增加負載較重的給定服務的執行個體數量。當他們完成擴充時，執行個體數比預設配置的執行個體數大幾倍。他們當時沒有意識到的是——盡管負載恢複到正常狀态——他們的額外執行個體仍然存在。
每個人似乎都對這種“根據需要擴大規模”的方法沒有意見……直到他們收到來自雲提供商的下一張發票。
這種情況讓我想到了Render，我在我的一些項目中越來越多地采用這個平台。這讓我想知道使用 Render 在基于雲的應用程式和服務中實作擴充是多麼容易。另一個劇透警報：這很容易。
基于雲的擴充的概念
您的應用程式或服務的消費者有一個共同的期望：他們的所有請求都應在合理的時間内得到處理。
同時，解決方案所有者有期望，其中包括：
- 確定滿足客戶的期望
- 将成本控制在計劃預算内
- 最大限度地減少停機時間和中斷——尤其是那些與性能相關的
當需求水準低于用于處理每個請求的技術的最大容量時，所有這些期望都很容易滿足。當需求開始超過這些水準時，事情就會變得有趣起來。
挑戰在于找到滿足預期并保持成本合理的最佳點。這就是基于雲的擴充概念發揮作用的地方。通過基于雲的擴充，重點是增加服務執行個體的數量以滿足目前需求，但在需求消退時縮減。
場景三重奏
我們将讨論自動縮放的三個用例：
- 手動縮放
- 自動擴容
- 自動縮小
讓我們通過場景示例來探索每個用例。
手動縮放
手動縮放概念适用于對其應用程式或服務的需求有深刻了解的團隊。
例如，考慮一項與所得稅相關的服務，該服務在客戶填寫納稅申報表時回答他們的問題。支援此服務的團隊可能擁有數十年的有關使用模式的資訊，使他們能夠确定全年需要多少服務執行個體。
掌握了這些資訊後，手動縮放方法将使消費者感到滿意，因為團隊始終知道應該有多少執行個體可用。解決方案所有者很高興，因為他們每月的支出完全在預算之内。
當然，此資訊并未考慮預期使用模式的重大變化。例如，可能釋出了有關該服務的新聞稿，突然對需求産生正面或負面影響。
自動擴充
自動擴充方法将執行個體數量置于由服務所有者建立但由雲提供商強制執行的預定義門檻值的手中。随着超過這些門檻值，執行個體數量将增加，直到需求下降到預期水準。大多數提供程式允許使用者設定最大執行個體數以限制最終可以生成的執行個體數。
雖然對每月預算的影響存在一些不确定性，但解決方案所有者可能會使用這樣的理由，即對其服務的需求增加通常與新訂閱或更新訂閱有關，進而帶來額外收入。
這就是“你必須花錢才能賺錢”的概念發揮作用的地方。
在實施自動擴充政策時，我總是建議對自動縮小政策也執行相同的操作。
自動縮小
自動縮減方法類似于自動擴充，隻是服務數量會随着需求的減少而減少。雖然自動擴充功能可以非常快速地引入新執行個體，但自動縮小功能通常會延遲以避免過早縮小。
回想一下我在介紹中提到的團隊，如果他們對我提到的服務采用自動縮減，他們就不會遇到在高峰需求消退後讓所有這些執行個體都運作良好的貼紙沖擊。
提供自動縮放的雲提供商現在開始将自動縮放與自動縮放結合起來，因為這是此功能的更常見實作。
使用渲染進行縮放
今年我已經寫過好幾篇關于 Render 平台的文章。以下是我關于該主題的其他一些出版物的連結：
- 第一次使用 Render and Go
- 引擎蓋下：渲染統一雲
- 目的驅動的微服務設計
- 在一天内啟動您的創業想法
我了解到他們非常重視零 DevOps 承諾。正如人們所預料的那樣，使用 Render 進行縮放很容易，并且由一個簡單的使用者界面驅動。
對于以入門計劃（或更高版本）運作的服務，手動縮放執行個體數量的能力就像在渲染儀表闆的縮放菜單中滑動到所需級别一樣簡單：
如果您有興趣在 Render 中使用自動縮放，隻需啟用自動縮放，然後：
- 選擇執行個體數
- 啟用并設定目标 CPU 使用率
- 啟用并設定目标記憶體使用率
請記住：可以将自動縮放限制為僅取決于 CPU 或記憶體使用率（而不是兩者）。
實施自動縮放後，渲染儀表闆會在對運作的執行個體數量進行更改時進行通信：
此外，還提供了名額來證明自動縮放實施的合理性：
從計費的角度來看，成本結構的變化是基于給定月份新執行個體到位的時間量。這意味着，如果您在計費周期的一天内将執行個體數量加倍 7 小時，則該計費周期的成本不會加倍；相反，它隻會在執行個體數量翻倍的那七個小時内翻倍。
其他可用的內建
使用 Render 部署的服務還可以與以下解決方案內建：
- Datadog：将 Postgres 名額和日志流提供到 Datadog 觀察平台
- Scout APM：為基于 Ruby、PHP、Python、Node.js 和 Elixir 的服務提供應用程式性能監控 (APM)
這些內建提供了洞察力，有助于在 Render 平台上運作的更大的企業級應用程式和解決方案。
結論
工作不到 13 年的技術人員很幸運，不必擔心全球經濟衰退的副作用。當今的經濟學家認為，下一次衰退将很快開始，一些經濟名額已經證明了這種說法是正确的。
這意味着公司可能會更加保守地支出以維持其底線。企業的審查領域之一是雲支出。
我仍然相信基于雲的産品和服務可以大大超過在專用資料中心内支援和維護類似配置的成本。也就是說，某些方面會顯着影響與基于雲的技術相關的定期成本：
- 對每筆發生的費用有很好的了解
- 了解如何以及何時擴充應用程式和服務以滿足需求
對于那些使用亞馬遜、谷歌或微軟雲服務的人，像CleanSlate Technology Group這樣的公司提供的服務可以幫助您解決這些問題。
自 2021 年以來，我一直在努力遵循以下使命宣言，我認為它适用于任何技術專業人士：
“将時間集中在提供可擴充知識産權價值的特性/功能上。為其他一切利用架構、産品和服務。”
- J. Vester
在我為自己的應用程式和服務使用 Render 期間，由于其零 DevOps 模型，我能夠專注于強大的功能傳遞。對于那些希望簡化其雲架構的人來說，Render 提供了關鍵任務的可擴充性，而無需成為競争對手采用的技術專家。
祝你有美好的一天！