虛拟機形态的雲伺服器産品對使用者來說是基本的計算單元，随着雲上應用規模的擴大，很多使用者在雲上保有數千乃至數萬虛拟機成為一種常态。數萬的虛拟機、數萬的IP 位址、數千的應用需要管理，這一切對于雲上的資源管理者來說壓力極大。如何幫助使用者提升雲上資源管理效率？相比于線下，雲上資源的彈性能力具有颠覆性的提升，使用者在雲上可以按需建立資源和按量付費。這種彈性能力在使用中如何變得簡單高效，是彈性計算整個業務團隊持續思考的問題。雲計算是普惠科技，必須要讓它能夠被簡單地使用。
2.4.1 資源編排服務
在雲上，由于按量付費的基本使用模型，使用者對于資源的建立和釋放的頻繁程度是遠高于線下IDC 的使用習慣的，另外考慮到使用者的業務擴張期會有更頻繁的新環境搭建、初始環境傳遞等場景，是以雲上計算環境應該有更高的資源管理要求。想象一下，如果遊戲使用者的新初始遊戲服務需要50 台伺服器，分别承擔10 種業務角色， 針對網絡、資料庫進行數百條業務配置是很正常的狀态，那如何幫助使用者簡化資源的傳遞管理、可複制，以及防止手動操作的失誤且可審計？這就是資源編排服務要解決的根本問題。資源編排服務（Resource Orchestration Service，ROS）是雲服務提供商提供的一項簡化雲計算資源管理的服務。使用者可以遵循ROS 定義的模闆規範編寫資源棧模闆，在模闆中定義所需的雲計算資源（例如ECS 執行個體、RDS 資料庫執行個體）、資源間的依賴關系等。ROS 的編排引擎将根據模闆自動完成所有資源的建立和配置，實作自動化部署及運維。
ROS 模闆是可讀、易編寫的文本檔案。使用者可以通過随時直接編輯JSON 格式文本，或者使用ROS 控制台提供的可視化編輯器來編輯模闆，可以通過SVN、Git 等版本控制工具控制模闆的版本，以達到控制基礎設施版本的目的。使用者可以通過API、SDK 等方式将ROS 的編排能力與自己的應用進行整合，實作基礎設施即代碼（Infrastructure as Code，IaC）。
ROS 模闆也是一種标準化的資源和應用傳遞方式。獨立軟體供應商（ISV）能夠通過ROS 模闆傳遞包含雲資源和應用的整體系統和解決方案，整合阿裡雲的資源和ISV 的軟體系統，實作統一傳遞。
ROS 通過資源棧（Stack）統一管理一組雲資源（一個資源棧即為一組阿裡雲資源）。對于雲資源的建立、删除、克隆等操作，都以資源棧為機關來完成。在DevOps 實踐中，使用者既可以使用ROS 克隆開發環境、測試環境和線上環境，也可以輕松實作應用的整體遷移和擴容。在雲上大規模的資源運維管理逐漸走向IaC 的形态下，ROS 可以幫助使用者快速地實踐DevOps 中IaC 的理念。
和其他同類産品相比，阿裡雲官方出品的ROS 與其他阿裡雲産品有着最佳的內建，包括統一的身份認證、安全和審計。ROS 內建了資源通路管理（RAM）來提供統一的身份認證，而無須單獨建立使用者認證體系。所有對雲産品的操作都通過Open API 調用，這意味着使用者可以使用操作審計服務（ActionTrail）來審查所有的運維操作，包括ROS 本身。
2.4.2 運維編排服務
傳遞的管理交給了資源編排服務，那大量資源的運維管理該如何加速？成千上萬的執行個體資源，作業系統内配置批量修改、更新檔更新、例行健康檢查等基礎操作都逐一登入到雲伺服器上操作，顯然是不可接受之“重”，而運維編排服務（Operation Orchestration Service，OOS）就是自動化管理和執行運維任務的得力幫手。使用者可以40
在執行模闆中定義執行任務、執行順序、執行輸入和輸出等，通過執行模闆自動化完成運維任務。運維編排服務很好地支援了以下運維場景：
執行定時和批量的運維場景。例如，批量檢查ECS 執行個體中的雲盤剩餘空間。使用者可以通過名字比對、标簽分組、資源組分組等方式選擇需要檢查的ECS 執行個體清單，再通過雲助手指令執行雲盤檢查，最終統一檢視結果。
執行事件驅動的自動化場景。例如，當某台ECS 執行個體的vCPU 使用量達到了85% 時，為了防止業務中斷，運維編排服務可以自動重新開機ECS 執行個體。
跨地域的運維場景。例如，使用者可以将一批ECS 執行個體從一個地域通過鏡像複制到另一個地域。除此之外，運維編排服務還可以作為運維任務的标準化平台，将運維手冊、操作手冊和維護手冊等轉化成模闆，實作運維即代碼（Operations as Code）形态。
好了，傳遞、運維都有工具了。那麼，如何把雲上的成本和彈性優勢發揮到極緻呢？
2.4.3 彈性伸縮
彈性是雲上特有的一種高階能力，使用者根據業務需要按需擴容或者縮容是雲上真正有意義的一個運維場景，但是擴容的資源如何加入已有的應用環境裡去、一些基本的系統關關聯作能否自動化完成，這對于使用者來說是至關重要的。比如使用者原來有10 台雲伺服器，前端通過負載均衡（SLB）做負載分擔，後端共同通路一台RDS 伺服器。這時，即使需要擴容1 台伺服器，那麼，SLB 和RDS 的白名單加白是手動還是自動，對于雲上的資源管理來說也是差别巨大的，直接決定彈性能力是所有使用者都可以直接用起來，還是僅少量的高階使用者才能享受的“特權”。
通過使用彈性伸縮（Auto Scaling），使用者可以根據業務需求和政策設定伸縮規則，在業務需求增長時自動為業務增加ECS 執行個體以保證計算能力，在業務需求下降時自動減少ECS 執行個體以節約成本。彈性伸縮不僅适合業務量不斷波動的應用程式， 同時也适合對業務量穩定的應用程式進行健康監測和異常的替換。這就是我們常說的彈性擴張、彈性收縮和彈性自愈。
彈性擴張：當業務更新時，彈性伸縮為使用者自動完成底層資源更新，避免通路延時和資源超負荷運作。使用者可以配置雲監控來實時關注ECS 執行個體的使用情況。例如，當雲監控檢測到伸縮組内的ECS 執行個體vCPU 使用率高于80% 時，彈性伸縮可根據配置的伸縮規則彈性擴張ECS 資源，自動建立合适數量的ECS 執行個體，并自動把ECS 執行個體添加到負載均衡執行個體和RDS 執行個體的通路白名單中，其具體過程如圖2-5 所示。
圖2-5 彈性擴張
彈性收縮：當業務需求下降時，彈性伸縮為使用者自動完成底層資源釋放，避免資源浪費。使用者可以配置雲監控來實時關注ECS 執行個體的使用情況。例如， 當雲監控檢測到伸縮組内的ECS 執行個體vCPU 使用率低于30% 時，彈性伸縮可根據配置的伸縮規則彈性收縮ECS 資源，自動釋放合适數量的ECS 執行個體，并自動從負載均衡執行個體和RDS 執行個體的通路白名單中移除ECS 執行個體，其具體過程如圖2-6 所示。
圖2-6 彈性收縮42
彈性自愈：彈性伸縮提供健康檢查功能，自動監控伸縮組内的ECS 執行個體的健康狀态，避免伸縮組内健康的ECS 執行個體數量低于設定的最小值。當檢測到某台ECS 執行個體處于不健康狀态時，彈性伸縮自動釋放不健康ECS 執行個體并建立新的ECS 執行個體，自動添加新ECS 執行個體到負載均衡執行個體和RDS 執行個體的通路白名單中，其具體過程如圖2-7 所示。
圖2-7 彈性自愈
彈性伸縮已有近10 種模式，如動态監控、固定時間、固定數量、健康監測、AI 智能預測等，均能對應到使用者應用的典型場景。彈性伸縮可以讓使用者做到成本的最優化，是真正降成本的雲上利器。
2.4.4 彈性供應
搶占式執行個體是一種極其特别的資源使用付費方式，使用者通過此方式以極低的成本擷取計算資源，但由于搶占式執行個體可能會被回收，是以這種執行個體有一定使用門檻。如何讓搶占式執行個體适用更多的使用者場景？彈性供應就是一個使用搶占式執行個體和按量付費執行個體快速部署執行個體叢集的方案，可一鍵部署跨計費方式、跨可用區、跨執行個體規格族的執行個體叢集。彈性供應以供應組為載體排程和維護計算資源，使用者可以通過彈性供應組穩定提供計算力，緩解搶占式執行個體的回收機制帶來的不穩定因素，免去重複手動建立執行個體的煩瑣操作。
彈性供應組的适用場景和搶占式執行個體類似，即适用無狀态的應用場景，如可橫向伸縮的Web 站點服務、圖像渲染、大資料分析、并行計算等。彈性供應組有靈活的第2 章 彈性計算産品家族43
政策組合，不僅可以緩解搶占式執行個體被回收這一問題的影響，而且以執行個體叢集的形式傳遞也更加便捷。
具體的執行個體規格和建立操作由彈性供應組自動完成，使用者無須逐一計算單台執行個體的成本。如果選擇持續保持模式，彈性供應組還會自動比較實時容量和目标容量，在搶占式執行個體被回收時按照備選執行個體規格建立執行個體，最大限度保有滿足業務需求的目标容量，以最低的成本滿足計算力需求。
簡單來說，彈性供應組可以根據使用者指定的備選執行個體規格和排程政策，建立出一個滿足計算力需求的執行個體叢集，如圖2-8 所示。
圖2-8 彈性供應組自動維護資源池
彈性供應組可以讓使用者的資源使用盡可能地自動化和低成本化，使雲上執行個體的運維成本最優。
至此，我們已完整介紹了使用者在雲上傳遞、管理、彈性、成本諸多方面的助力産品工具，接下來，我們将關注使用者上雲的問題。無論線上下，還是雲之間，平滑的業務遷移都是使用者最大的期望，那麼彈性計算哪個産品來提升這一環節的體驗呢？
2.4.5 遷移中心
雲上使用者一般可分為雲原生和從其他雲或IDC 遷移過來的兩種，前者出生即用44
雲，而後者則是認可了雲計算的優勢後，需要完成線下上雲或在雲之間遷移。雲上業務的遷移需求從雲計算誕生的第一天起就存在，但由于早期使用者以雲原生為主，企業使用者也多是獨立的小業務上雲，是以這類遷移的問題對使用者來說還算可以容忍。随着越來越多的大中型企業和核心業務選擇使用雲計算，業務的遷移成為所有大中型企業必須要面對的問題，近幾年尤其如此。伺服器遷移中心（Server Migration Center， SMC）是阿裡雲自主研發的遷移平台，可将單台或多台源伺服器遷移至阿裡雲。遷移源包括IDC 伺服器、虛拟機、其他雲平台的雲主機或其他類型的伺服器，即各種形态的計算單元，都能夠通過SMC 遷移到阿裡雲上。SMC 具有如下優勢：
不依賴遷移源的底層環境：SMC 支援P2C/V2C/C2C 遷移，支援多種格式的檔案系統和磁盤類型。
自動收集遷移源資訊：使用者無須手動配置遷移源的系統資訊。運作相關指令後，SMC 用戶端可自動收集并導入遷移源資訊至SMC 控制台，為後續遷移操作做準備。
操作便捷：SMC 控制台讓使用者可直覺便捷地配置資訊、遷移上雲。
支援批量遷移：使用者可以在SMC 控制台完成批量遷移。
集中跟蹤遷移進度：當批量遷移源伺服器至阿裡雲時，我們需要跟蹤每台遷移源的遷移狀态。SMC 控制台展示了所有遷移源和遷移任務的狀态，幫助使用者迅速了解整體遷移進度，識别并排查遷移中出現的問題。
有了遷移中心，使用者無論從何處将業務搬遷到阿裡雲上都變得簡單高效。