ECS應用管理最佳實踐

前言

即使在CloudNative發展如火如荼的當下，ECS應用（直接将應用部署在ECS上，不使用容器）仍然占了相當大的比重，原因主要在于相對容器化應用，ECS應用由于不需要容器的運作時環境和類似K8S的排程層軟體，是以存在一些天然優勢，比如：

• 更低的Overhead，可以更充分發揮硬體的處理能力，适合用于工作負載比較高的元件或應用
• 更高的單元可靠性，結合高可用方案，可以實作很好的整體可用性
• 更好的安全性，因為隔離在虛拟化層面
• 更易用的運維界面，對運維的技能要求更低
• 對于既存系統，無改造成本

當然，對比于容器化的應用，ECS應用的劣勢也很明顯，因為缺少統一的部署标準和排程系統，需要使用者通過腳本或配管工具才能實作自動化管理，而這些附加手段由于本身缺乏标準，如果使用者沒有良好的運維能力，其本身的功能完整性和可靠性都有可能成為制約業務發展的不利因素。

拿釋出應用過程來看，往往會經曆資源預備，應用部署和服務上線等操作，對于ECS應用，這些操作基本隻能用腳本來進行串聯，使用腳本建立使用者，使用腳本配置服務，使用腳本挂載磁盤，使用腳本部署，使用腳本配置負載均衡......

腳本勝在高效靈活，且可以滿足大部分場景的需求，主要缺點則包括：

• 易錯，對于使用者有較高的意識和技能要求;
• 缺少上下文資訊，需要配合CMDB來使用;
• 需要運作環境，不易被內建;
• 通用性比較差，往往多個元件，多套環境之間的腳本是不可互換的

如果使用者希望從Devops，彈性伸縮，微服務架構中擷取優勢，必然會面對更為頻繁的資源建立，應用部署，資源銷毀動作，這時腳本很容易就會變成系統的阿喀琉斯之踵，需要投入精力去小心翼翼的維護，這就是ECS應用管理中的痛點，我們需要揚長避短。

EDAS如何提供幫助

我們認識到，面對不同的使用者和各異的業務場景，尋求一個“萬能”架構是極其困難甚至不可能的，是以在多數情況下，業務系統尤其是複雜系統，往往呈現出混合架構的特點；在架構演進過程中，也總會有中間狀态存在，對于一個不停發展的系統，中間态就是常态。“混合”并不等于“不良”，隻是相比“純”标準化系統或者CloudNative的系統，混合架構的系統會存在相對較高的管理成本，因為各元件的部署形态和管理模式并不相同。

使用者在做架構選擇時固然要将運維成本納入考慮，但業務的适用性永遠是更重要的決策依據，使用者需要聚焦業務本身，

EDAS

的任務在于幫助使用者降低運維成本，使得架構能更好的适應業務發展，提供更多價值。

為了實作這一目标，EDAS對于資源，應用，服務做了清晰的模組化，并在相應的層次内提供了多種适配方案，比如：在資源層，EDAS既允許使用者使用K8S，也允許使用者直接使用ECS，同時也提供了完全屏蔽掉資源層的Serverless方案；EDAS既可以管理阿裡雲的ECS主機也可以管理使用者自建IDC内的主機；在服務層，EDAS又可以無縫的對接HSF，Dubbo，SpringCloud等多種主流微服務體系，提供諸如調用鍊跟蹤，服務監控，限流降級等多種功能。

相比其他的PAAS平台，使用者往往隻需要很少的改動就可以将應用托管到EDAS，而且EDAS可以發揮阿裡在Java應用和大規模分布式系統領域的深厚積澱，在保證自身處理高效的同時還可以提供給使用者更多有價值的資訊。

對于ECS應用，EDAS不強制使用者做容器化改造，如果使用者希望使用ECS，應用适合運作于ECS，那應用就應該使用ECS。而EDAS則會幫助使用者消除運維過程中的各種障礙，我們下面會介紹一些優化實踐，通過這些大家也許可以發現享受雲計算所帶來的價值并不需要“純”的CloudNative架構。

實踐1：環境配置标準化

如前文所述，應用管理過程中面臨的一大問題就是腳本的脆弱性，包括環境初始化，應用部署，服務上線等各個環節的使用腳本。再進一步分析，當應用被EDAS管理後，部署和服務管控的流程也就随之标準化了，是以這些腳本是會被取代的，但在被EDAS管理之前，環境初始化過程中往往包含了業務特定的配置，如果不使用腳本，怎樣将環境資訊傳遞給EDAS，讓平台來完成初始化過程？

