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應用管理實踐就是其中一個例子。

 

原文連接 更多技術乾貨 請關注阿里云云棲社區微信號 ：yunqiinsight