2023云原生大規(guī)模應用落地指南

推薦序 推薦序 推薦序 4985億交易額的背后，全面揭秘阿里巴巴雙11的云原生支撐 第一章技術體系升 以Kubernetes為代表的容器技術，已成為云計算的新界 Serverless如何落地？揭秘阿里核心業(yè)務大規(guī)模落地實 第二章技術能力突 七年零故障支撐雙11的消息中間件RocketMQ,2020有何不同 阿里雙11同款流控降級組件SentinelGo正式GA，助力云原生服務穩(wěn)穩(wěn) OpenKruise：阿里巴巴雙11全鏈路應用的云原生部署基 第三章雙11云原生實 2020雙11，Dubbo3.0在考拉的超大規(guī)模實 申通快遞雙11云原生應用實 「云原生上云」后的聚石塔是如何應對雙11下大規(guī)模應用挑戰(zhàn) 高德最佳實踐：Serverless規(guī)?；涞赜心男﹥r值 訂單峰值激增230%，Serverless如何為世紀聯(lián)華降本超 >>2211為例，我們將“光棍節(jié)”升級為“雙節(jié)棍”。過去雙11的模式是提早111111IT幫助企業(yè)IT平滑、快速、漸進式地落地上云之路?？梢灶A測,在未來企業(yè)加快數(shù)字化轉型比如今年疫情期間，基于阿里云容器解決方案，釘釘2小時內擴容1支撐2億上班族在線開工；申通快遞將核心系統(tǒng)搬到阿里云上，并進行應用容器化和微服務改造，在日均處理訂單3000萬的情況下，IT成本降低50%；采用了阿里云原生PaaS1050%，支撐訪問量由1000萬上升至1.1億。>>33的云原生客戶群體賦能。在容器、服務網(wǎng)格和Serverless等領域均為企業(yè)提供豐富的技術和產(chǎn)品體系，覆蓋八大類別20余款產(chǎn)品，涵蓋底層基礎設施、數(shù)據(jù)智能、分布式應用IT在2020里巴巴全面云原生化的職責，委員會更加重要的一個責任是將阿里巴巴已經(jīng)沉淀10多年的云原生實踐對外賦能數(shù)百萬家企業(yè)，幫助他們進行云原生改造，提升30%研發(fā)效率的同時降低30%ITDNA。相信在阿里云原生的助推下，“云”KuereteservrlessIT在阿里巴巴我們常說，沒有經(jīng)過雙11檢驗的技術不是成熟的技術。2020年雙11，三大提升，萬筆交易的資源成本4年間下降80%，研發(fā)運維效率平均增效10%以上，規(guī)?；瘧媒桓缎侍嵘?00%?？梢哉f，阿里巴巴在2020雙11完成了全球最大規(guī)與2019年全面云化相比，2020年的“全面云原生化”革命性地重構了雙11“技術引擎”。從產(chǎn)品和技術兩方面來看，產(chǎn)品側，阿里云通過提供容器服務ACK、云原生數(shù)據(jù)庫PolarDB/Redis、消息隊列RocketMQ、企業(yè)級分布式應用服務EDAS、微服務引擎MSE、應用監(jiān)控服務ARMS等百款云原生產(chǎn)品全面支撐雙11支持全球最大容器集群、全球最大Mesh集群，神龍架構和ACK容器的組合，可以實現(xiàn)1小時擴容1百萬個容器，混部利用率提升50%，萬筆交易成本4年下降國內最大計算平臺、頂級實時計算能力。大數(shù)據(jù)平臺批處理單日計算數(shù)據(jù)量達到1.7EB，30億條記錄；PolarDB50%+，計算資源利用率提高60%+。原生中間件服務框架峰值調用量超百億QPS。Serverless10云原生技術不僅在阿里內部大規(guī)模普及，也正通過阿里云服務全社會的雙11。大促期11億級包裹過境，系統(tǒng)穩(wěn)如泰山，IT成本還降低了30%；以大型商超為例，世紀聯(lián)華基于阿里云函數(shù)計算(FC)彈性擴容，業(yè)務峰值QPS超過2019年雙11的230%，研發(fā)效率交付提效超過30%，彈性資源成本減少40%以上。2008分布式、互聯(lián)網(wǎng)中間件，到2011年落地容器化，我們在不斷發(fā)展的過程中看到云原生的致的要求。我們將今年在阿里巴巴雙11 >4985114985261158.3IT80%。這次全球最大規(guī)模的云原生（CloudNative）實踐也引發(fā)了業(yè)界新的思考，在企業(yè)積124985億交易額的背后，全面揭秘阿里巴巴雙11的云原生支撐力 11202058.3可能。2010年“去IOE”，阿里發(fā)展出互聯(lián)網(wǎng)海量交易支付的架構與技術；2015年提出“中臺”戰(zhàn)略，阿里邁向移動化、數(shù)據(jù)化新征程；201711能時代；2019年核心系統(tǒng)100%上云，讓積累多年的雙11技術，通過阿里云實現(xiàn)技術紅從2019“雙11上云”到2020“云上雙11”，阿里核心系統(tǒng)在2020年實現(xiàn)了全面11""ACKolrDB/edisocketQ、DASSEAMS產(chǎn)品全面支撐雙11。技術側，云原生四大核心技術實現(xiàn)規(guī)模和創(chuàng)新的雙重突破，成為從技極致彈性：ACK11Mesh集群。記錄；PolarDB50%+，60%+。QPSServerlessServerless，彈性伸縮能力會提10原生是云計算的再升級，是真正意義的云技術革命，推動從CloudHosting演進到CloudNative，從基于自有、封閉的技術體系，走向標準、開放公共的云技術體系。除了 >498511技術不僅在阿里內部大規(guī)模普及，也正通過阿里云服務全社會的雙11。大促期間，阿里云系統(tǒng)穩(wěn)如泰山，IT30%；以大型商超為例，世紀聯(lián)華基于阿里云函數(shù)計算(230%彈性資源成本減少40ASK（AlibabaCloudServerlessKubernetes）容器服務靈活調度AI模型訓練時的計算資源，可縮短了60%的模型測試時間，并在完成測試之后可以快速釋放算力，極大節(jié)約了繼2020年9月云棲大會上阿里巴巴宣布成立云原生技術委員會，云原生升級為阿里技術新戰(zhàn)略。2020雙11核心系統(tǒng)全面云原生化，成為云原生技術委員會推動阿里巴巴全 11都是一場“盛宴”。為了讓顧客有順滑的購11的驅動下成倍提高，激發(fā)著技術人的潛力。作為基礎技術核心之一，阿里中間件11迎來一次技術的全面演進和升級。2019年完成了全站的核心系統(tǒng)上云，對于阿里中間件來講，這是一個意義非2011Dubbo開源開始，阿里中間件就已經(jīng)嘗試在云產(chǎn)EDAS產(chǎn)品線，希望能夠把阿里在微服務和應用托管體系的實踐經(jīng)驗分享給用戶；與此同時，阿里云還在開源社區(qū)中推出了Dubbo、11的技術紅利發(fā)揮到極致?；诩瘓F場景，沉淀SpringCloudAlibaba全家桶，形成微服務HSFDubboMSE提供的服務發(fā)現(xiàn)和流量治理能力，輕11大促中，考拉核心鏈路上的數(shù)百個應用運行在Dubbo3.0這個版本上。acos與ub/SringCludAliba018開源戰(zhàn)略的推進，阿里云以10年雙11沉淀的注冊中心和配置中心為基礎開源了Nacos，以簡單易用、性能卓越、高可用、特性豐富等核心競爭力快速成為領域首選。并且跟阿里ub/SringCludAliba2020年，隨著阿里全站上云的全面推進，阿里云將阿里巴巴內部注冊中心和配置中心用Nacos重構完成，并以云產(chǎn)品MSE支撐了淘寶、餓了么、考拉等核心BU平穩(wěn)度過雙11。了生態(tài)和標準，憑借MSE、EDAS等云產(chǎn)品完成產(chǎn)品化和能力輸出。基于此，阿里云中SpringCloudAlibaba阿里云Prometheus監(jiān)控服務，提供了水平擴展能力，平均查詢30以上的基石。Prometheus是CNCF下第二個畢業(yè)的項目，已成為云原生可觀測領域的事實標準之一。如何將開源Prometheus的優(yōu)秀生態(tài)與技術架構與阿里云原生基礎設施進行11期間我們見證了這一目標的實現(xiàn)，阿里云Prometheus服務成功為眾多大規(guī)模在線業(yè)務保駕護航，幫助業(yè)務系統(tǒng)順利相比于自研的監(jiān)控體系，阿里云Prometheus服務與云生態(tài)有更緊密的集成，實現(xiàn)了與托管類產(chǎn)品底層API的深度集成與聯(lián)動。外部用戶也無需顧慮運維Prometheus數(shù)據(jù)采集與上報，以極低的遷移成本將自建Prometheus遷移到阿里云的Prometheus服務上。相比于開源版本的Prometheus，阿里云的Prometheus為了應對阿里的大規(guī)30%以上。釘釘視頻會議在今年基于ASK實現(xiàn)了全球系統(tǒng)的全量容器化，采用云原生Serverless流量特征所帶來的特殊資源彈性訴求。阿里云Prometheus服務針對ASK集群特性做了一系列定制，實現(xiàn)了無損的Serverless指標采集能力，以及釘釘視頻會議整個ServerlessPrometheus指標數(shù)據(jù)的自動彈性能力。基于RocketMQ的消息產(chǎn)品家族無縫快速上云，擁抱標準，引領RocketMQ是阿里巴巴在2012年開源的第三代分布式消息中間件，并在2017年正式成為Apache頂級開源項目。在阿里巴巴內部，RocketMQ一直承載著阿里巴巴11萬億級消息洪峰的嚴苛考驗。隨著阿里全站上支撐阿里巴巴、阿里云產(chǎn)品以及開源社區(qū)需求。通過三種截然不同場景的打磨，RocketMQ可以幫助用戶無縫快速上云。RocketMQ開源社區(qū)中的一大批生態(tài)項目可以快速在阿消息服務。三位一體技術融合使得RocketMQ不僅讓阿里成熟穩(wěn)定的技術能夠服務外部憂。繼今年9月云棲大會上阿里巴巴宣布成立云原生技術委員會，云原生升級為阿里技術新戰(zhàn)略。202011核心系統(tǒng)全面云原生化，成為云原生技術委員會推動阿里巴巴全面云11 >以Kubernetes以Kubernetes為代表的容器技術，已成為云計算的新界面以Kubernetes為代表的容器技術，已成為云計算的新界面 以Kubernetes為代表的容器技術，已202011，阿里核心系統(tǒng)實現(xiàn)了全面云原生化，扛住了史上最大流量洪峰，向業(yè)其中非常關鍵的一點是80%核心業(yè)務部署在阿里云容器ACK上，可在1小時內擴展可以說，以Kubernetes為代表的容器技術正成為云計算新界面。容器提供了應用分發(fā)和交付標準，將應用與底層運行環(huán)境進行解耦。Kubernetes作為資源調度和編排的標準，屏蔽底層架構差異性，幫助應用平滑運行在不同基礎設施上。CNCFKubernetes的一致性認證，進一步確保不同云廠商Kubernetes實現(xiàn)的兼容性，這也讓更多的企業(yè)愿意作為容器編排的事實標準，Kubernetes支持IaaS層不同類型的計算、存儲、網(wǎng)絡等能力，不論是CPU、GPU、FPGA還是專業(yè)的ASIC芯片，都可以統(tǒng)一調度、高效伴隨著Kubernetes成為新操作系統(tǒng)的事實，以云原生容器為主的技術，已經(jīng)成為云計統(tǒng)一技能棧降低人力成本：Kubernetes可以在IDC、云端、邊緣等不同場景進行統(tǒng)一部署和交付，通過云原生提倡的DevOps文化和工具集的使用有效提升技術迭代速度，統(tǒng)一技術棧提升資源利用率：多種計算負載在Kubernetes集群統(tǒng)一調度，可以有效提升資源利用率。Gartner370%AI任務運行在容器和ServerlessAI模型訓練和大數(shù)據(jù)計算類工作負載更加需要Kubernetes提供Serverless的彈性可以簡化對計算任務的容量規(guī)劃。結合分布式緩存加速（比如Alluxio或阿里云Jindofs）和調度優(yōu)化，也可以大大提升數(shù)據(jù)計算類和AI任務的計算效率。IntelSGX等加密計算技術，阿里云為云上客戶提供了的技術焦點。Kubernetes具有強大的容器編排、資源調度能力，可以滿足邊緣/IoT場景算交叉領域的協(xié)同發(fā)展，阿里巴巴于2020年5月正式對外開源邊緣計算云原生項目OpenYurt，推動“云邊一體化”概念落地，通過對原生Kubernetes進行擴展的方式完“零”侵入的邊緣云原生方案：提供完整的Kubernetes兼容性，支持所有原生工作負載和擴展技術（Operator/CNI/CSI等）；可以輕松實現(xiàn)原生Kubernetes集群一鍵轉化為OpenYurt集群。2019年KubeCon上阿里云發(fā)布邊緣容器服務ACK@Edge，OpenYurt正是其核心框架。短短一年，ACK@Edge已經(jīng)應用于音視頻直播、云游戲、工業(yè)互聯(lián)網(wǎng)、交通同時，作為ACK@Edge的開源版本OpenYurt，已經(jīng)成為CNCF的沙箱項目，推動Kubernetes上游社區(qū)兼顧邊緣計算的需求，歡迎各位開發(fā)者一起共建，迎接萬物智聯(lián)的ITKubernetes可以向上支持眾多開源主流框架構建微服務、數(shù)據(jù)庫、消息中間件、大AIKberetsevps時的組件要改為支持KubernetesPod下的新模式，容器內日志、監(jiān)控等各類運維組件在計算、網(wǎng)絡、存儲方面，用戶通過Kubernetes的統(tǒng)一管理，可以充分利用阿里云的IaaS能力，讓每個業(yè)務擁有自己獨立的彈性網(wǎng)卡和云盤，對網(wǎng)絡和存儲性能有著高低在節(jié)點資源層，用戶可充分利用Kubernetes的底座擴展能力，讓節(jié)點管理實現(xiàn)云原新興的生態(tài)和業(yè)務，基于ACK（阿里云容器服務）提供的云原生土壤，如ServiceMesh、Serverless、Faas等，也非常快速地在集團內落地，并得到蓬勃發(fā)展。在應用PaaS層，云原生的應用交付模式走向了更為徹底的容器化，充分利用了Kubernetes的自動化調度能力，基于OAMTrait的標準定義來構建集團內統(tǒng)一的PaaSGits研發(fā)模式讓基礎設施和云資源代碼化、可編程。在過去十年，阿里集團內的容器技術，經(jīng)歷了從自研LXC（LinuxContainer）容器T4，到富容器，再到Kubernetes云原生輕量級容器的演進歷程。每一次轉變升級，都第一階段：基于LXC的容器T4嘗試受困于虛擬機KVM的巨大開銷，以及KVM編排管理的復雜度，阿里集團在2011年時發(fā)起對LXC和LinuxKernel的定制，在內部上線了基于LXC的T4容器。但相比后面出現(xiàn)的Docker,T4容器在技術上存在一些不足，比如沒有實現(xiàn)鏡像提取和應用描述。T4誕生后的多年，阿里持續(xù)嘗試在T4之上構建復雜的基線定義，但屢屢遭遇問第二階段：引入容器鏡像機制的AliDocker2015年，阿里引入Docker的鏡像機制，將Docker和T4的功能取長補短互相T4DockerDockerT4過程中，阿里引入P2P鏡像分發(fā)機制，隨著電商核心應用逐步全面升級到化的P2P鏡像分發(fā)是2018年10月加入CNCF的Dragonfly。第三階段：完全自主產(chǎn)權的容器Pouch隨著容器技術的規(guī)模化鋪開，AliDocker化的優(yōu)勢得以體現(xiàn)，阿里完全自主產(chǎn)權的Pouch得以展開并逐漸替代AliDocker。同時，阿里集團100%Pouch化也一直在快速推進，201611前，已經(jīng)實現(xiàn)了全網(wǎng)的容器化。Pouch寓意是一個神奇的育兒袋，為里面的應用提供貼心的服務。因為Pouch統(tǒng)一底層基礎設施發(fā)生了云化、混部、網(wǎng)絡VPC化、存儲無盤化、內核升級、調度系統(tǒng)升級等各種技術演進，但Pouch容器運行時使絕大部分底層變化對應用無感知，屏蔽了對上開源社區(qū)，同時集團也逐步將過去的存量AliDocker實例無縫切換為開源的Pouch實進。例如：Serverless第四階段：調度系統(tǒng)兼收并蓄及ACK的演進隨著以Kubernetes為代表的容器技術成為云計算的新界面，阿里自研的im也在持續(xù)探索Kubernetes的落地實踐，并借助集團全面上云的契機，最終實現(xiàn)了從igma管控到ACK的全面遷移。2018年，集團調度系統(tǒng)開始了從內部定制的igma到ACK的逐步演進，容器輕化容器的解決思路是用Kubernetes的Pod來拆分容器，剝離出獨立的運維容器，并將igma誕生之初致力于將阿里集團眾多割裂的在線資源池整合統(tǒng)一，在此基礎上，不全托管免運維imaMaster、公共大資源池、應用額度服務，提供Serverless的資源交付和最佳的用戶體驗。imT4到Pouch的全面容器化進程，通過應用研發(fā)自定義的Dockerfile標準化容器，以及透明化基礎設施的im調度引擎，從igma到ACK的升級，是希望ACK領先的云產(chǎn)品能力得以賦能阿里集團，使得im可以加速享受云計算的能力，包括異構資源的統(tǒng)一管理、面向全球化的安全合規(guī)等。但實際上，遷移ACK的過程并非一帆風順：其次，性能、多集群運維、安全防御、穩(wěn)定性等眾多問題，都是全面遷移ACK的挑戰(zhàn)。圍繞著性能，阿里基于原生Kubernetes做了非常多的優(yōu)化并回饋給社區(qū)，如CacheIndex、WatchBookmarkKubernetes=ACK+ACK過程中的積累又能沉淀給云，豐富產(chǎn)品能力，幫助客戶形成云上的競爭力。至此，阿以Kubernetes為代表的容器技術，已成為云計算的新界面以Kubernetes為代表的容器技術，已成為云計算的新界面 >以Kubernetes開源側的挑戰(zhàn)和機遇：阿里云在云原生開源項目貢獻中有著持續(xù)投入，推出了Kri、聯(lián)合微軟推出OAM、KubeVela等開源項目，這些都源于阿里巴巴在云peKuKubernetesKubernetes開發(fā)者和阿里云上的用戶都能便Kubernetes原生workload不滿足的困境時，企業(yè)內部不需要重復造一套相似的“輪子”，而是可以選擇使用OpenKruise的成熟能力。而且，阿里集團內部使用的與enKruie建設的云原生愛好者，共同打造了這個更完善、普適的云原生應用負載引IaaS2015年上線來，伴隨SLAACKPro，并同樣支撐了阿ACKPro版，針對金融、大型互聯(lián)網(wǎng)、政企客無損Terway容器網(wǎng)絡，簡化數(shù)據(jù)鏈路，相比路由網(wǎng)絡延遲下降30支持全球首款持久性內存實例，相比NVMe，I/O密集應用TPS提升100%。CPUSLA和密度的前提下，WebQPS30%支持GPU算力共享,AI模型預測成本節(jié)省50以上。30%ASMIstio容服務網(wǎng)格ASMASM可以實現(xiàn)多種異構應用服務統(tǒng)一治理，提供了對云上虛擬機，IDC應用等異構服務的統(tǒng)一管理，提供全鏈路可觀測性和端到端安全防護。幫助您加速企業(yè)應用的現(xiàn)代化改造，輕松構建混合云IT架構。阿里云容器服務連續(xù)兩年國內唯一進入Gartner《公有云容器服務競爭格局》報告；Forrester首個企業(yè)級公共云容器平臺報告中，阿里云容器服務位列StrongPerformer,中國第一。Serverless、新一代的中間件、新一代的應用PaaS方興未艾。 >ServerlessServerless如何落地？揭秘阿里核心業(yè)務大規(guī)模落地實現(xiàn)<Serverless如何落地？揭秘阿里核心業(yè)務大規(guī)模落地實現(xiàn)< Serverless如何落地？揭秘阿里核心業(yè)020全面提升效率的今天，幾乎無人否認背負“降本增效”使命誕生的Serverless即將成為云時代新的計算范式。Serverless將開發(fā)者從繁重的手動資源管理和性能優(yōu)化中解放出ervrles傳統(tǒng)項目如何遷移到Serverless，同時保障遷移過程業(yè)務連續(xù)性，在Serverless架構下如何提供完善的開發(fā)工具、有效的調試診斷工具，如何利用Serverless做更好的節(jié)約成本等，每一個都是難題。尤其涉及到在主流場景大規(guī)模的落地Serverless，更是并非ervrles總交易額98283萬筆/秒，020年天貓雙11對于阿里云來說，今年的雙11還有另一個意義，阿里云實現(xiàn)了國內首例Serverless在核心業(yè)務場景下的大規(guī)模落地，扛住了全球最大規(guī)模的流量洪峰，創(chuàng)造了erverless落Serverless落地之痛快彈是Serverless天然自帶的屬性，但是快彈的條件是要有極致的冷啟動速度去支場景，延時超過500毫秒已經(jīng)會影響到用戶體驗。雖然Serverless利用輕量化的虛擬技術，不斷的降低冷啟動，甚至某些場景能降低到200毫秒以下。但這也只是理想的獨立ServerlessServerless場景下實例生命周期短、進行網(wǎng)絡連通優(yōu)化，同時對調用鏈路進行監(jiān)控數(shù)據(jù)打通，幫助SRE（SiteReliabilityEngineer）從業(yè)者更好的評估函數(shù)的下游中間件依賴情況，對于核心應用遷移上Serverless非常重要。標，還需要檢查業(yè)務所在系統(tǒng)的資源指標，但是在Serverless場景中沒有機器資源的概然后登陸進行調試。而在Serverless場景中沒有機器層面的概念，所以如果用戶想登陸機器，在現(xiàn)有的Serverless基礎技術之上是很難做到的。當然原因不僅限于此，比如Vendor-lockin的擔心等。上面幾大類痛點的概括，主要是針對開發(fā)者的開發(fā)體驗，對于實對Serverless還是持有觀望狀態(tài)，當然也不乏一些質疑觀點，“FaaS只適合小業(yè)務場Serverless11“大考”201912O'ReillServerless40的受訪者所在的組織采用了Serverless。2020年10月，中國信息通信研究院發(fā)布的《中國云原生用戶調研報告》指出：“Serverless技術顯著升溫，近30%的用戶已在生產(chǎn)環(huán)境中應用?！?020ServerlessServerless規(guī)模化落地核心場景的案例。面對Serverless開發(fā)者數(shù)量的穩(wěn)步增長的現(xiàn)狀，阿里巴巴11技術煉金爐”把阿里云Serverless打為例，每萬筆峰值交易的IT80%。Serverless也迎來了首次在雙11場景一:2020雙11，阿里巴巴集團前端全面擁抱云原生Serverless，淘系、飛豬、高德、CBU、ICBU、優(yōu)酷、考拉等十數(shù)BU，共同落地了以Node.jsFaaS在線服務架構為11在保障穩(wěn)定性、高資源利用率的前提下，多BU重點營銷導購場景實現(xiàn)了研發(fā)模式升級。前端FaaS支撐的云端一體研發(fā)模式交付平均提效38.89%。依托Serverless11會場頁面快捷落地SSR技術，提高了用戶頁面體驗，除了保障大促以外，日常彈性下也較以往減少30%計算成本。Serverless天然的彈性伸縮能力，是“個性化推薦業(yè)務場景”選擇由Serverless實現(xiàn)的最重要原因，數(shù)以千計的異構應用運維成本一直是這個場景下的痛點。通過Serverless化進一步釋放運維，讓開發(fā)者專注于業(yè)務的算法創(chuàng)新。目前這個場景的應用范圍越來越廣，已經(jīng)覆蓋了幾乎整個阿里系APP：淘寶，天貓，支付寶，優(yōu)酷，飛豬等等，源利用率達到了60%.202011基于阿里云函數(shù)計算(FC)彈性擴容，在大促會場SSR、線QPS201911230%，30%，彈性資源成本減少40%以上。當然，適用于Serverless的場景還有很多，需要更多行業(yè)的開發(fā)者們共同豐富?？侳aaS11大促中，不僅承接了部分核心業(yè)務，流量也突破新高，幫助業(yè)務扛住了百萬QPS的流量洪峰。阿里云如何擊破Serverless痛點？erverles+019年的ervrless0持了預留模式，接著AWSLambda幾個月后，也上線了類似的功能。為什么阿里云會率先提出這個問題？阿里云Serverless團隊不斷探索真實業(yè)務的需求，按量模式的按需一個非常典型的業(yè)務曲線圖，用預留模式方式滿足底部固定的量，用彈性能力去滿足burst的需求。針對burst擴容，我們利用兩種擴容方式結合進行滿足：按資源擴容與CU0%，當實例的CU達到3置，那么先滿足的條件會先觸發(fā)擴容。通過豐富的伸縮方式，阿里云函數(shù)計算解決了ervrlesServerless用戶需要經(jīng)過CI測試，日常測試，預發(fā)測試，灰度部署等幾個流程驗證，才能確保函數(shù)的質量。這些流程是阻礙核心應用使用FaaS的絆腳石。針對于這個問題，阿里云函數(shù)計算的策略是"被集成“，把研發(fā)平臺的優(yōu)勢與阿里云函數(shù)計算進行結合，既能滿足用戶的CI/CD流程，又能享受到Serverless的紅利，幫用戶跨過使用FaaS的鴻溝。阿里集團內部通過暴露標準的OpenAPI與各個核心應用的研發(fā)平臺進行集成，經(jīng)過雙十一業(yè)務研發(fā)的驗證，研發(fā)效率大大提高了38.89%。在公有云上我們與云效平臺集成，把研發(fā)流程與FaaS結合的更緊密、更順暢，幫助集團外的業(yè)務提高人效。合？傳統(tǒng)應用開發(fā)需要集成各類中間件的SDK，進行打包上線，但對于Serverless的計算經(jīng)過兩個階段的發(fā)展，第一個階段我們通過搭建中間件Proxy,通過Proxy去打通中間件，函數(shù)只用單一的協(xié)議與Proxy進行交互，從而offload掉中間件的SDK的包令下發(fā)，流量管理，配置拉取等等，期間阿里云擁抱了開源組件Dapr，利用Sidecar的方式Offload中間的交互成本。上述的方案，是基于阿里云函數(shù)計算的Customune以及CustomContainer功能完成的。能力。阿里云函數(shù)計算同時啟動了不同的攻關小組，首先與Tracing/ARMS結合，打造LS行自定義，并且擁抱開源產(chǎn)品Prometheus暴露出資源利用率，支持遠程調試能力的WeDEervrles-dvs幫助開發(fā)者在Serverless架構下實現(xiàn)開發(fā)/運維效率翻倍的開發(fā)者工具。開發(fā)者可以簡ServerlessServerless首先，阿里云提供了所有云廠商中最完整的Serverless產(chǎn)品矩陣，包括函數(shù)計算FC、Serverless應用引擎SAE、面向容器編排的ASK、以及面向容器實例的ECI能力和百毫秒伸縮的極致彈性；而針對微服務應用，Serverless應用引擎能做到零代碼改造，讓微服務也能享受Serverless紅利。其次，Serverless是一個快速發(fā)展的領域，阿里云在不斷拓展Serverless的產(chǎn)品邊界。例如函數(shù)計算支持容器鏡像、預付費模式、實例內并發(fā)執(zhí)行多請求等多個業(yè)界首創(chuàng)的功能，徹底解決了冷啟動帶來的性能毛刺等Serverless難題，大大拓展了函數(shù)計算的應用場景。最后，阿里巴巴擁有非常豐富的業(yè)務場景，可以進一步打磨Serverless的落地實踐。今年阿里巴巴的淘系、考拉、飛豬、高BU1111Serverless引領下一個十年動分工越來越細，物理機托管時代已經(jīng)成為了歷史，被成熟的aaS層取代，隨之而來的是容器服務，目前也已經(jīng)是行業(yè)的標配。那么，接下來的技術十年是什么呢？答案是：Serverless，抹平了研發(fā)人員在預算、運維經(jīng)驗上的不足，在對抗業(yè)務洪峰的情況下，絕率，線上預警、流量觀測等工具一應俱全，輕松做到了技術研發(fā)的免運維，可以說ervrles此大大提高了勞動生產(chǎn)力，這就是“斯密定理”效應，也是Serverless成為未來必然趨勢的內在原因。當下，整個云的產(chǎn)品體系已經(jīng)Serverless化，70%以上的產(chǎn)品都是erverless形態(tài)。對象存儲、消息中間件、AI網(wǎng)關、表格存儲等erverless產(chǎn)品已下一個十年，Serverless1111的消息中間件RocketMQ,2020有何不同？< >七年零故障支撐雙11RocketMQ,2020七年零故障支撐雙11的消息中間件RocketMQ,2020有何不同？202058.3WRocketMQ0故障絲般順滑地完美支持了整個集團大促的各類業(yè)務平穩(wěn)。今年雙十一大促中，消息中間件RocketMQ發(fā)生了以下幾個方面的變化：kubernetes30%Kubernetes作為目前云原生化技術棧實踐中重要的一環(huán)，其生態(tài)已經(jīng)逐步建立并日益豐富。目前，服務于集團內部的RocketMQ集群擁有巨大的規(guī)模以及各種歷史因素，因201616RocketMQ的部署過的工程里寫自己的業(yè)務代碼，確實也是一個不太友好的實現(xiàn)方案，因此我們希望通過Kubernetes來實現(xiàn)消息中間件自己的operator。我們同樣希望利用云化后云盤的多副本CRDoperatorKubernetesIaasOperator承擔了所有的新建集群、擴容、縮容、遷移的全部邏輯，包括每個pod對應的brokerName自動生成、配置文件，根據(jù)集群不同功能而配置的各種開關，元數(shù)據(jù)的operatorreplicaKubernetes要求，這種部署模式在Kubernetes的體系下是并不提倡的。若依然采用以上老的架構方式，會導致實例控制的復雜性和不可控性，同時我們也希望能更多的遵循Kubernetes的ECS了保障。并且高速云盤在性能上完全滿足MQKubernetes（包含宕機引起的掛掉），broker上圖是Kubernetes上線后雙十一大促當天的發(fā)送RT統(tǒng)計，可見大促期間的發(fā)送RTRocketMQ0故障支持集團的雙十一大促。自從RocketMQ誕生RocketMQ上，并同時充分RocketMQ消息中間件的各類特性。RocketMQSQL過濾。RocketMQCPU過濾計算邏輯，交易集群都是大促中機器成本增長最大的地方。MessageType==xxxx翻看aviator的源碼可以發(fā)現(xiàn)這樣的條件最終會調用Java的字符串比較oo由于交易消息包括大量不同業(yè)務的MessageType，光是有記錄的起碼有幾千個，隨著交易業(yè)務流程復雜化，MessageType的增長更是繁多。隨著交易峰值的提高，交易消groupgroup快查詢結果，可以選擇MessageType作為一個索引字段進行索引化，每次查詢變?yōu)橄绕essageType主索引，然后把匹配上主索引的記錄再進行其它條件(如下圖的sellerIdtestA)匹配，優(yōu)化流程如下圖所示：如何抽取每個表達式中的MessageType如何對MessageType對于技術點1，需要針對aviator的編譯流程進行hook，深入aviator源碼后，可以發(fā)現(xiàn)aviator的編譯是典型的Recursive descent（/wiki/Recursive_descent_parser)同時需要考慮到提取后父在編譯過程中針對messageType==XXX這種類型進行提取后，把原有的message==XXXtrue/falsetrue、falsemeagepe200-trade-paid-done'&&buyerId==123456（meagepe200-adepa-on）：bueId12462（meagepe!200adepa-on）：faeaviatortokenList，類似如下圖所示(為方便理解，綠方框的是token，其它框表示表達式的具體條件組合)：提取了messageType情況一：messageType=='200-trade-paid-donetokentruebuyerId==123456，具體如下：情況二：messageType!='200-trade-paid-donetokenfalsefalse，具體如下：這樣就完成messageType的提取。這里可能有人就有一個疑問，為什么要考慮到上面的情況二，messageType!='200-trade-paid-done'，這是因為必須要考慮到多個sseyp='0-trade-paid-done'&&buyerId==123456)||-trade-success'&&12HashMap行索引化即可，即把messageType的值作為HashMap的key，把提取后的子表達式作為HashMap的value，這樣每次過濾直接通過一次hash計算即可過濾掉絕大部分不適該優(yōu)化最主要降低了CPU計算邏輯，以三個交易集群為例，優(yōu)化前后的平均cpu使用率對比如下（24c128g）：TRADE-TRADE-TRADETRADE-SUBTRADE-SUB2個交易集群的業(yè)務訂閱方復雜度不同（TRADE-SUBTRADE-SUB2TRADE），理論上只要訂閱關系約復雜優(yōu)化效果越好，因此可以看到TRADE-SUB的優(yōu)化最大，有32的提升。全新的消費模型——POPRocketMQPULLhanghangbrokerrebalancehangBrokerrebalance我們增加了一種新的消費模型——POP消費，能夠解決此類穩(wěn)定性問題。rebalancebrokerPOPbrokerbrokerAckbroker，broker再標記消息消費結果，如果超時沒響應或者消費失敗，再會進行重試。POPBroker對于每次POP然后寫入CK消息，表明獲取的消息要被POPCKPOPCK消息就會重新被broker消費，然后把CK消息的位點的消息寫入重試隊列。如果brokerAckCK從整體流程可見，POP消費并不需要reblance，可以避免rebalance帶來的消費延brokerhang >< 阿11同款流控降級組件SentinelGoGA，助力云原生服務穩(wěn)穩(wěn)穩(wěn)“黑馬”熱點商品擊穿緩存，DBSentinel11Sentinel11峰值流量的穩(wěn)定性，同時SentinelGo版本也在近期正式宣布GA。下面我們來一起了解下SentinelGo的核心場景以及社區(qū)在云原生方面的SentinelSentinel的穩(wěn)定性。Sentinel1011的利器，原生支持Java/Go/C++等多種語言，并且提供Istio/Envoy全局流控支持來為ServiceMesh提供高可用防護的能力。今年年初，Sentinel社區(qū)宣布了SentinelGo版本的發(fā)布，為Go語言的微服務和Sentinel出了新的一步。在這半年的時間內，社區(qū)推出了近10個版本，逐步對齊了核心高可用防SentinelGo1.0版本對齊了Java流量整形、并發(fā)控制、熔斷降級、系統(tǒng)自適應保護、熱點防護等特性。同時Go版本已覆蓋主流開源生態(tài)，提供了n、gRPC、go-mio、dubbo-go等常用微服務框架的適配，并提供了etcd、Nacos、Consul等動態(tài)數(shù)據(jù)源擴展支持。SentinelGo也在朝著云原生的方向不斷演進，1.0版本中也進行了一些云原生方面的探索，包括KubernetesCRDdata-source,KubernetesHPA等。對于SentinelGo版本而言，我們期望的流控場景并不局限于微服務應用本身。云原生基礎組件中Go語言生態(tài)占比較高，而這些SentinelGo來保護自身的穩(wěn)定性。Sentinel底層通過高性能的滑動窗口進行秒級調用指標統(tǒng)計，結合tokenbucket,leakybucket和自適應流控算法來透出核心的高可用防護能力。那么我們如何利用SentinelGo來保證我們微服務的穩(wěn)定性？下面我們來看幾個典型的峰了（11零點的場景）。然而我們系統(tǒng)的容量總是有限的，如果突然而來的流量超過了系統(tǒng)的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load飆高，最后導致系統(tǒng)崩潰。因此，我們需要針對這種突發(fā)的流量來進行限制，在盡可通常在Web入口或服務提供方（ServiceProvider）的場景下，我們需要保護服務QPS模式的流控規(guī)則，當每秒的請求量超過設定的閾值時，會自動拒絕多余的請求。Sentinel_,_,err="some-service10,//閾值為10，默認為秒級維度統(tǒng)計，即該請求單機每秒不超過10次 （二）Warm-Up/。Sentinel的Warm-Up流控模式，控制通過的流量隔控制+排隊的控制效果來防止大量請求都在同一時刻被處理。這樣可以給冷系統(tǒng)一個預API等。例如，支付的時候，可能需要遠程調用銀聯(lián)提供的API；查詢某個商品的價格，就可能會層層級聯(lián)，最終導致整個鏈路都不可用。SentinelGo提供以下的能力避免慢調熔斷降級（circuitbreaker）：對不穩(wěn)定的弱依賴調用進行自動熔斷降級，暫時SentinelGo熔斷降級特性基于熔斷器模式的思想，在服務出現(xiàn)不穩(wěn)定因素（如響應止給不穩(wěn)定服務“雪上加霜”，另一方面保護服務的調用方不被拖垮。Sentinelfallback機制，我們還是需要在HTTP或RPC可以快速返回而不會都打到DB上。但每次大促都會涌現(xiàn)出一些“黑馬”商品，這些“黑請求會擊穿緩存，直接打到DB層，導致DB訪問緩慢，擠占正常商品請求的資源池，數(shù)并控制每個熱點值的訪問QPS或并發(fā)量，可以有效地防止過“熱”的參數(shù)訪問擠占正再比如有的場景下我們希望限制每個用戶調用某個API的頻率，將API名稱+userId作為埋點資源名顯然是不合適的。這時候我們可以在給API埋點的時候通過WtAr(x將userId作為參數(shù)傳入到API埋點中，然后配置熱點規(guī)則即可針對每個用戶分別限制調用頻率；同時，SentinelSentinelGo提供的RPC框架整合模塊（如Dubbo、gRPC）均會自動將RPC如果需要配置具體值限流，受類型系統(tǒng)限制，目前僅支持基本類型和string類型。SentinelGo的熱點流量控制基于緩存淘汰機制+令牌桶機制實現(xiàn)。Sentinel通過淘汰機制（LRU、LFU、ARC策略等）來識別熱點參數(shù)，通過令牌桶機制來控制每個熱點參數(shù)的訪問量。目前的SentinelGo版本采用LRU策略統(tǒng)計熱點參數(shù)，社區(qū)也已有貢獻者提交了優(yōu)化淘汰機制的PR，在后續(xù)的版本中社區(qū)會引入更多的緩存淘汰機制來適LoadCPUusage的兜底防護手段，將瀕臨崩潰的微服務“拉”回來。針對這些情況，SentinelGo提供了entinlCPBBRoad、CPUPS務不掛，對CPU密集型的場景會有比較好的效果。同時，社區(qū)也在結合自動化控制理論SentinelGoGA的過程中，SentinelGo社區(qū)也在Kubernetes和ServiceMesh等場景下進行了一些探索。（一）KubernetesCRDdata-在生產(chǎn)環(huán)境中我們一般都需要通過配置中心來動態(tài)管理各種規(guī)則配置。在Kubernetes集群中，我們可以天然利用KubernetesCRD的方式來管理應用的SentinelGo1.0.0SentinelCRD抽象以及相應的數(shù)據(jù)源實現(xiàn)。用戶只需要先導入Sentinel規(guī)則CRD定義文件，接入Sentinel時注冊對應的data-source，然后按照CRD定義的格式編寫YAML配置并kubectlapply到對應的namespaceKubernetesCRDdata-source模塊地址：后續(xù)社區(qū)會進一步完善RuleCRD定義并與其它社區(qū)一起探討高可用防護相關的標（二）ServiceServiceMesh是微服務向云原生演進的趨勢之一。在ServiceMesh架構下，一些服務治理和策略控制的能力都逐漸下沉到了dataplane層。去年Sentinel社區(qū)在Java1.7.0版本里面做了一些嘗試，提供了EnvoylobaRateLimitinggRPCService的實現(xiàn)——SentinelRLStokenserver，借助Sentinel集群限流tokenserverEnvoySentinelGo版本的誕生，社區(qū)與更多的ServiceMesh產(chǎn)品開展合作、整合。我們與螞蟻的MOSN社區(qū)進行共建，在MOSNMesh中原生支持了SentinelGo的流控降級能力，同時也已在螞蟻內部落地。社區(qū)也在探索更為通用的方案，如利用Istio的EnvoyWASM擴展機SentinelIstio/EnvoySentinel（三）KubernetesHPAbasedonSentinel是一種思路。對于部署在Kubernetes中的應用來說，可以利用KubernetesHPA能力進行對服務進行水平擴縮容。HPA默認支持多種系統(tǒng)指標，并且支持自定義指標統(tǒng)計。KubernetesAHASSentinel均QPS、響應時間等作為條件進行彈性伸縮。社區(qū)也正在這一塊做一些嘗試，將一些Sentinel的服務級別的指標統(tǒng)計（通過量，拒絕量，響應時間等）通過Prometheus或enTee等標準方式透出，并適配到KubernetesHPA中。啟動速度快的無狀態(tài)服務（Serverless）。對于啟動較慢的服務，或非本服務容量問題的場景（如依賴的DB容量不夠），彈性的方案不能很好地解決穩(wěn)定性的問題，甚至可對微服務容錯與穩(wěn)定性的手段有了新的體會。歡迎大家動手玩一下demo，將微服務接入Sentinel來享受高可用防護和容錯的能力，讓服務“穩(wěn)如磐石”。同時Sentinel1.0GA本次GA我們也新加入了兩位給力的committer@sanxun0325和luckyxiaqing兩位在1.0版本的演進帶來了WarmUp流控、Nacos動態(tài)數(shù)據(jù)源以及一系列功能改進和性能優(yōu)化，非常積極地幫助社區(qū)答疑解惑以及review代碼。恭bugnewGtHgoodfirstissueissuemr一起主導社區(qū)的發(fā)展。我們也歡迎大家有任何問題和建議，都可以通過GtHissue、Gitter或釘釘群（群號：30150716）等渠道進行交流。Nowstarthacking!企業(yè)用戶歡迎進行登記pbmSentinel >「更高更快更穩(wěn)」，看阿里巴巴如何修煉容器服務「內外功」「更高更快更穩(wěn)」，看阿里巴巴如何修煉容器服務「內外功」 11月11日零點剛過2611往需要部署豐富的組件，不僅包括主要的Master組件，還需要部署業(yè)務方定制的OperatorIT針對上層PaaS容器服務依托OAM（OpenApplicationModel）和penKusola提供了豐富的應用交付能力抽象。對于PaaS層來說，只需要讀取匯總的應用部署統(tǒng)計數(shù)值即可，極大減少了上層系統(tǒng)需要批量查詢pod、event等信pod及events信息轉存到數(shù)據(jù)庫中，并根據(jù)數(shù)據(jù)庫中的內容提供一個統(tǒng)一的、可內嵌的部署狀態(tài)查看和診斷頁面的方式，可以使PaaS層避免直接訪問容器服務來實現(xiàn)相關功幾個命名空間中，導致容器服務管控（控制器和APIServer）在查詢命名空間下所有資源Operatorlist在控制器和APIServer中都實現(xiàn)有索引，如果使用應用作為命名空間可以利用默認的索容器服務進行了大量的組件優(yōu)化，比如通過索引、Watch書簽等的方式，避免直接穿透APIServer訪問底層存儲ETCD，并通過優(yōu)化ETCD空閑頁面分配算法、分離eventleaseETCDETCD本身的存儲能力，其中不少已經(jīng)反饋給了社區(qū)，極大降低了ETCDhttps://4/JsXsU。并且常態(tài)化地執(zhí)行演練。例如，對于容器服務APIServer，需要保證任何時候的APIServerHAAPIServeroperatordaemonsetAPIServer的魯棒性，可以利用官方提供的max-requests-inflight和max-mt-requests-inflight來實infight值配置的功能，方便在緊急情況下不APIServerETCD，要做好數(shù)據(jù)pnus進行應用的交付，其中cloneset覆蓋了阿里上百萬的容器。在cloneset中可以通過partition來控制暫停發(fā)布從而進行業(yè)務觀察，通過xvlb來控制發(fā)布的并發(fā)度。通過綜合設置partition和xaib可以實現(xiàn)復雜的發(fā)布策略。實際上，大多數(shù)情況下PaaS層在設計分批發(fā)布的功能時，往往選取了每批暫停的方一方面，通過推進業(yè)務使用方的CPUShare化，讓應用能夠原地利用節(jié)點額外計算其次，通過鏡像預熱的方式來預熱基礎鏡像，通過P2P和CDN的技術加速大規(guī)模實際情況定期對部分業(yè)務縮容，并對另外一種業(yè)務進行擴容的方式實現(xiàn)計劃資源的伸ServerlessPod池，使得不同業(yè)務緊急擴容時能夠完全規(guī)避保護。近一步來講，為了防止容器服務用戶的誤操作，我們對Namespace、CRD和Workload的資源都增加了級聯(lián)刪除的保護，避免用戶因為誤刪除還在運行Pod的Namespace、CRD和Worklo而引發(fā)災難性的后果。下圖展示了刪除一個CRD可能造成的級聯(lián)刪除故障，實際應用中，許多operator中都會設置CR為關聯(lián)WrkladOwnerCRD（Operator），極有可能會導致級聯(lián)刪除關聯(lián)的所有Pod，引起故障。施功能從應用的富容器中剝離到Sidecar或者Daemonset中的方式，并對Sidecar或者Daemon的容器進行資源的隔離，保證即使基礎設施功能發(fā)生內存泄露等異常也不指保證所有應用都具備基本的穩(wěn)定性保障配置，包括默認的調度打散策略、Pod中斷過webhook或者通過全局的應用交付模板來實現(xiàn)，應用PaaS也可以根據(jù)業(yè)務的實際針的準入、監(jiān)測機制，防止業(yè)務研發(fā)同學在對K8s機制不完全了解的情況下編寫錯誤的探Kubelet自主首先，要保證容器服務自身的變更可觀測、可灰度、可回滾。對于Controller和Webhook這類的中心管控組件，一般可以通過集群來進行灰度，但如果涉及的改動風險amesace上或者Pod的Sidecar中運行的，而官方K8s中欠缺對于節(jié)點上Pod和SidecarenKruie中的Avaceaemnset和iecaret阿里云容器服務ACK（AlibabaCloudContainerServiceforKubernetes）是全球首批通過Kubernetes一致性認證的服務平臺，提供高性能的容器應用管理服務，支KubernetesACK在阿里集團內作為核心的容器11活動；同時，容器服務將阿里內部各在過去的一年，ACK進行了積極的技術升級，針對阿里的大規(guī)模實踐和企業(yè)的豐富生產(chǎn)實踐，進一步增強了可靠性、安全性，并且提供可賠付的SLA的Kubernetes集群-ACKPro版。ACKPro版集群是在原ACK托管版集群的基礎上發(fā)展而來的集群類Master節(jié)點托管、Master節(jié)點高可用等。9月底，阿里云成為率先通過信通院容器規(guī)模化性能測試的云服務商，獲得最高級別認證—“卓越”級別，并首先成功實現(xiàn)以單集群1萬節(jié)點1百萬PodKubernetes最多可以支撐5節(jié)點及15萬Pod，已經(jīng)無法滿足日益增長的業(yè)務需求。作為云原生領域的實踐者和引領者，阿里云基于服務百萬客戶的經(jīng)驗，從多個維度對Kubernetes集群進行優(yōu)化，率先實現(xiàn)了單集群1萬節(jié)點1百萬Pod在應用管理領域，OpenKruise項目已經(jīng)正式成為了CNCF沙箱項目。OpenKruise的開源也使得每一位Kubernetes開發(fā)者和阿里云上的用戶，都能便捷地使用阿里內部云原生應用統(tǒng)一的部署發(fā)布能力。阿里通過將OpenKruise打造為一個Kubernetes之上面向大規(guī)模應用場景的通用擴展引擎，當社區(qū)用戶或外部企業(yè)遇到了Ks原生Wrklad而是可以選擇復用penKruise的成熟能力。阿里集團內部自己penKruise；而更多enKruie業(yè)版ACREE，提供公共云首個獨享實例的企業(yè)級服務。ACREE除了支持多架構容器鏡像，還支持多版本elChart、Operator等符合OCI規(guī)范制品的托管。在安全治理部分，ACREE提供了網(wǎng)絡訪問控制、安全掃描、鏡像加簽、安全審計等多維度安全保障，助力企業(yè)從DevOps到DevSecOps的升級。在全球分發(fā)加速場景，ACREE優(yōu)EE支持按需加載，實現(xiàn)鏡像數(shù)據(jù)免全量下載和在線解壓，平均容器啟動時間降低60%，提升3倍應用分發(fā)效率。目前已有眾多企業(yè)生產(chǎn)環(huán)境模使用ACREE，保障企業(yè)客戶云我們希望，阿里云上的開發(fā)者可以自由組合云上的容器產(chǎn)品家族，通過ACKPro+ACRE+OpenKruise >Oenrus11OOeKruis：11 OpenKruise：阿里巴巴雙11全鏈路應penKus是由阿里云于2019年6月開源的云原生應用自動化引擎，本質是基于Kubernetes標準擴展出來一個的應用負載項目，它可以配合原生Kubernetes使同維度上通過自動化的方式解決Kubernetes之上應用的規(guī)?；\維和規(guī)?；ㄕ締栴}，包括部署、升級、彈性擴縮容、Qos調節(jié)、健康檢查、遷移修復等等。enKruie官網(wǎng)：GitHbpbmKruise是Cruise的諧音，'K'forKubernetes，寓意Kubernetes上應用的航行Kubernetes服務數(shù)千客戶的需求沉淀。OKue阿里巴巴雙11enKruie11，阿里巴巴實現(xiàn)了核心系統(tǒng)的全面云原生化。截至202011，阿里巴巴內部已運行近十萬enKruie的workload、管理著上百萬容器。（一）內部運行的Oenu版本代碼超95下圖展示了阿里巴巴內部運行的enKrise版本與開源版本之間的關系：從上圖可以看出：Github上的enKruie就是我們主體的上游倉庫，而內部的下游倉庫只基于公共接口實現(xiàn)了極少數(shù)內部耦合功能（這部分代碼只占據(jù)了不到5%），也就是說阿里巴巴內部運行的enKrise其中95%以上的代碼完全來自于社區(qū)倉庫。社區(qū)成員為enKruie（二）在Kubernetes上自動化應用程序工作負載管理做上層業(yè)務的同學可能對“應用負載（workload）”缺乏概念，這里先簡單做個介應用負載（workload）主要指的就是這個YAML當應用擴縮容時，PaaS（運維平臺）會修改上述YAML對象中的需求機器數(shù)（比如10臺改為110，再縮容5臺則改為105），然后控制器就會按照workload期望的數(shù)量來調整實際運行的Pod（容器）數(shù)量。當應用觸發(fā)發(fā)布或回滾時，PaaS（運維平臺）則會修改上述YAML對象中的鏡像版本和發(fā)布策略，控制器就會按照給指定的發(fā)布策略來將所有管理的Pod（容器）重建為期縮容、發(fā)布都依賴于workload的工作，workload還負責持續(xù)維持應用運行時的應用實例被驅逐，那么workload會立即再為應用擴出新的容器。（三）11核心應用全面基于Oenu部署生環(huán)境下，統(tǒng)一使用penKuis的應用負載能力做部署。penKuis提供了多種不同類型的workload來支持不同的部署方式：CloneSet：（無狀態(tài)應用）這是規(guī)模最大的部分，絕大部分泛電商業(yè)務都是通過CloneSetAdvancedStatefulSet（有狀態(tài)應用SidecarSet：（sidecar生命周期管理）可以將定義好的sidecar容器動態(tài)注入到新建的Pod中，云上的運維容器、mesh容器都是通過這種機制加入到業(yè)務PodAvancedDaemonSet都是依賴于penrus提供的workload做部署和運行。不管是應用運行時的機器數(shù)量、版本管理，還是緊急擴容、發(fā)布等操作，都有enKrise無時無刻在維護著?？梢韵胂?，如果enKruie出現(xiàn)了故障會發(fā)生什么？而如果控制器邏輯存在重大bug，比如數(shù)量或版本號計算錯誤，甚至可能引起業(yè)務容這就是阿里巴巴的云上部署基座OpenKruise11業(yè)務的部署管>OenKuis：11enKruie從何而來？或者說什么問題或需求促使了eKrise當上云成為大勢、當云原生逐漸成為標準，我們卻發(fā)現(xiàn)Kubernetes原生提供的workload能力根本無法滿足阿里巴巴超大規(guī)模業(yè)務場景的需求：無狀態(tài)應用負載（eyet還有很多，這里不一一列舉在這種背景下，OpenKruise出現(xiàn)了。我們通過或是全新開發(fā)（CloneSet、SidecarSet），或是兼容性增強（AdvancedStatefulSet、AdvancedDaemonSet），penri首推的功能就是“原地升級”。通過這種能力，我們終于可以使應用發(fā)Pod建升級提升了80以上的發(fā)布速度：不僅省去了調度、分配網(wǎng)絡、分配遠程盤的耗node上已有舊鏡像、只需要拉取較少的增量發(fā)布前后IP不變、升級過程Pod網(wǎng)絡不斷，并且Pod中除了正在升級容器之外的Vlme業(yè)務訴求，本文不做一一介紹，但下圖可以看到eKrise與Kubernetes原生應用OOenKuis：11 >OenKuis：11OpKuseCNCF2020年11月11日，在這個特殊的時點，阿里巴巴技術人又迎來一件大事：經(jīng)CNCF技術監(jiān)督委員會全體成員投票，一致同意將阿里云開源的pnus正式晉級CNCF托管項目。正如開篇所說penri已經(jīng)完成了社區(qū)開源，并且內外的版本做到幾乎完全一致。除此之外，我們還將enKruie提供到了阿里云容器服務的應用目錄中，公有云上的任意客戶都可以一鍵安裝和使用pKi，真正實現(xiàn)penKuis在阿里集團內ACKpKri的客戶主要包括斗魚TV、申通、有贊等，而開源社區(qū)中攜程、Lyft等公司也都是enKruie的用戶和貢獻者。penri將基于阿里巴巴超大規(guī)模場景錘煉出的云原生應用負載能力開放出來，用部署的管理經(jīng)驗和云原生化歷程的最佳實踐成果。從正式開源之日起，enu項aitainr544國內：阿里云、螞蟻集團、攜程、騰訊、拼多多國外：微軟、Lyft、SpectroCloud、1900+GitHb300+后續(xù)enKruie深度挖掘細分領域的應用負載需求，比如我們正在探索針對FaaS與其他相關領域的開源產(chǎn)品做更緊密的結合，如Muee等，打造更完整的歡迎加入perise如果你對enKruie的發(fā)展有任何建議，歡迎發(fā)表在下方評論區(qū)。另外，你可以通過掃碼進入“pnKus社區(qū)交流釘釘群”，我們衷心歡迎每一位開源愛好者來參與enKruie的建設，共同打造云原生領域最成熟、面向最大規(guī)模的應用自動化引擎。揭開阿里巴巴復雜任務資源混合調度技術面紗揭開阿里巴巴復雜任務資源混合調度技術面紗 >揭開阿里巴巴復雜任務資源混合調度技術下，阿里巴巴針對云原生應用設計的統(tǒng)一基礎設施ASI（AlibabaServerlessASI在阿里集團內部引領著容器全面上云的實施，承擔了包括阿里集團內部輕量級容器架構演進、運維體系云原生化等職責，并進一步加速促進了新興的技術包括Mesh、Serverless、Faas等在阿里集團內的落地；支撐了包括淘寶、天貓、優(yōu)酷、高德、餓了ASI的核心基于Kubernetes，并提供完整的云原生技術棧支持。如今的ASI也已成功實現(xiàn)與阿里云容器服務ACK（AlibabaCloudContainerServiceforKubernetes）的會師；而ACK既保留了云上的各種能力，也能成功應對阿里集團復雜ASI調度器是ASI云原生的核心組件之一。在ASI云原生的發(fā)展歷程中，調度器的11零點峰值場景下，少數(shù)容器編排錯誤都有可能給業(yè)務帶來ASI調度器起源于2015年在線電商交易容器調度，這一年最早的調度器僅涵蓋在線T4（LXCLinuxKernel）和Alidocker場景，出生即責任重大，并在201511流量峰值中發(fā)揮作用。ASI調度器的演進之路也伴隨著云原生發(fā)展的全過程。它經(jīng)歷了最早期的在線交易容igmaCreulumAI一代調度器nified-Scheduler，它將進一步吸收并融合過去數(shù)年阿里巴巴DPS（伏）Hio在ASI調度器調度的任務種類豐富多樣，有海量的在線長生命周期容器和POD實例、BatchBestEffort任務等不同SLO等級的任務；有計算型、存調度之上的宿主資源各異。機型的存量非云物理機、云上神龍、ECS、異構機型如GPU/FPGA等。調度器服務場景廣泛。eesMeho等眾多新興計算場景；餓了么、考拉、神馬等新興生態(tài)場景；ODPS（伏羲）、Hippo、螞蟻、ASI在基礎設施層的職責眾多。這篇文章來了解。下面，我們重點來分享ASI調度器是如何管理著阿里如此龐大規(guī)模、如ASIASI&的資源使用姿勢，做到最少的相互干擾（CPU分布、IO）來運行用戶提交的ASI（其中標紅的框框所示在大部分時候，業(yè)界講到調度器指的是“中心調度器”，例如社區(qū)的K8skube-提交后，它需要中心調度器、單機調度、內核調度多層次調度共同協(xié)調，并進一步在K8skubelet、controllerASI廣義的調度器理解為：中心調度器、單機調度、內核調度、重調度、規(guī)模化編排調度、多層調度一體的綜合體。步細化節(jié)點上的CPU分配、存儲、網(wǎng)絡資源分配。中心調度器在K8sASI云原生的演進之路中，中心調度器即上文描述的igm調度器、eebulu調度器、ASI調度器等等。揭開阿里巴巴復雜任務資源混合調度技術面紗揭開阿里巴巴復雜任務資源混合調度技術面紗 >第一類職責：統(tǒng)籌協(xié)同單機內多POD的最佳運行。ASI在接受到中心調度器的節(jié)點POD的工作最優(yōu)，這意味著它將在單機內統(tǒng)籌協(xié)同資源，例如：每一個POD的CPU核分配的最佳調整。實時根據(jù)POD的運行指標如負載、QPS等，針對部分運行時資源執(zhí)行單機內的VPA擴縮容、或對低優(yōu)先級的任務執(zhí)行驅逐等操作。例如：動態(tài)擴展POD的CPUASI內，單機調度組件主要指SLO-Agent、Kubelet的部分增強能力；在正在建設的Unified-Scheduler調度內，單機調度主要指SLO-Agent、Task-Agent、以及Kubelet的部分增強能力。單機調度從資源視角統(tǒng)籌單機內多POD的最佳運行，但任務的運行態(tài)實際由內核控規(guī)?；幣耪{度是阿里巴巴大規(guī)模在線調度的特有場景，自17年開始建設，現(xiàn)在已另一個維度，我們也會定義調度分層，包括一層調度、二層調度、三層調度...等；igma在離線混部場景甚至引入了零層調度的概念。每個調度系統(tǒng)對調度分層的理解和定義會不一樣，并都有各自的概念。例如，在過去的igma體系內，調度分為0層、1層和2層調度：01裁，以及具體執(zhí)行；1igmaigma體系中，m12層調度交由不同的接入業(yè)務各自實現(xiàn)（例如電商交易、廣告Captain、數(shù)據(jù)庫AliDB等）。2層調度充分貼近和理解各自業(yè)務，并站在業(yè)務全局視角做眾多優(yōu)化，igma的調度分層體系的致命弊端是，各個二層調度的技術能力和投入?yún)⒉畈积R；例如廣告的二層調度系統(tǒng)非常優(yōu)秀，但并不是所有的二層調度對業(yè)務貼心到極致。ASI吸取教訓，將眾多能力下沉至ASI內，并進一步標準化上層PAAS，簡化上層的同時增強上orkloa的調度管理）、計算調度層（如DAG調度、MR調度等）、業(yè)務層（同igma2層的概念）。我嘗試用正在建設的Unified-Scheduler調度器來讓大家更好地理解。在Unified-Scheduler調度器內，調度著Product資源、Batch資源、BE計算資源三種分等級的理解這一精髓，我在后續(xù)的章節(jié)對ASI調度器也做了詳細講解。Product（在線）有Quota預算的資源，且調度器需保障其最高級別的資源可用性。典型代表是在線POD11核心鏈路上的購物車（Cart2）、訂單（trdplatfrm2等交易核心的業(yè)務POD。這些資源要求算力的嚴格保舉例來說，在線交易的長生命周期POD的存在時間很長，數(shù)天、數(shù)月、甚至數(shù)年。Product資源。淘寶、天貓、聚劃算、高德、友盟、合一、菜鳥、國際化、閑魚 多業(yè)務研發(fā)同學申請的POD（或容器）實例，相當大部分都是product資源。Product資源不僅僅指在線長生命周期的POD；凡是符合上述定義的資源請求，都是Product資源。但并不是所有的長生命周期POD都是Product資源。例如阿里內部“Aone實驗室”用于執(zhí)行CI構建任務的POD，可以長生命周期存在，但它可以被Batch資源在線業(yè)務使用的Product資源的Allocate和Usage之間的Gap在一段時間內Gap和ProdBE資源，售賣給針對latency不那么敏感和但是對資源穩(wěn)定性有一定需求的業(yè)務。Batch有quota預算，但是保證一段時間內（例如10分鐘）的一定概率（例如90%）的資源可用性。來看可能有眾多算力未被使用；此時將發(fā)揮調度器的差異化SLO分等級調度能力，將那些未跑滿的部分，作為超發(fā)資源充分使用，售賣給Batch資源。BestEffort(BE指沒有Quota預算，不保障資源可用性，隨時可以被壓制和搶占；節(jié)點上已分配在節(jié)點的Usage低于一個水位的時候，調度器認為這部分Gap是一個“比較不穩(wěn)定/不記GapBE我們可以這樣來比方：Product、Batch資源負責大塊吃肉，BE資源則負責消費Product和BatchUT測試任務，度預算，針對這類場景去購買大量的Product或者Batch資源，將非常不劃算；但如果使用最廉價的BE資源，收益將相當可觀。此時，BE資源就是Product/Batch運行中Unified-Scheduler下圖是ASI圍繞著廣義調度需覆蓋的職責，并對應不同資源等級訴求、以及服務的豐ASIASI鳥、高德、合一、友盟、海外等數(shù)十個BU的各類調度場景。其中最高等級的“Product在線業(yè)務的調度與離線調度、眾多JOB型調度相比較，有著典型的差異（描述在線LongRunning：在線應用的容器生命周期普遍都比較長。少則數(shù)天，大部分以月計，能等。而長生命周期POD帶來的差異化挑戰(zhàn)是：全局最優(yōu)的調度必須依賴重調度來持續(xù)容器運行時需要支持業(yè)務的實時交互、快速響應、低業(yè)務RT等訴求。在線容器運行的案例是2020年疫情期間的釘釘彈性訴求。大促&秒殺的規(guī)?；逯堤卣鳎喊⒗锇桶偷母鞣N大促貫穿全年，比如大家熟悉的雙1112、春節(jié)紅包等等。整個鏈路上的應用壓力、資源消耗都會隨著大促峰值流量應用基本訴求對應的是：應用擴容對應的基本訴求，例如POD規(guī)格、OS等。在ASI調度器內，它被抽象為普通的label匹配調度。容災與打散：localityASI中的網(wǎng)絡核心、ASW等。高級策略：ASI訴求如HostConfig參數(shù)、內核參數(shù)訴求等。專家運維經(jīng)驗。調度器采納這些規(guī)則，并應用于每一個POD的擴容分配中。需要應用間編排策略，來確保每一個宿主節(jié)點和每一個POD運行時最優(yōu)。地解決這一平衡；通過定義應用之間（如CPU消耗密集型、網(wǎng)絡消耗型、IO密集型、峰進而做到不同POD間的干擾概率最小。CPU精細編排控制等策略，來盡可能規(guī)避應用間運行時的潛在影響。（四）CPUCUCuet調度、CuhareCUCPU精細編排的一句話解讀是：調核，確保CPUCPU精細編排如此重要，以至于ASI在過去的數(shù)年，已經(jīng)將這一規(guī)則吃透并使用到了極致。相信您在看到下表后（僅含CpuSet精細編排調度），您也會感嘆ASI甚至已>科普：以一臺96核（實際上我們說的都是96個邏輯核）的X86架構物理機或神龍為例，它有2個Socket，每個Socket有48