好 大家下午好我們是來自於協成的月宏輝和李金雪今天給大家分享一下就是我們怎麼用多機群HPA來幫助我們公司應對這個特別是疫情之後這個流量的快速的猛烈的恢復這樣的一個過程的OK 今天先由我給大家講一下這個事情的一個背景以及一些核心的關鍵設計然後將有我的搭檔就李金雪給大家分享這些核心的關鍵實現以及最後我們的一些經驗OK 協成大家可能國內的是非常了解的但是其實協成在疫情以前就已經開始了國際化在海外的話其實我們也有像類似於Trip.comSky Scanner這樣的一些品牌然後今天也藉這個機會也感謝一下就參與了這個項目的一些核心的成員像李宗清和王瑤OK然後我們在17年以前的時候其實就已經將我們的微服務絕大部分已經容器化了然後接下來的幾年的話我們實際上也用一系列雲原生的技術來對我們的基礎設施進行現代化的改造然後現在的話我們除了微服務其實還有一些有狀態的服務像Redis 甚至是Kavka這些已經進行的容器化也構建了一個基於多雲多混合雲的一個容器平台來給我們的整個平台進行降本同時進行自動化的一些運營OK基於這樣的一個平台我們像今年大家也知道疫情放開之後其實大家出去旅遊的這個興趣是非常的高漲的然後我們自己的平台看到的流量也是一波接一波就是非常的猛烈那我們也成功地應對了好幾波這樣的流量的一個衝擊也是對我們過去幾年的一個架構做了一次檢驗那我們觀察到我們最高的一個擴容峰值達到了2000個破的每分鐘然後在像過去的剛過去的51我們看到就是因為那個HPA的這個錯峰的一個效應給我們整個的機房的capacity有一個28%以上的一個下降對 一個節約然後我們也最高將30%以上的流量和負載泄洪到公有雲那一開始我們在做HPA的時候我們之前想一個問題就是我們要用HPA來解決什麼樣的一個問題那我覺得這個問題可能很多大家遇到的是相同的問題就是我覺得應用的容量管理是非常困難的特別是手動管理管理的話是很難管的像協成我們有一萬多個應用有兩萬多個不足組或者大家可以通俗理解為像deployment然後這些呢基本上以前都是由研發自己去管的甚至可能有一些SRE來輔助來做一些工作像疫情期間尤其像政策反覆大家也能看到這個流量基於傳統的預測是非常難做的而且疫情期間也有很強的降本壓力那降本意味著你不能太過於樂觀地去擴容那這些因素對研發來講是非常頭疼的它要花大量的時間去做這件事情而且即使它這樣做了我們也發現一些很詭異的一個現象就是我們的整體的利用率不高但是經常在一些有量的衝擊之下就是出現擴不出來的一個原因主要為什麼呢就是它會引起一個恐慌性的一個集隊就是研發都上去擴然後導壓大家都擴不出來會出現這樣的一些現象然後整個的大家的一個體驗都非常的差然後另外一個就是對資源的一個嚴重的一個浪費因為剛剛講的就是它手動管是很難的所以研發它會傾向於說以前擴很多出來放在那邊明明像我們的機票酒店或者票它是很明顯有錯峰效應的但是因為這樣的行為這些效應都已經就消失掉了就沒法去用了造成的一個後果是什麼就是整個這個應用疊加起來之後它的一個對資源對我們的capacity的一個衝擊是遠遠大於它實際所需的這個就是我們剛剛講的就是對機房的一個28%的一個錯峰效應就已經拿不到了就不管是浪費也好還是對我們容量的一個風險也好都是一個很大的一個問題這些我們都是想通過HPA來解決的OK 那進入第二部分那HPA看上去是很不錯的一個東西那我們剛開始想做的時候不管是研發也好還是說是SRE也好還是我們自己也會問自己的一個問題你這個東西我交給你拖廣了關鍵時候你擴不出來怎麼辦大家就直接就完蛋了我們對這個問題也非常非常重視了所以我們認為這個可靠性是HPA的核心當中的核心功能其實到不一定那我們那個回答就是說關鍵要保證說這個系統要擴的時候要快然後你擴的時候不要掉鏈子再一個就是你的容量要充足你容量不足你肯定說什麼也沒有用的那怎麼能保證它快那第一個問題就是你到底有多快你到底需要多快那這個我們是建立了一個框架我們第一步要做的是說我們怎麼去評估我們的目標的擴容的吞吐的SLO這個我們的做法是基於我們的一些關鍵的場景比如我們日內的擴容然後我們節假日的一些擴容的情況以及我們做DR切換的時候就融災的時候整個機房突然下盪然後它這樣的一個擴容的一些歷史的數據我們來估算說歷史上它大概是需要多大的一個峰值然後我們再疊加一些榮譽系數或者對未來的一個預估這樣能算出我們的一個SLO然後算出SLO之後的話你就要去對我們整個的擴容鏈路進行分解看看有哪些核心的關鍵鏈路哪些是不核心的不核心的他們才要做到能夠自動bypass如果掛的話那核心的鏈路的話你就要去做各種的買點然後做數據的收集然後執行壓測然後壓測完了之後就會發現有平均點然後去優化那優化這邊的話除了我們認為比較常見的就是你對代碼進行優化提升程序的性能以外我們看下來就是最有效的還是對架構進行優化這個意思是什麼意思就是核心你要保持你的架構的一些精簡就是有很多的現在各種開源項目很多但是有些項目它可能為了滿足功能的豐富性它做得比較複雜你越複雜的東西它其實越脆弱你的性能肯定就會越差的這個要特別小心你可能要對架構做一些梳理然後另外一個就是你的核心的一些關鍵鏈路 高頻的鏈路你要儘量做到收斂儘量要短就不要再東西像跨來跨去的OK那剛剛性能這個問題比如我們搞定了但是可靠性這個問題其實大家肯定心裡想我這個程序我就努力保證它可靠我做各種優化但是從架構上來講的話這是不可能的就是系統一定會蕩的那加上系統蕩了之後或者說局部蕩了之後我們怎麼保證我們對業務的承諾還是可靠的就是我們還是能擴得出來的那這個我覺得可能就是經典的可靠性的一個設計裡面的原則那什麼呢就是你要先做到故障的隔離就是你出現故障之後你不要傳導你不要這邊掛了之後導致傳導到你另外一邊也掛了你做到這一步之後那麼你應用要做一個副本的部署就是你榮譽的部署然後再做一個故障的切換那平常可能我們更多地關注的是說我多副本部署我去切換但是很多時候忽視了故障隔離這個是我們過去看到了一些大大小小的故障裡面非常非常重要的一個原則如果你做不到故障隔離你後面兩個都是沒有用的那這個也就是我們基於這種想法下面我們自己設計的一個故障隔離的一個架構從這個結構上來看的話我們一個region裡面是有多個AZ的那region AZ本來就是公有員天然提供給我們的一個故障隔離的一個預那基於這個預之類我們又划分了多個partition然後每個partition內部也有多個K8的一個集群那這點可能跟大家看到有點不太一樣就是我們的K8是不跨AZ的它不是一個regional部署的結構它是在AZ內甚至在partition內部署的一個結構目的還是為了去盡量避免各種東西向的傳導OK然後在此之上的話為了簡化這種複雜性對我們上層那些各種parts的用戶的複雜性我中間會引入一層federation抽象層具體上就是Kamada然後它會負責集群的一些調度同時會盡量屏蔽member class對外部的一個感知在這個結構之上我們引入了一些最佳時間的一些約束時間你的核心的觀點流程你應該封閉在故障域內比如說封閉在partition內封閉在AZ內盡量避免跨越partition或者是跨越AZ跨越故障域的東西向的這樣的一些依賴和頻繁的交互這個是非常非常非常非常非常重要然後基於此我們的應用是會多副本的部署在多個的故障域之間然後我們的變更我們的變更也不應該在多個故障域之間同時進行對 這是一些基本的原則那以這個原則來我們以HPA多群群HPA來舉例我們看看怎麼來落地這樣的一個原則那HPA多群群HPA我們有華費還有三個怎麼講就是鏈路第一個就是對應用的擴縮容這個是非常高頻的而且非常critical的一個鏈路然後第二個就是HPA資源的一個修改就是發佈變更這些然後還有一個就是多群群之間負載的一個均衡再平衡這是第三個鏈路那一般來講第二個鏈路或第三個鏈路是相對低頻的就如果你掛了掛了那麼一兩個小時相對對生產的定難來講沒有太大的影響那它的故障域就可以稍微放鬆一點我們把它定義成一個regional故障域也就是說如果我這個東西比如Kamada掛了或者Federation掛了它影響的只會是第二條第三條鏈路但是第一條鏈路我們把它定義成一定要再封閉在Cluster類即使我的Federation掛了或者我其他的MemberCluster掛了我只要那個MemberCluster它還是活著的它就應該能夠自動擴出來的然後這裡面有一個影視的約定就是我們的應用它在多個Cluster同一個AZ類是共享同一個流量入口的所以說某一個MemberCluster掛了之後它的負載是會均勻地傳導到另外的Cluster裡面去的它會引導到另外的Cluster裡面去擴攏所以這是一個非常關鍵的約束那這個地面也會講到OK 剛剛講到就是隔離故障隔離這樣的一個架構那我們也是構建了混合雲來擴展我們的容量解決我們容量上的一個一個焦慮的一個問題那這裡面可能有一些有一些前提給大家介紹一下就是我們的所有的Port的IP都是可路由的它不是在Class的類的一個IP然後第二個就剛剛提到的就是我們的應用在一個AZ類是共享同一個流量入口的然後第三個就是同一個AZ類我們是儘量地去Nocal的去流量調度的OK 基於這樣的一些前提我們對它的capacity的一個調度我們劃分成兩個層次第一個層次就是AZ和AZ之間我們如果要去做capacity的調度它是走的是流量的調度來驅動的那如果是一個AZ類我有多個cluster它要去做這樣的一些容量的再平衡它是通過Federation這一層的調度能力去做的這是一個分工在架構上的一個劃分OK 那接下來的就交給我的搭檔就李金雪這邊給大家分享大家好就是剛剛鴻輝給大家介紹了背景還有我們故障與隔離的架構以及混合雲的一個容量調度下面我會給大家介紹一些我們在多級群HPA上的一些具體實現首先我們先從單級群HPA講起首先就是我們的HPA它不是原生的HPA然後這樣的我們做字眼來HPA它的一個優勢在於它的擴展性和融合性會比較強具體我們的這套HPA裡它其實是分為兩類組件一類是這個型號源一類是這個型號的合生器如這樣的鎖式基本上是體現了我們的一個設計思路就這些多個processor它作為型號源它的輸入可以是CPU利用率可以是定時規則也可以是QPM等等它的輸出都要符合是replicar及實力數它代表的是什麼呢代表著這個型號源在此是它期望的一個實力數是多少這個一類組件是型號源第二類是合成器它合成器它是會接收多路replicar的輸出然後經過一個融合會得出最終的一個實力數然後會對work load進行擴縮容可以看到其實這樣的一個設計它在擴展性上是會有所提高的因為我們的processor是一個插件化的就如果我們想要擴展一個一類新的指標我們其實新增一個processor也可以了第二個就是融合性就這樣的一個按規則去做融合它的一個好處是我們其實已經解決了原生的HPA和chrome HPA它如果共同開啟會起衝突的這麼一個問題那麼基於剛剛的這樣一個設計上的思路這張圖上是對應了我們在生產上的一個單基群的一個HPA的架構圖可以看到我們主要是定義了四種CRD前面三種它名字叫Results metric, Chrometric和External metric它其實它是主要這三種主要是指代的是指標它分別是用來定義CPU這種資源利用率Chrometric是用來表示定義一個定時規則External metric是用來去定義一些比如說QPM等一些集群外的一些信息那第四種combinator是我們是用來定義比如說HPA的最小實力數最大實力數或者一些擴縮容的一些控制這樣的然後在這張圖裡我們對應的信號源有Results server, Chrome server還有External server它分別是用Watch以上的上面名字很相似的這三種CRD然後這些server當有請求來的時候它會返回的會返回的是replicat然後我們對應的在這張圖裡對應了信號源它名為smart HPA controller然後其實這一套HPA在我們公司內部的一個產品名叫smart HPA所以這裡controller是叫smart HPA controller那這個controller它是負責去watch這個combinator它會週期性的這個controller會週期性的會去檢查這些所有的這些combinator並且去各個信號源去查看這個replicat值然後進行一個融合最後去給workload進行擴縮容那在講下面的內容之前我想提前說明一點的是我後面如果提到了HPAobject或者是HPA controller指的都是我們這一套smart HPA那麼剛剛單集群HPA其實遇到了一些問題鴻灰其實也有提到過其實為了我們能夠盡量的縮小這個故障域因此我們需要實現多級群的HPA那麼我們對於HPA多級群的HPA其實主要有3點一個訴求主要的3點訴求第一個是我們希望它的改造成本能盡量的低也就是說我們希望在聯邦級群和紫級群它的HPA盡量是用同一套HPA的定義那其實那這個也是我們選擇以combinator作為多級群HPA製作的一個主要原因之一其實兼容KBS的API也是combinator這個多級群方案的一個優勢之一那麼第二點呢我們希望它是一個可靠的可靠性那它其實如剛剛鴻灰所說的我們一個故障隔離故障與隔離的這樣一個架構那我們把最核心最高頻的擴縮容鏈路要把它收斂在集群內那這就代表著我們紫級群的HPA其實是獨立工作的那聯邦級群是不參與擴縮容的那這樣會好處是我們不管是聯邦級群故障還是紫級群的故障其實是不會影響到應用的擴縮容的第三點呢是我們希望的是一個容量管理的能力那其實是我們是希望多級群HPA它能夠根據一個群眾來對HPA分發到各個紫級群並且它也能夠在多個紫級群裏針對這個群眾來做一個rebalance那簡單說來就是我們希望能夠調一調群眾那麼應用在多個集群裏的這個容量的分布也會隨之改變那其實這樣的一個剛剛提到的這個群眾其實是指的是這個群眾在集群間的一個容量的分布那我們是這個群眾是定義在一種叫propagation policy的一個CRD裏這個CRD其實是來自於commoda的那如右下角所示的一個例子它是可以通過level select選中一個或者是EP應用給它配置一個群眾那這個例子裏就表明這位被選中的這個應用它在A級群和B級群的群眾那麼再看一下我們左上角的這樣的一個多集群的架構圖那我們上一層是代表著聯邦集群聯邦集群會部署了commoda的控制面以及我們開發的FedHPA control了那下面的兩個子集群分別部署了HPA那這裏的HPA就是之前的單集群HPA那一套那在協成用戶會通過發布系統來聯邦集群創建HPA對象那FedHPA呢會根據群眾也就是定義在propagation policy裏面的這個群眾策略然後將HPA分發到下面的子集群然後並且也會根據這個群眾做rebalance那麼HPA被發到了子集群之後呢那麼子集群的HPA控制了就會工作來負責本集群的應用的一個擴縮容稍等一下這個大家稍等一下我們導師電腦參加CubeCon也很緊張了所以大家稍等一下又恢復了剛剛大概是串了一下我們這個多集群HPA架構然後用戶的這個是怎麼是怎麼用起來的吧那那這裏其實剛剛也提到了就是多集群HPA裏頭就是我們FedHPA是是如何把HPA分發到各個子集群的那那這個流程呢大致呢我會照著這個圖先講一下就主要是分為四個步驟首先呢我們FedHPA控制了它會watchHPA object然後並且呢並且呢它是也會去watchprovocation policy也就是裏頭的一個群眾那對應的是這張圖裏的一和二那然後呢這個FedHPA控制了會根據這個HPA對象和這個群眾去去做一些工作然後去生成work這裏可能要提到兩點第一個呢是是個work它是一個出現在就Kamada的一個CRD並且它在K8社區裏其實也是出現過的它代表的是什麼呢是一個子集群的HPA它會在聯邦集群有一個對應的work第二點就是我們值得一提的是就是其實HPA它有很多的參數比如說最小實力數最大實力數還有一些目標利用率等等其實這些參數呢它不太一樣有一些參數呢它是可以直接分發下去的意思是就是聯邦集群的參數和和那個子集群的呢是一樣的那在我們的這個在這場景下呢其實CPU利用率這個是可以移植的但是有一些呢它是不能一樣的比如說最小實力數和最大實力數那如果說我們原樣下發下去呢它可能因為有多個資金的存在可能會導致這個容量的加倍因此呢針對於這一種參數我們需要有一個對應的一個拆分的算法能夠根據集群的這種權重的這個order然後去做一個拆分然後去生成這個相應的這個work然後最後呢那Kamada會根據這個work裡頭定義的HPA的template去把HPA分發到這個對應的子集群裡那麼我們已經具備了把HPA分發到子集群的這樣能力那那它是根據這個權重來發的嘛那但是那麼現在有個問題是我們如果權重發生了改變那我們多集群HPA是如何在多個子集群圈進行一個rebalance的呢那我們感覺這個問題可以分成兩個字問題第一個是權重如果發生改變它對於min replicamax replica等等這種一個在多集群間的一個分配的影響是是怎樣的呢那這個一個影響的過程其實大致是分為兩部的第一個呢是其實FatHPA會根據我們的權重和當前的這樣的一個殘屬來做一個計算會算出一個design一個一個分配的結果然後接下來呢就是它會根據會根據這個design這樣的一個distribution然後去多次的去逼近這樣的一個中態那麼為什麼會存在多次逼近的這樣的一個情況呢其實是因為這個現在這個應用呢它在集群裡已經有了一些ready to pull的它已經是在承接流量了那我們權重如果發生改變那它在多個子集群裡的那個HPA的最小實力數最大實力數呢它是會發生改變的那這種改變呢可能會導致應用的一個擴縮容而我們希望這種原因導致的改變呢它不要產生縮容而盡量少的去產生擴容是為了避免這個實力在子集群間的一個震盪所以會有這麼一個多輪逼近的一個狀態那對於這種情況呢我們舉兩個例子第一個呢是沒有這種策略之前那假設我們舉個例子就是有兩個子集群A和B它之前的權重是1比0那我們現在要把它調成0比1如果呢我們沒有這麼一個grace for rebalancing的過程那這個A集群裡的實力數會立刻的縮為0那其實這個時候B集群的這個泡的其實可能沒有建出來或者它已經建出來了但是它因為做一些初始化的工作還沒有ready是不能接流量的那這個時候呢這個應用它在集群裡是沒有可用實力的那這就是一個故障了那因此呢我們就引入了這個這樣的一個grace for rebalancing的樣的一個過程那基於這樣的一個過程我舉一個例子就如又所示就是我們現在有A B C三個子集群那我們其實代分配的最小實力數假設有12個那如果直接按照這個權重來分了那應該是2 4 6但是呢我們要基於當前它有一個ready的泡的數分別是3 6 1可以看到如果我們直接按2 4 6往下發的話它會產生什麼樣的一個結果呢那其實它的C群C集群會擴容會從1擴到6會擴5個但是這三個三個集群裡其實這個應用呢它是共享一個流量入口的總流量不變的情況下那其實總實力也是不變的那C集群擴了5個A B就會縮容那其實這是一個不必要的一個正當的一個過程因此呢我們要做的就是用ready的當前的ready泡的數去修正這樣的一個desire的結果因此我們去修正了呢最終得出的是本能要發下去的一個三數是3 6 3逐步的按照這樣的一個流程去做像中態的一個逼近那剛剛我們說的是權重的改變對於最小實力數最大實力數在多集群間分配的一個影響這個權重的變化對於真實實力在多個權重間的影響是怎麼是怎麼產生的呢那其實這樣的一個流程也是主要分為兩步第一個很類似也是根據當前的一個實力數還有一個權重去計算出一個中態及desire第二個也是去多輪的去逼近這個狀態只是這個逼近的過程呢和剛剛那個場景不太一樣的就是FileHPA會在每一輪呢會計算一個我當前就根據我的部長會算一下我本輪要達到了一個狀態然後呢但是這個他把這個狀態呢想會記載一個result binding的資源但是這樣的一個狀態我們採取的策略是什麼就是我們會主動給偏少實力的那一邊那個集群主動進行擴容那主動進行擴容就會有一個問題那這個動作呢是由紫集群HPA去實現的那他如何知道有主動擴容這麼一個動作呢那其實我們是是使用了剛剛我們HPA裏的一個擴展性我們是新增了一個Processor叫Rebalance Server由他來負責輸出這個我們主動主動擴容的這樣的一個信號這樣的話紫集群的HPA扛出了會融合這個Rebalance信號和其他和其他的信號去在紫集群裏進行擴索容關於這樣的一個擴展過程它的Grace-Folded Rebalance的過程我想舉一個例子就如右邊的這個表格所示就是兩個集群A和B全重是1和1那他其實當前的實力數是9和1你如果按照應該按照全重來算呢那其實我們希望它分別有五個實力嘛那我們是如何去逼近這樣一個狀態的呢其實我們是會去主動給少的B集群去擴容從1擴到3然後再到4A集群B集群分別是6和4的這樣的一個狀態那其實這個狀態是否是要嚴格和5和5相等呢那其實是我們有一個參數是一個容忍度Tolerance的設置那麼剛剛我們介紹了單集群和多集群其實我們其實就是想做一套可靠的HPA來給應用來提高那個資源的使用效率以及提高人員效率但其實我們HPA對推崗的過程中發現其實很多研發人員並不知道HPA的這些參數要怎麼設才合理那其實這種效率還是有進一步提升的空間呢因此呢我們又推出Autopilot的這款產品這個產品呢就是給HPA挑戰的如果一個應用的HPA它被Autopilot的納管了那有Autopilot會對它的很多的參數比如Ming RappliacMax Rappliac還有一些target做一些挑優那我們這個Autopilot呢會可以支持給多個不同的應用支持不同的一個配置然後並且這樣的一個調整過程是一個逐步逼近的過程不會出現這個變化太快導致一個正當的這樣的一個結果上市的內容呢其實是我介紹的關於我們多級群HPA的一些實現那最後呢我想給大家介紹一下我們的一些經驗第一個呢是性能和可靠性是彈性系統的一個基石就是如果中間鍵或者是應用它沒有一些彈性其實這些彈性系統是很難是能夠推得起來的那第二個是我們要盡早的去建立這個數據動差的系統那其實比如說HPA它到底價值在何它是否如何衡量其實這個就是要靠數據來衡量的第三個呢就是我們去推薪項目的時候可能會比較困難但是我們可以採用的是先找到一些跟我們理念相同的一些有影響力的種子用戶那這些種子用戶我們一起去解決這些遇到的一些問題那麼後續呢再推給別的用戶就會比較自然那最後呢就是就是暫時的那種低沉低落其實是可能它就是一個暫時的然後我們需要做的一個準備就是為未來的一個復甦做好準備然後以上是我們分享的全部內容大家有問題嗎我要上來嗎喂我想問一下前生現在HPA接入率是多少復甦的話接入率就是多少復甦接入了HPA90%以上的在接生那我有個問題就是比如說你的復甦期得很慢比如加碼就得3分鐘你中了什麼快速轉復拉起來然後還有一個問題就是比如說HPA跟C1肯定離不開那你如果離不開的話節點大概多久能夠進擊群這種時間沒有要求限制之類的或者怎麼加速加速這個這個C的一個快速因為我們這邊有類似的問題想問一下OK行我回答一下這個問題就是剛剛也提到的就是你做這個事的前提你的系統一定要有足夠的彈性也就是說你的應用要改造的然後像公司當然它也有一些動機我們做了很多的改造比如說像酒店的計算引擎輸責引擎它都是很重的它原先在物理機上面但是它後來都改造成比如說是8C 24G的這樣的規格的容器而且它要求它的多長時間的一定要能啟動起來它做了很長時間的這樣的改造那為什麼要做這個改造原因是降本壓力疫情期間的那個成本壓力非常的大然後另外一個就是我們在出海的時候亞馬遜雲海外的雲它的成本是遠高於它上去之後它那個尤其你用物理機你在雲上用物理機那個成本不一定是線性的它可能是非線性的增長的所以逼迫之下它們去做這樣的改造然後像SRE它也推就是說你的應用的啟動時間的一些治理這個是前提沒有這些前提後面都不用講的沒有意義對然後第二個問題怎麼加快CA的一個擴容這塊一個是CA我們也沒有用社區的太慢了我們也做了很多的優化第一點第二點是我們也做了一些buffer就是我們在池子裡面放了大概是5%到10%的一些buffer就這樣的話它會但是這個buffer你要根據雲它自己的擴容能力你要提前去你要去測算或者你要因為你buffer背多了就是浪費對你要去算的對這個也要有數據的支撐對所以這邊背後有很多的工作而且這些工作如果等你們要來你再去做因為Infra的週期跟業務的需求週期是完全錯配的對你好我問一下就是咱們這個HPA方案的話是不是依賴於卡馬的如果那個後端的話比如說是Coopy Fet或者是Coopy Fet的話是不支持嗎Coopy Fet我們不支持因為Coopy Fet的實話講跟我們的理念還是有點差就是我們還是希望說Fet的集群它對外部用戶來講它就是看上去就算是一個單集群來用因為你只有這樣子你想寫成它很多的不同的中間建團隊或者不同的PASS團隊你要是對它沒有這樣的一個隔離透明的話你要讓它改讓它上來非常地費勁幾乎不可能就是它沒有一個這種concern的一個結偶咱們這個方案可能以後就是可能不會開源是吧我們其實之前是想開源的就是也在卡馬大裡面提了一個Proposal但是確實今年也但也知道我們衣服非常快我們太忙了所以就是暫時沒時間但是確實是Proposal已經提上去了對謝謝我想問一下就是咱們剛才說的一些指標就是什麼場景下什麼情況下會擴容或者說用然後中間提到了一個Outer Copilot那個HP我想問一下這個針對不同的應用這個自動的這個指標你怎麼定義呢你是每一個應用你都定義一個模板還是不是它是根據它歷史的數據然後會有一個有一個機線的Bass 9的推薦這個推薦其實已經適用90%以上的應用了但是始終還是有10%最後那一波那一波可能就會有SRE那邊它會基於更多的數據來源它會給一個Hint或者是就剛剛提到的對於內部的應用它會有一些更細的模板對它並不代表說它沒有意義因為如果一個Bass 9能解決90%的問題那你剩下的資源就可以投在10%上面那就是很划算的一件事情意思就是說其實協成這邊90%的應用可能就自動的那個指標對但是類似於自定默認的指標剩下的10%可能是沒有10%10%量也挺大的它也有一千個這個也受不了剩下的可能就是要自己細化這個指標這個配置這個也不是研發做剩下那些很少數的那些可能是S21跟他們一起看對但是那個占比非常小因為我們有一萬的問題用10%也有一千個謝謝OK謝謝大家