先來看容器化的應用，它們依靠鏡像提供了一個良好的解耦點，因為環境配置是包含在鏡像内的，鏡像粘合了資源與應用層，使用者隻需要把鏡像配置到EDAS，提供标準化的主機即可以得到一個可供EDAS管理的單元，而鏡像是由DockerFile生成，本身是标準化的，可讀的且可被版本化的。

同樣，ECS應用也可以借鑒這種思路，首先需要一個資訊載體來實作标準化的環境初始化過程。我們可以使用cloud-init來實作這樣的功能，現在主流的雲計算廠商都支援cloud-init，阿裡雲自然不例外。使用cloud-init，無論是通過DSL或是普通shell，都足以勝任環境初始化的任務。

阿裡雲更進一步，提供了更強大的資訊載體——啟動模闆，在啟動模闆中不僅可以定義cloud-init所需的User-Data，還可以填寫完整的主機規格，進而實作從0開始生成完整的可供部署的環境，這是使用容器鏡像都無法做到的。是以我們推薦使用者使用啟動模闆功能，對于不同的應用分别建立對應的啟動模闆，EDAS也實作了與啟動模闆的無縫對接，比如在建立應用，擴容，彈性伸縮等場景下，EDAS都支援使用者配置啟動模闆來作為建立資源藍本，來提升使用者建立資源效率。

談到環境，使用者往往還面臨一個相關的問題，即處理共享資源。雖然Shared nothing架構可以提供更好的擴充性和更高的穩定性，但對于一個既存系統，改造可能意味着投入和風險，使用者可以通過使用cloud-init在換初始化時完成共享資源配置，比如挂載NAS盤等，這也不失為一種務實的方案。

注意，這裡并沒有使用時下熱門的Infrastructure As Code概念，标準化并不等于IaC，通過标準化可以解決脆弱腳本的問題，但并不苛求純粹的“代碼化”。

cloud-init

https://cloudinit.readthedocs.io/en/latest/topics/format.html https://help.aliyun.com/knowledge_detail/49121.html

啟動模闆**

https://help.aliyun.com/document_detail/73916.html

實踐2：按需取用，按量付費

雲計算提供的價值很大部分來源于彈性。通過彈性，雲可以将相對固定的資源，動态的配置設定給相對易變的處理需求，在業務高峰期保證服務品質，在低谷期節省運作成本，這是使用傳統手段很難做到的。

彈性即按需取用，不妨拆開來看“按需”和“取用”，什麼是“需”？需求是來自業務的，最直接的需求是來自人的決策，除此之外，需求往往還可以通過一些運作名額來回報，與人的決策互相補充。對于需求，其準确性是非常重要的，如果将系統分為資源，應用和服務層來看，服務層因為最接近業務，是以其名額往往具備更強的參考性。其次，什麼是“用”？用的主體自然是應用，用的過程其實就是将資源調配至需求産生的應用的過程，而對于排程，速度則是至關重要的。

EDAS對于ECS資源的排程支援來源于阿裡雲的ESS服務，建立資源時，支援ECS啟動模闆功能，對于一個使用典型啟動模闆的應用，EDAS在2分鐘左右即可實作資源和應用的擴容過程。EDAS可參考資源或服務的壓力進行彈性觸發，使用者配置好規則後，完全不需要人工幹預。使用者也可以通過多可用區分布政策來實作資源在多個可用區間均勻配置設定，擷取更高的可用性。

除了由系統觸發的彈性伸縮，使用者在人工建立應用或者擴容應用時，同樣也可以使用啟動模闆，而無需切換到ECS控制台操作，指定執行個體數量後，由EDAS負責驅動ESS和ECS來完成資源的建立過程。

彈性對使用者産生的價值離不開按量付費模式，EDAS為使用者建立的資源均為按量付費模式（使用啟動模闆還支援建立搶占式執行個體），EDAS會為按需建立的主機做上标記，當應用被銷毀，或執行個體被縮容後，資源也将會随之被回收，使用者隻需要為執行個體服務期間的用量付費即可；如果使用者不希望EDAS徹底釋放掉資源，在建立資源時使用“停機回收”政策，在觸發資源釋放時，EDAS會為使用者保留下磁盤資料，在ECS控制台重新開機主機即可，這樣做也隻需要使用者支付存儲所産生的很少部分的費用，避免了相對昂貴的處理資源浪費。

ESS

https://www.aliyun.com/product/ess

按量付費

https://help.aliyun.com/knowledge_detail/40653.html

實踐3：關于安全

