1. 項目概述從傳統(tǒng)緩存到無服務器化的躍遷最近剛結(jié)束的亞馬遜云科技 re:Invent 2023 大會又放出了一堆讓開發(fā)者興奮的新玩意兒。作為一名常年混跡在云原生和數(shù)據(jù)庫領(lǐng)域的老兵我特別關(guān)注那些能實實在在降低運維復雜度、提升開發(fā)效率的服務更新。這次亞馬遜云科技 ElastiCache Serverless 的全面推出絕對算得上是一個重磅炸彈。你可能早就用過 ElastiCache不管是 Redis 還是 Memcached它都是我們應對高并發(fā)、低延遲數(shù)據(jù)訪問的“老伙計”。但傳統(tǒng)模式下的容量規(guī)劃、節(jié)點擴縮容、故障切換哪一樣不讓人頭疼半夜被容量告警叫起來手動擴容的經(jīng)歷相信不少朋友都有過。ElastiCache Serverless 的出現(xiàn)目標就是把這些“臟活累活”徹底接管過去。它不再要求你預先配置節(jié)點類型和數(shù)量而是根據(jù)你應用程序的實際負載在秒級內(nèi)自動伸縮你只需要為實際消耗的數(shù)據(jù)存儲和讀寫操作付費。這不僅僅是“Serverless”這個熱詞的簡單套用而是真正將緩存服務的體驗推向了一個“設(shè)置即用無需操心”的新高度。我?guī)е皡⒓酉嚓P(guān)技術(shù)競賽時對性能極致追求的眼光仔細體驗了這項新服務特別是其對 Memcached 協(xié)議的支持這背后對于大量現(xiàn)有應用的無縫遷移和現(xiàn)代化改造意義重大。2. 核心需求解析我們?yōu)槭裁葱枰?Serverless 緩存在深入動手之前我們得先搞清楚把緩存做成 Serverless 到底解決了什么痛點。傳統(tǒng)的 ElastiCache你需要像一個基礎(chǔ)設(shè)施架構(gòu)師一樣思考我的業(yè)務峰值 QPS 是多少數(shù)據(jù)量大概有多大該選cache.r6g.large還是cache.m6g.xlarge要部署多少個節(jié)點副本怎么配置這些問題在項目初期往往基于猜測要么資源過剩造成浪費要么預估不足導致性能瓶頸。2.1 應對不可預測的流量波峰現(xiàn)代應用尤其是面向消費者的互聯(lián)網(wǎng)應用流量模式越來越難以預測。一次成功的營銷活動、一個突然爆火的社交話題都可能帶來瞬間的流量洪峰。傳統(tǒng)固定容量的緩存集群要么在平時閑置大量資源要么在高峰時被擊穿導致請求直接壓向后端數(shù)據(jù)庫引發(fā)雪崩。Serverless 緩存的核心價值之一就是彈性。它通過實時監(jiān)控負載指標自動增加“計算單元”來處理更多的連接和請求同時擴展存儲來容納增長的數(shù)據(jù)。這意味著你的應用可以平滑應對“黑色星期五”式的購物狂潮而無需提前數(shù)月進行容量規(guī)劃和壓力測試。2.2 簡化開發(fā)測試與運維流程在開發(fā)、測試、預發(fā)布和生產(chǎn)多個環(huán)境中維護一套配置不同的緩存集群是件繁瑣的事。開發(fā)人員可能只需要一個很小的緩存實例來跑單元測試而生產(chǎn)環(huán)境則需要一個多可用區(qū)的高可用集群。使用 Serverless 模式你可以在所有環(huán)境使用同一種配置方式——即“無需配置”。只需定義好一個緩存端點Endpoint所有環(huán)境都按需使用按量付費。這極大地簡化了 CI/CD 流水線實現(xiàn)了環(huán)境配置的標準化。對于運維團隊而言他們從繁重的容量監(jiān)控、擴縮容操作、補丁升級中解放出來可以將精力更多地投入到更高價值的業(yè)務邏輯監(jiān)控和優(yōu)化上。2.3 優(yōu)化成本結(jié)構(gòu)為實際價值付費傳統(tǒng)預置模式下成本是固定的無論你的緩存使用了 30% 還是 80% 的資源你都需要為整個節(jié)點的運行時間付費。Serverless 緩存采用了更精細的計費模型通常包括兩部分數(shù)據(jù)存儲費按 GB-小時計費和ECPU 費ElastiCache Processing Unit衡量計算消耗。你的成本直接與應用程序的實際使用量掛鉤。對于流量呈現(xiàn)明顯波峰波谷的應用如白天活躍、夜間空閑的辦公系統(tǒng)或者處于探索階段、流量不確定的新業(yè)務這種成本模型可以帶來顯著的節(jié)省。注意Serverless 并不意味著在所有場景下都更便宜。對于負載持續(xù)穩(wěn)定且可高度預測的應用長期預留實例可能更具成本效益。選擇的關(guān)鍵在于評估你業(yè)務的流量模式是否具有“波動性”和“不可預測性”。3. 產(chǎn)品體驗與核心特性深度剖析基于 re:Invent 2023 發(fā)布的最新能力我通過控制臺和 CLI 完整地創(chuàng)建和測試了一個 ElastiCache Serverless 緩存。下面結(jié)合我的實操拆解它的幾個核心特性。3.1 極簡化的創(chuàng)建與配置流程創(chuàng)建過程直觀得令人驚訝。在亞馬遜云科技管理控制臺進入 ElastiCache 服務選擇“創(chuàng)建緩存”你會看到“無服務器”作為一個頂級選項。與傳統(tǒng)模式需要選擇節(jié)點類型、數(shù)量、副本等數(shù)十個配置項不同Serverless 模式下你需要配置的核心參數(shù)屈指可數(shù)名稱與描述為你的緩存起個名字。引擎與版本選擇 Redis 或 Memcached。我重點體驗了 Memcached因為它協(xié)議簡單在大量遺留系統(tǒng)中應用廣泛。子網(wǎng)組指定緩存將部署在哪個 VPC 和子網(wǎng)中這是為了網(wǎng)絡(luò)隔離和安全。安全組控制哪些資源如 EC2 實例、Lambda 函數(shù)可以訪問這個緩存端點。加密可選擇靜態(tài)加密使用 KMS 密鑰和傳輸中加密這是安全最佳實踐。容量限制可選你可以設(shè)置存儲容量的上限防止因應用 bug 導致無限寫入而產(chǎn)生意外費用。這是一個非常重要的成本控制閥。點擊創(chuàng)建后通常在 1-2 分鐘內(nèi)一個可用的緩存端點就準備就緒了。你不需要關(guān)心它背后啟動了多少個節(jié)點分布在哪些可用區(qū)。這種體驗非常類似于創(chuàng)建一個 S3 存儲桶或一個 DynamoDB 表。3.2 自動化的彈性伸縮與高可用這是 Serverless 的“魔法”所在。創(chuàng)建完成后我使用一個簡單的 Python 腳本模擬了不同的負載場景。場景一平穩(wěn)負載期。腳本以每秒約 100 次SET/GET操作的速率運行。通過 CloudWatch 監(jiān)控指標可以看到DatabaseCapacityUsage計算容量使用率和StorageUsage存儲使用率保持在一個穩(wěn)定且較低的水平。此時服務可能只運行著最小規(guī)模的計算單元。場景二流量激增期。我啟動了多個并發(fā)腳本將請求速率瞬間提升到每秒 5000 次以上。在監(jiān)控儀表盤上可以清晰地觀察到DatabaseCapacityUsage指標開始攀升。關(guān)鍵點在于應用的 P99 延遲并沒有出現(xiàn)明顯的毛刺或飆升。這意味著在流量激增的幾秒到幾十秒內(nèi)ElastiCache Serverless 已經(jīng)自動完成了計算資源的擴容以維持穩(wěn)定的低延遲性能。這個過程對應用完全透明無需任何人工干預。場景三數(shù)據(jù)量增長。我修改腳本持續(xù)寫入大量隨機數(shù)據(jù)。隨著StorageUsage的增長存儲層也在自動擴展。更重要的是其高可用架構(gòu)是內(nèi)置的。數(shù)據(jù)在多個可用區(qū)AZ間自動同步即使整個可用區(qū)發(fā)生故障服務也會在另一個可用區(qū)快速重建端點保障可用性。這比手動配置和管理一個跨 AZ 的副本集要可靠和簡單得多。3.3 全面的監(jiān)控、日志與集成運維的簡化不代表可觀測性的削弱。ElastiCache Serverless 提供了豐富的 CloudWatch 指標除了上面提到的容量使用率還有CurrConnections當前連接數(shù)、NetworkBytesIn/Out網(wǎng)絡(luò)流量、CacheHitRate緩存命中率等關(guān)鍵指標。你可以基于這些指標設(shè)置告警例如當緩存命中率過低時發(fā)出通知提示可能需要優(yōu)化緩存鍵設(shè)計或數(shù)據(jù)淘汰策略。此外你可以輕松地將慢查詢?nèi)罩救绻褂?Redis或?qū)徲嬋罩景l(fā)布到 CloudWatch Logs 或 S3便于后續(xù)分析和安全審計。與 AWS IAM 的深度集成使得你可以精細地控制哪個 IAM 角色或用戶可以執(zhí)行哪些操作如elasticache:Connect實現(xiàn)了權(quán)限管控的安全最佳實踐。4. 應用實踐將現(xiàn)有應用遷移至 ElastiCache Serverless理論再好終需落地。對于廣大開發(fā)者而言最關(guān)心的問題莫過于我現(xiàn)有的應用如何能平滑地用上這個新東西好消息是遷移成本極低。4.1 客戶端連接的無縫切換這是 ElastiCache Serverless 設(shè)計上最精妙的一點它完全兼容現(xiàn)有的 Memcached 和 Redis 客戶端協(xié)議。你的應用程序代碼幾乎不需要任何修改。以我測試中使用的 Pythonpymemcache客戶端為例。原來連接傳統(tǒng) ElastiCache 集群的代碼可能是這樣的from pymemcache.client.hash import HashClient # 傳統(tǒng)集群模式需要列出所有節(jié)點端點 servers [(cluster-node-1.xxxxx.cache.amazonaws.com, 11211), (cluster-node-2.xxxxx.cache.amazonaws.com, 11211)] client HashClient(servers, use_poolingTrue)遷移到 Serverless 后代碼簡化到只需一個端點from pymemcache.client.base import Client # Serverless 模式只有一個統(tǒng)一的端點 serverless_endpoint your-cache-name.xxxxx.serverless.cache.amazonaws.com client Client((serverless_endpoint, 11211))你不再需要關(guān)心客戶端的分片邏輯HashClient因為 Serverless 服務內(nèi)部替你處理了所有數(shù)據(jù)分片和請求路由。對于 Redis 客戶端情況類似你只需要將連接字符串指向新的 Serverless 端點即可。這意味著遷移可以分階段進行例如先在非關(guān)鍵業(yè)務或新功能上試用穩(wěn)定后再逐步切割流量。4.2 配置與最佳實踐調(diào)整雖然代碼改動小但為了獲得最佳性能和成本效益一些配置和思維需要轉(zhuǎn)變連接池管理由于 Serverless 緩存可以快速伸縮保持一個適度大小的連接池并啟用連接健康檢查是個好習慣。避免為每個請求創(chuàng)建新連接也避免維持過多空閑連接。大多數(shù)現(xiàn)代客戶端庫都支持連接池。超時與重試策略盡管服務可用性很高但在極罕見的伸縮事件或故障轉(zhuǎn)移瞬間連接可能會短暫中斷。為客戶端配置合理的連接超時、操作超時和退避重試機制能提升應用的韌性。例如采用指數(shù)退避策略進行重試。緩存鍵設(shè)計與淘汰策略Serverless 按存儲量收費因此管理好緩存數(shù)據(jù)的生命周期尤為重要。積極使用 TTL生存時間避免永久存儲不再需要的數(shù)據(jù)。對于 Memcached它本身基于 LRU 自動淘汰但設(shè)定合理的 TTL 是開發(fā)者的責任。對于 Redis Serverless你可以配置基于內(nèi)存使用率的逐出策略。監(jiān)控緩存命中率緩存命中率是衡量緩存效益的核心指標。命中率低意味著大量請求穿透到后端數(shù)據(jù)庫不僅增加了延遲也使得 Serverless 緩存的計算資源ECPU被低效利用。持續(xù)監(jiān)控并優(yōu)化它。4.3 實戰(zhàn)遷移檢查清單為了幫助你更順利地遷移我整理了一份簡易檢查清單步驟任務說明與注意事項1. 評估與規(guī)劃分析現(xiàn)有緩存集群的監(jiān)控數(shù)據(jù)流量模式、數(shù)據(jù)量、命中率。確認業(yè)務模式是否適合 Serverless波動大、不可預測。計算當前成本作為遷移后的對比基線。2. 創(chuàng)建與測試在測試環(huán)境創(chuàng)建 ElastiCache Serverless 緩存。使用與生產(chǎn)環(huán)境隔離的 VPC/子網(wǎng)。初步測試客戶端連通性和基本操作。3. 客戶端適配修改應用配置將緩存端點指向新的 Serverless 地址。關(guān)鍵通常只需改配置無需改代碼邏輯。確保客戶端庫版本兼容。4. 數(shù)據(jù)預熱可選如果緩存冷啟動對業(yè)務影響大考慮編寫腳本預熱關(guān)鍵數(shù)據(jù)。Serverless 實例啟動時緩存是空的。對于重啟容忍度低的應用預熱能平滑遷移。5. 流量切換采用藍綠部署或金絲雀發(fā)布方式逐步切流。例如先讓 10% 的讀流量走新緩存監(jiān)控延遲和錯誤率穩(wěn)定后再逐步提升比例最后切換寫流量。6. 監(jiān)控與優(yōu)化密切監(jiān)控 CloudWatch 指標特別是延遲、命中率和容量使用率。根據(jù)監(jiān)控結(jié)果優(yōu)化 TTL、調(diào)整客戶端連接池參數(shù)。設(shè)置成本告警如每日費用超閾值。7. 清理舊資源確認新緩存穩(wěn)定運行后下線舊的 ElastiCache 集群。務必在舊集群下線前確認所有流量都已切換并備份最終數(shù)據(jù)如果需要。5. 場景化應用與成本分析ElastiCache Serverless 并非萬能鑰匙但在特定場景下它能發(fā)揮出巨大威力。結(jié)合成本分析能幫助我們做出更明智的選擇。5.1 典型適用場景深度解讀微服務與事件驅(qū)動架構(gòu)在微服務架構(gòu)中每個服務的負載可能獨立變化。為每個服務單獨預置一個緩存集群成本高昂且管理復雜。使用 Serverless 緩存每個微服務或一組相關(guān)微服務可以共享或獨享一個按需伸縮的緩存端點架構(gòu)更清晰資源利用率更高。對于由事件如消息隊列消息觸發(fā)的 Lambda 函數(shù)Serverless 緩存是完美的搭檔它能匹配 Lambda 的瞬時并發(fā)起落。開發(fā)測試與 CI/CD 環(huán)境如前所述這些環(huán)境的使用是間歇性和低負載的。為每個開發(fā)分支或測試套件維護一個常駐的緩存集群是巨大的浪費。使用 Serverless 緩存環(huán)境可以隨時創(chuàng)建、按需使用并在不需要時自動“縮容到零”嚴格來說是極低的基礎(chǔ)容量實現(xiàn)顯著的開發(fā)成本節(jié)約。新業(yè)務與原型驗證在新產(chǎn)品上線初期用戶量和數(shù)據(jù)增長軌跡難以預測。采用 Serverless 緩存你可以避免在基礎(chǔ)設(shè)施容量規(guī)劃上過度投入快速啟動業(yè)務并根據(jù)實際增長情況付費。如果業(yè)務失敗也不會留下閑置的預付費資源。應對季節(jié)性峰值零售、票務、在線教育等行業(yè)具有鮮明的季節(jié)性。Serverless 緩存能自動應對大促、開學季等流量高峰而在淡季自動縮減成本。你無需再為了一年幾次的高峰而常年維持龐大的集群。5.2 成本模型拆解與估算示例理解 Serverless 緩存的成本構(gòu)成至關(guān)重要。其主要費用來自兩部分存儲費用按你的緩存中存儲的數(shù)據(jù)總量GB每小時計費。價格因區(qū)域而異。ECPU 費用這是計算資源的度量單位。你的每一次緩存操作如 GET, SET, INCR 等都會消耗一定的 ECPU。消耗量取決于操作的復雜性和數(shù)據(jù)大小。服務會根據(jù)你的請求吞吐量自動伸縮 ECPU 資源。為了給你一個直觀的概念我們做一個簡單的估算對比假設(shè)場景一個中型電商應用日常緩存數(shù)據(jù)量約 50GB日均緩存請求約 1 億次。請求模式呈典型“雙峰”分布白天高峰時段8小時請求速率是夜間低谷時段的5倍。傳統(tǒng)預置模式方案為了覆蓋白天高峰你需要部署一個足夠大的集群。假設(shè)選擇 3 個cache.r6g.2xlarge節(jié)點按需價格約 $1.0/小時。為了高可用可能還需跨 AZ 部署。月度成本估算3 節(jié)點 * $1.0/小時 * 24 小時 * 30 天 $2160。這還不包括存儲費用通常包含在節(jié)點價格中和可能的數(shù)據(jù)傳輸費用。Serverless 模式方案我們根據(jù)公開的定價示例進行估算。假設(shè)每百萬次 ECPU 請求費用為 $0.10每 GB-小時存儲費用為 $0.025。ECPU 費用1 億次/天 * 30 天 / 100萬 * $0.10 $300存儲費用50 GB * $0.025/GB-小時 * 24 小時 * 30 天 $900月度總成本估算$300 $900 $1200在這個簡化的例子中Serverless 模式顯示了約 44% 的成本節(jié)省。但請注意這只是一個示意性估算。實際成本受眾多因素影響具體的請求類型簡單 GET 與復雜 Lua 腳本消耗的 ECPU 不同、區(qū)域定價、數(shù)據(jù)傳輸量、是否使用預留容量等。對于負載極其穩(wěn)定且可預測的應用長期使用預留實例的傳統(tǒng)集群可能價格更低。實操心得在決定遷移前強烈建議使用亞馬遜云科技官方的成本計算器。你可以根據(jù)從現(xiàn)有集群 CloudWatch 中導出的歷史指標如GetTypeCmdsSetTypeCmds和BytesUsedForCache輸入到計算器中獲得一個相對準確的 Serverless 模式成本預估。這比任何經(jīng)驗猜測都可靠。6. 常見問題與故障排查實錄在實際體驗和與同行交流中我總結(jié)了一些可能會遇到的問題及其排查思路。6.1 連接與性能相關(guān)問題問題1應用程序偶爾出現(xiàn)連接超時或“Cannot assign requested address”錯誤。排查思路檢查客戶端配置這是最常見的原因。確認客戶端使用了連接池并且連接池大小設(shè)置合理。過小的連接池在高并發(fā)下會導致連接等待超時過大的連接池可能耗盡客戶端或服務器端的端口/內(nèi)存資源。同時檢查SO_KEEPALIVE或客戶端庫的心跳配置是否開啟以清理死連接。檢查安全組和網(wǎng)絡(luò) ACL確保運行應用的 EC2、EKS 節(jié)點或 Lambda 函數(shù)所在的安全組允許出站連接到 ElastiCache Serverless 緩存端口的 11211Memcached或 6379Redis。同時檢查緩存子網(wǎng)關(guān)聯(lián)的網(wǎng)絡(luò) ACL確保雙向流量允許。檢查 VPC 端點策略如果通過 VPC 端點訪問其他服務確保策略不會意外阻斷。監(jiān)控服務器端指標查看 CloudWatch 中的CurrConnections和NewConnections。如果連接數(shù)持續(xù)接近或達到上限Serverless 有默認軟限制可提工單調(diào)整則需優(yōu)化客戶端連接復用或申請?zhí)岣呦拗?。問題2遷移后P95/P99 延遲比在傳統(tǒng)集群中略有增加。排查思路理解架構(gòu)差異Serverless 緩存是多租戶架構(gòu)底層資源動態(tài)調(diào)度。在極端情況下可能會引入微秒級的額外開銷這對于 99% 的應用無關(guān)緊要。首先確認增加的延遲是否在業(yè)務可接受范圍內(nèi)例如從 0.5ms 增加到 0.8ms。進行基準測試對比在相同網(wǎng)絡(luò)環(huán)境同一可用區(qū)下使用相同的負載模式如memtier_benchmark工具對傳統(tǒng)集群和 Serverless 緩存進行壓測獲取客觀數(shù)據(jù)。檢查客戶端位置確保測試應用與 Serverless 緩存部署在同一個亞馬遜云科技區(qū)域最好是同一個可用區(qū)以最小化網(wǎng)絡(luò)延遲。分析請求模式大量的小包請求如頻繁的GET一個很小的鍵可能比少量的大包請求更能凸顯網(wǎng)絡(luò)往返開銷。優(yōu)化請求模式考慮使用批處理命令如 Redis 的MGET、MSET或 Memcached 的get_multi來減少網(wǎng)絡(luò)往返次數(shù)。6.2 數(shù)據(jù)與成本相關(guān)問題問題3緩存命中率Cache Hit Rate下降。排查思路確認指標來源確保你查看的是 CloudWatch 提供的CacheHitRate指標而不是客戶端自行統(tǒng)計的可能不準確的指標。分析鍵的 TTL檢查是否大量緩存鍵未設(shè)置 TTL 或 TTL 設(shè)置過長導致緩存被不常訪問的“冷數(shù)據(jù)”占滿熱數(shù)據(jù)被淘汰。適當縮短默認 TTL或?qū)Σ煌臄?shù)據(jù)類別設(shè)置差異化的 TTL。檢查緩存鍵設(shè)計是否存在大量一次性或隨機化的緩存鍵如 session:${randomId}這會導致緩存效率極低?？紤]能否將這類數(shù)據(jù)移至更適合的存儲如會話存儲數(shù)據(jù)庫或?qū)︽I進行歸一化處理。審視數(shù)據(jù)更新策略是“寫后淘汰”Cache-Aside還是“寫穿透”Write-Through在 Cache-Aside 模式下數(shù)據(jù)庫更新后需要主動淘汰或更新緩存如果這一步遺漏就會導致臟讀和命中率下降。問題4Serverless 緩存的費用超出預期。排查思路細化成本分析使用成本資源管理器按“使用類型”篩選 ElastiCache 費用清晰看到 ECPU 和存儲各自的消耗占比。分析 ECPU 消耗如果 ECPU 費用占比高回到 CloudWatch分析DatabaseCapacityUsage和命令計數(shù)指標。是否存在異常的請求風暴是否有客戶端在頻繁執(zhí)行低效操作如KEYS *命令分析存儲消耗如果存儲費用占比高檢查StorageUsage增長趨勢。是否有預期外的數(shù)據(jù)大量寫入是否忘記了設(shè)置 TTL導致數(shù)據(jù)只增不減使用 Redis 的INFO memory命令通過 CLI 連接或設(shè)計掃描腳本來分析大鍵和鍵數(shù)量。設(shè)置預算告警在“預算”服務中為 ElastiCache 成本設(shè)置月度預算和告警例如達到預算的 80% 時通知這是成本管控的主動措施。6.3 監(jiān)控與告警配置建議僅僅排查問題是不夠的建立 proactive 的監(jiān)控體系才能防患于未然。以下是我建議配置的核心 CloudWatch 告警告警指標建議閾值告警原因與行動DatabaseCapacityUsage 80% 持續(xù) 5 分鐘計算容量持續(xù)高位運行可能預示流量超過預期增長或存在低效操作。需要檢查應用負載和查詢模式。StorageUsage 你設(shè)定上限的 80%存儲即將達到限制。需要檢查數(shù)據(jù)寫入是否異?；蚩紤]提高存儲上限以防寫入失敗。CacheHitRate 90% 根據(jù)業(yè)務調(diào)整緩存命中率過低大量請求穿透到數(shù)據(jù)庫影響性能和成本。需要優(yōu)化緩存策略或鍵設(shè)計。CurrConnections 你設(shè)定上限的 80%連接數(shù)接近限制可能影響新連接建立。需要優(yōu)化客戶端連接池或申請?zhí)岣哌B接數(shù)限制。EngineCPUUtilization 90% 持續(xù) 3 分鐘僅適用于提供該指標的引擎版本底層計算資源利用率極高是性能瓶頸的強烈信號。體驗完 ElastiCache Serverless特別是其 Memcached 兼容性給我的感覺是“潤物細無聲”。它沒有強迫開發(fā)者改變?nèi)魏螒脤訁f(xié)議卻從根本上改變了我們管理和消費緩存資源的方式。對于追求敏捷、效率和成本優(yōu)化的團隊來說這無疑是一個強有力的工具。當然任何技術(shù)選型都需結(jié)合具體場景。我的建議是對于新建項目或具有明顯波動負載的現(xiàn)有項目可以毫不猶豫地將其作為首選。對于負載極度穩(wěn)定、且已通過預留實例獲得極低成本的超大規(guī)模型應用則可以詳細進行成本測算后再做決定。云服務的進化正一步步將我們從繁重的基礎(chǔ)設(shè)施管理中解放出來讓我們能更專注于創(chuàng)造業(yè)務價值本身。