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

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