因為雲最大化了資源的共享，是以安全也變成了比以往更重要的話題。對比容器化的應用，ECS應用因為少了容器的層次，隔離相對徹底，但關于安全仍然需要注意很多問題，這裡提醒兩個方面：

在進行主機登入認證時，EDAS推薦使用者使用主機密鑰對。密鑰的複雜程度遠高于密碼，不存在被枚舉的風險，同時非對稱密鑰的機制也保證了使用者不需要将私鑰通過任何網絡傳輸給任何目标，原理上不存在傳輸的洩露可能。是以當使用者選擇在EDAS建立資源時，使用密鑰總是推薦的或者唯一的選擇。

而對于主機之間或者主機與雲産品之間的通路控制，推薦使用安全組。使用雲往往意味着資源的生命周期被縮短，資源就像“細胞”一樣，快速産生并被替代，這時基于ID（IP）的通路政策就會顯得捉襟見肘，可維護性變差，是以雲廠商引入了“角色”來将身份标記與規則配置解耦，這種角色就是安全組。目前，安全組在阿裡雲已經廣泛使用于各個産品，比如使用者可以在啟動模闆中很友善的配置安全組；比如在RDS中，使用者可以将需要被控制RDS執行個體添加到一個安全組，并通過配置此安全組規則，實作控制該執行個體與其他安全組内資源通路的目的。被EDAS使用的啟動模闆也要配置安全組，通過這些模闆啟動的執行個體會歸屬于确定的安全組，這與使用阿裡雲ECS服務來建立資源的要求是一緻的，使用者也可以通過配置安全組規則來控制這些執行個體的通路權限。

密鑰對

https://help.aliyun.com/document_detail/51792.html

安全組

https://help.aliyun.com/document_detail/101348.html

實踐4：開放API

有一個觀點：對使用者而言，業務邏輯和資料永遠是皇冠上的明珠，應用程式和基礎設施隻是載體。其實除了業務，還有另外一顆明珠，雖不放射奪目光彩但也被使用者視若珍寶，那就是流程。

流程的背後是“人”，比如團隊組織，知識倉庫甚至使用習慣，更特定一些，這些人就是“開發者”。程式可以改變人與機器的邊界，機器與機器的邊界，人也同樣也可以；而且由于人是各異的，以現有的技術還不足以制定出同時讓所有人都滿意的流程，是以人必然還會要介入流程的制定。

是以對于像EDAS類似的管理平台而言，在維持功能内聚的前提下留給開發者定制的能力是至關重要的。這些能力，EDAS都通過開放API提供出來，使用者可以通過使用API來完成控制台相同的功能，将EDAS操作串接起來，編排自身所需要的流程。

EDAS的開放API是阿裡雲的OpenAPI的一個子集，在OpenAPI的體系下，EDAS不僅有API，還有支援多種開發語言的SDK以及指令行工具CLI，友善開發者選擇。同時，EDAS與Alibaba Cloud Toolkit也做了深度整合，在IDE内即可完成EDAS應用的釋出等常用功能。

使用開放API并不局限于管理ECS應用，本文不展開介紹，API給了開發者發揮的空間，大家可以通過探索下面的文檔擷取更多靈感。

API / SDK / CLI

https://help.aliyun.com/document_detail/62038.html

Cloud Toolkit

https://www.aliyun.com/product/cloudtoolkit

結語

本文其實側重于ECS應用的資源管理，不包含服務和應用資料管理的等相關内容，是以并不足以覆寫“應用管理”的全部内容，當然，EDAS的功能也不局限于文中介紹的部分，之是以提煉出這些優化實踐，皆因ECS應用在資源管理上的特殊性，而EDAS旨在幫助使用者更高效的将合适的技術運用于解決實際問題，保證使用者盡可能少的被技術（ECS應用）本身的短闆所困擾，同時規避全面架構改造所帶來的不可控性。

另一方面，文中推薦的實踐都不是EDAS特有的技術，EDAS隻是将這些雲計算的工具集做了融合，通過平台整合讓使用者更容易了解并使用，這些工具中既有阿裡雲提供的，也有來自開源社群的。這樣做的好處顯而易見：阿裡雲的專業服務可以保證技術的優勢，而開源給了使用者不被鎖定，平滑遷移的能力，這兩者都可以給使用者提供獨特價值。

在雲時代，技術日新月異，理念層出不窮，降低技術的落地成本并保持開放，這是EDAS與使用者的共同努力的方向，在雲計算的浪潮中避開暗礁和蜃景，與使用者一起探究雲的本質，攫取更多寶藏，ECS應用管理實踐就是其中一個例子。

本文作者：三未，阿裡巴巴技術專家，目前負責分布式應用服務的開發工作。