前言
即使在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應用管理實踐就是其中一個例子。
本文作者：三未，阿里巴巴技術專家，目前負責分佈式應用服務的開發工作。