一、關於ECI
背景從2018年正式發佈，ECI已經打磨了整整4個年頭，如今也已經快速成長爲了阿里雲serverless容器的基礎設施，服務着阿里內外衆多的公有云客戶與雲產品，每天承接着數百萬的彈性容器創建。
然而，ECI這些年卻未參與到集團雙十一大促，雙十一可以說是阿里技術人的閱兵，能不能承接住雙十一的流量成爲了檢驗一個產品是否穩定可靠的重要標準。但一切都是水到渠成，就在今年，ASI開始與ECI對接，嘗試讓ECI承接雙十一大促的彈性的30W覈算力，我們都知道雙十一大促對於整個阿里集團的意義，使命將至，我們必將全身心地投入到對接、壓測、護航的工作中。經過長達兩個多月的業務適配、壓測、備戰，最終完成了雙十一大促的彈性容器的圓滿交付。這背後，離不開ASI、ECI以及參與到其中的每一位腳踏實地、用心鑽研、保駕護航的同學的努力。ECI今年首次作爲集團大促彈性基礎設施，根據線上數據統計，大促期間ECI彈性資源使用共計約400W核，從資源的瞬時彈性、保有規模、系統穩定性等多方面對雲原生系統都是一次巨大的考驗。作爲底層的計算單元，ECI此次也成功頂住了雙十一彈性流量洪峯的考驗，在感嘆serverless、容器這些技術發展迅猛的同時，對於全新的系統架構穩定性的考驗也不小。
如今再回過頭來看ECI的第一次雙十一，我們有必要做一次全面的總結，我們爲集團彈性保障做了哪些工作，哪些是將來可以複用的工作，哪些是可以給其他的團隊作爲借鑑的技術和經驗，以及哪些地方還可以做的更好，爲下一次大促做準備。
本文我們將爲大家介紹，ECI這些年在穩定性方面做了哪些工作，以及是如何來爲集團雙十一保駕護航的。
二、遇到的挑戰
大規模併發帶來的穩定性挑戰遇到的最大挑戰首先是大規模併發帶來的。容器保有量增多之後，從容器實例生產方面來看對於雲管控系統是不小的考驗，尤其是對於彈性場景來講，需要在極短的時間進行實例的生產，鏡像的大規模拉取，進而保障容器的成功啓動。
如何能保障實例的大規模成功生產，如何先於線上發現問題，以及即使出現了問題如何第一時間止血並進行故障恢復，這對於集團雙十一期間的業務重保都是尤爲重要的。除此之外，對於公有云環境來講，不能影響到其他的公有云客戶也是需要重點關注的，因此需要具備一套完整的穩定性保障體系以及故障應對方案以確保雙十一期間的業務能夠順利進行。實例生產系統穩定性ECI和ECS共用一套資源調度系統，相對於ECS容忍度爲分鐘級別的應用來講，ECI實例頻繁的創建刪除對調度系統的要求更爲苛刻，對系統容量以及穩定性保障方面提了更高的要求。服務可用性保障ECI安全沙箱由於某種原因異常（OOM/物理機宕機/kernel panic），導致不健康情況。這種情況下，k8s層面如果不從endpoint上摘除這個ECI Pod，會導致請求通過負載均衡依然可以路由到這臺不健康的ECI上，會導致業務請求成功率下降，因此對於集團業務服務可用性保障也是尤爲重要的。
三、ECI穩定性技術建設
穩定性保障從需求收集準備階段開始，雙十一大促持續兩個月之久，爲了配合集團全鏈路驗收，ECI自身的穩定性保障工作也隨之緊鑼密鼓地進行。
穩定性的保障貫穿了整個大促過程，大促前慎重/減少系統變更以排除人爲因素的干擾，敬畏發佈，多次壓測演預案確保系統穩定性，不斷提升系統抵抗力穩定性和系統恢復力穩定性，以保障大促的順利進行，最後通過問題覆盤沉澱出可複製的大客戶重保策略，這對於未經過雙十一實戰演練具有積極的意義。
因此我們梳理出了整個大促期間圍繞穩定性方面做的主要工作，主要包括風險控制、關鍵業務依賴梳理、技術保障、壓測預案、運行時保障、故障運維能力、以及最後的覆盤優化，希望以此能對今後的大促工作作爲指導，並沉澱出穩定性治理的經驗。接下來我們對此次大促涉及到的主要穩定性保障方法以及如何應用進行介紹。
實例生產保障VM複用技術實例生產行爲的保障是集團彈性使用ECI的重中之重。一個典型的實例生產過程如圖所示，ECS和ECI在控制面共用一套管控系統，ECI管控側調用資源調度系統之後會分配計算資源之後會調用pync（阿里雲單機管控組件），進而調用avs(阿里雲單機網絡組件)和tdc(阿里雲單機存儲組件)分別生產網卡與磁盤。在此過程中，對於調用ECS依賴的open api接口較重，在大規模創建刪除場景很快成爲系統瓶頸，此前我們專門針對容器實例高頻創建刪除場景開發了VM複用功能，對於高頻場景刪除容器實例的場景，延遲vm的回收，並複用容器實例的網卡、鏡像、計算資源，降低對管控系統整體的衝擊，以此來保障實例生產系統的穩定性，從此次雙十一的實戰演練效果來看，vm複用取得了很好的效果，管控系統容量整體處於正常水位，保障了集團雙十一實例穩定的彈性能力。
重調度機制對於庫存不足或者遠程服務調用超時等情況，爲了保障實例生產的最終一致性，對於ECI實例生產我們設計了相應的故障處理策略策略，取值如下：fail-back：失敗自動恢復。即Pod創建失敗後自動嘗試重新創建fail-over：失敗轉移。效果等同於fail-backfail-fast：快速失敗。即Pod創建失敗後直接報錯故障處理策略本質上是一種重調度的策略。原生的k8s調度支持重調度，即調度失敗後會將pod重新放入調度隊列等待下次調度，類比k8s的重調度行爲，當eci管控系統收到創建請求的時候，首先會進入一個隊列，然後有個異步定時任務會將創建從隊列中撈起，提交到異步工作流進行實際的資源生產、以及容器的啓動等。即便是結合了多可用區和多規格的優化，異步工作流依然有可能失敗的，比如資源的爭搶、內網ip不足、啓動失敗等，這時候就需要將創建請求再次重回隊列，等待被重新調度生產。
我們目前對於故障處理策略：
1、失敗的任務會一直重試，但是我們會計算每個任務的執行週期，重試次數越多，執行週期越長，以達到退避效果。
2、優先級策略會考慮用戶級別、任務類型、任務上次失敗的原因等因素，優先級高的任務優先提交執行。
3、每次調度失敗的原因都會以標準事件的方式通知到k8s集羣。隊列裏的任務的整個執行流程的狀態機如下：
所有執行失敗的任務都會重新進入隊列，等待被再次調度。由於任務會在任何一步失敗，所以所有生產出來的資源都會回滾，回滾結束後，進入初始狀態。初始狀態的任務會被拉起執行，然後提交到異步生產。如果生產失敗，就會再次回到等待調度的狀態。如果生產成功，任務就結束，到達終態。基於我們的重調度機制，可以極大的減少由於生產系統抖動造成實例生產失敗的情況，對於容器啓動成功率要求高的場景可以保障實例生產的最終一致性，對於容器啓動成功率要求不那麼嚴格的場景可以快速失敗，由上層業務進行處理。
服務容錯降級對於故障場景，系統依賴服務的降級也是十分重要的。大多數進行限流降級的方案主要關注點在服務的穩定性，當調用鏈路中某個資源依賴出現異常，例如，表現爲 timeout，異常比例升高的時候，則對這個資源的調用進行限制，並讓請求快速失敗或返回預設靜態值，避免影響到其它的資源，最終產生雪崩的效果。ECI目前實現了基於歷史日誌自學習進行無損降級、本地cache降級、流控降級3級降級機制框架，ECS/ECI openapi 全面接入，內部依賴200+接口接入，根據每個接口的調用頻率、RT分佈、超時時間設置來單獨分析，選擇合適的降級策略，設置合理的閥值，能讓系統出問題時，智能降級從而進行系統保護。一個典型的降級機制實現過程如圖：
當有非資源類核心API新請求進入，如果歷史緩存數據未過期則直接返回緩存數據，結束業務邏輯反之則請求遠程接口。如果請求成功，返回數據，對數據進行緩存，同時將緩存數據以日誌方式存入sls cache log日誌用於未來降級，結束業務邏輯當遠程請求失敗時觸發降級策略：如果失敗指標（例如指定時間內異常比例）在預設時間窗口內未達到配置的降級策略閾值，則直接拋出相應業務異常，結束業務邏輯如達到降級策略閾值則按以下順序實行降級策略：從sls 緩存日誌查找歷史日誌數據作爲降級返回值，同時將返回值重新寫入緩存，結束業務邏輯如果sls緩存日誌沒有相應日誌則返回：預設靜態值或空值，結束業務邏輯對於一些跟用戶資源無關，更新少，屬於全局參數的服務/接口，以上通用降級策略和方案可能因爲降級規則閾值難以界定而無法有效執行。
針對這些接口採用dubbo異常直接降級的策略涉及到降級或熔斷的條件：自動降級(可選利用Sentinal進行自動降級)： 超時 異常 限流手動開關支持核心非資源api直接進行openapi 本地降級cache 對於嚴重的系統故障，可以將核心幾個describe api進行openapi本地cache，發生故障，或有雪崩出現時，全部切到openapi本地cache，在降級影響面的同時，也能減輕對下層服務的調用壓力來贏取恢復時間。
依賴服務非創建鏈路dubbo或http請求進行本地moc對於幾乎不會頻繁變化的依賴服務，通過每日sls分析進行kv的存儲，當故障發生時，降級爲備用，讓降級影響面趨向於0。其他服務降級機制大分頁流控cache創建類api進行依賴dubbo或http服務降級，異步補償操作類api進行鏈路降級，取消非必需依賴數據庫降級ro庫流量降級隔離 用戶級別流量切到灰度 api級別流量切到灰度/獨立線程池日誌debug及調用鏈路跟蹤使用apicontext實現詳細日誌debug及調用全鏈路跟蹤能力核心api debug日誌建設，支持按用戶開啓debug日誌打印requestId貫穿到dao，支持隨時採樣，及時發現dao異常調用服務依賴降級容錯機制可以在保障服務穩定性的前提上，利用相關接口的歷史緩存數據，基於SLS日誌無損降級，當SLS無數據的時候也可以採用本地靜態數據兜底，構建有效返回值，在服務觸發流控降級熔斷後，大部分用戶不會感知到服務異常。
在內部的多次故障演練中，服務降級機制可以有效保護系統由於發生故障帶來的系統癱瘓。服務可用性保障在傳統的 Kubernetes 集羣中，如果 Node 變得不可用且達到時間閾值，那麼會將 Node 上的 Pod 進行驅逐，重新在其他 Node 上拉起新的 Pod。而在 Serverless 場景下，ECI管控會通過異步檢測機制檢測不健康ECI，修改狀態爲不可用，同時增加導致不可用的事件，告知ECI用戶，之後ECI會通過主動運維的手段治癒不健康ECI，之後觸發控制面將ECI恢復爲Ready狀態，主要過程如圖所示：
處理不健康 ECI 的流程：
恢復 Ready ECI 流程預案&壓測除了技術方面的保障，故障注入、應急預案、壓測演練在穩定性建設中也尤爲重要。在雙十一活動期間我們內部進行了多次壓測演練，對系統中常見的性能瓶頸進行故障注入，用以模擬故障的發生，同時制定應急預案，以此應對故障已經發生時的場景。通過多次的壓測摸高，一方面可以評估系統容量的承載上限，另一方面可以藉此機會進行大規模壓測演練，驗證系統降級方案並對系統穩定性進行評估。預警&監控大促進行時，預警和監控是保證系統運行時穩定性的重要措施。通過監控和預警可以及時發現系統故障，進而快速進行恢復。
四、系統的健壯性
思考沉澱一個健壯的系統不僅需要減少問題的發生，同時要具備故障發現以及故障快速恢復的能力。除了預警和監控，運維能力建設也十分重要。
一個系統的健壯性體現在系統的容量，系統的容錯能力以及系統依賴的各個資源的sla，尤其是在雲上覆雜的資源環境下，由於“木桶效應”，某一項依賴資源的很可能造成整個系統的直接不可用。因此，隨着系統不斷完善，我們需要通過混沌工程等方法來找出當前系統的“弱點”進而對其進行專項優化，進而提升整個系統的健壯性；其二對於系統的故障恢復以及降級能力也很重要，歷史上ECS/ECI管控多次由於單用戶或系統某個環節變慢，導致系統全鏈路雪崩，最終導致P1P2故障，ECS/ECI管控是阿里雲最複雜的管控系統，複雜的業務邏輯，內部系統依賴，非常多的環節出問題都有可能導致全鏈路某個應用雪崩進而全局不可用，因此，對於故障已經來臨時，依賴降級能力能非常有效的保護我們的系統，這也是穩定性建設的一個十分重要的方向。
五、總結
未來展望隨着雙十一最後一波流量高峯結束，ECI順利通過了對阿里人最嚴苛的技術考驗--雙十一，本文圍繞此次參與雙十一活動的經歷做出總結，希望可以爲今後ECI穩定性方面的建設積累經驗，當然，這對ECI來說也僅僅是一步試金石，作爲雲原生時代的基礎設施，ECI任重而道遠，共勉！
本文出品及鳴謝： 柳密、羽雲、景奇、存誠、 煜楓、景止、皓瑜、月懸、佐井、尚哲、湧泉、十刀、 木名、秉辰、易觀、冬島、不物、瀟洛、 懷歡、 嘗君、寒亭、伯琰。
本文爲阿里雲原創內容，未經允許不得轉載。