作者簡(jiǎn)介

李 雨 前?

花名叫鷹緣

系統(tǒng)軟件事業(yè)部調(diào)度系統(tǒng)。

關(guān)鍵詞

Golang

調(diào)度系統(tǒng)

Sigma，阿里巴巴自有的內(nèi)容

實(shí)踐交流

工程

?

1.取材

資源調(diào)度領(lǐng)域Sigma

?主要思路是說(shuō)資源調(diào)度領(lǐng)域的Sigma，共性的借鑒性的東西，阿里特有的就不講，更多在Q&A里面。因?yàn)?/span>涉及到實(shí)踐會(huì)聚焦工程的問(wèn)題，所以我會(huì)講一些架構(gòu)設(shè)計(jì)與語(yǔ)言的選擇，和并發(fā)模式下面任務(wù)粒度怎么樣去選擇，還有一些比較大型、綜合的解決方案。

2. 工程問(wèn)題

? 所有的工程問(wèn)題，突出背后的故事，有幾個(gè)線索，第一個(gè)線索就是跟規(guī)?；嚓P(guān)，阿里的規(guī)模很大，背后就要支撐很大的規(guī)模。另外就是阿里還有很大一塊就是上云，包括雙十一，很多東西跟云相關(guān)。

???另外，我們踩過(guò)的坑，針對(duì)這些坑的解決方案跟大家分享一下。

? 最后就是在Golang當(dāng)中的bug，最怕低級(jí)錯(cuò)誤引起的。



???Sigma的業(yè)務(wù)有兩塊，一塊是對(duì)內(nèi)，一塊是對(duì)外，對(duì)內(nèi)是所有的bu都接入了Sigma的系統(tǒng)，我們的規(guī)模會(huì)有100萬(wàn)級(jí)別。Sigma的內(nèi)部有一個(gè)logo，很容易理解，就是數(shù)學(xué)求和，Sigma是很大的生態(tài)系統(tǒng)，需要很多人和系統(tǒng)配合完成。

???這個(gè)業(yè)務(wù)分了幾個(gè)層次，上層業(yè)務(wù)偏運(yùn)維，下層業(yè)務(wù)偏系統(tǒng)，從接入層，到中心的Master，到Slave，到最底會(huì)有一個(gè)Pouch。

這是sigma的架構(gòu)

可以看出來(lái)，顏色有三塊，一塊是Sigma的，一個(gè)是0層，還有一塊是關(guān)于Fuxi的，通俗的理解就是Sigma管在線，然后是Fuxi管離線的，中間是一個(gè)協(xié)調(diào)層，這樣理解起來(lái)就跟Mesos比較接近一點(diǎn)。這個(gè)架構(gòu)肯定不是最優(yōu)的，但是它存在有它客觀的原因。

我會(huì)從Sigma這邊抽象的四個(gè)案例。我會(huì)給大家展示是什么的同時(shí)，講背后我們的故事。

案例1

???首先看一下APIServer



? 我們平常寫代碼經(jīng)常會(huì)接觸到這些事情，在業(yè)務(wù)領(lǐng)域、調(diào)度領(lǐng)域稍稍不同，背后要做發(fā)布、擴(kuò)容、銷毀、啟停、升級(jí)，還有云化，特別是雙十一到阿里云買服務(wù)器，所以會(huì)有混合云需求。我們規(guī)模很大，就會(huì)要求所有簡(jiǎn)單的事情，怎么樣讓它在規(guī)?；膱?chǎng)景下面依然能夠工作。我們調(diào)度系統(tǒng)跟運(yùn)維有關(guān)，核心的內(nèi)容就是怎么樣做到運(yùn)維友好。還有就是我們做在線的容器服務(wù)，肯定要做到高可用，還有一致性。

解決思路

1. 數(shù)據(jù)一致性

數(shù)據(jù)的一致性上面我們是用etcd/redis，我們會(huì)用一個(gè)實(shí)時(shí)+全量的方式做到數(shù)據(jù)的一致性

2. 狀態(tài)的一致性

想做到很好是很難的，但是我們把狀態(tài)的一致性轉(zhuǎn)為存儲(chǔ)一致性來(lái)做，就會(huì)降低處理問(wèn)題的難度。

3. 簡(jiǎn)單的

我們沒(méi)有追求技術(shù)看起來(lái)非常完美的方案，先把業(yè)務(wù)推起來(lái)能夠用就好了。

4. 高可用-無(wú)狀態(tài)

我們要做到前面說(shuō)的高可用，有幾種方案，一個(gè)是多Master結(jié)構(gòu)，還有無(wú)狀態(tài)，還有就是快速的failover，我們希望做到無(wú)狀態(tài)。

5. 降級(jí)-搶占

規(guī)模大了以后就會(huì)有一個(gè)問(wèn)題，很多人都要資源，這個(gè)時(shí)候肯定會(huì)有一些稀缺的資源，系統(tǒng)要支持降級(jí)搶占。

6. 內(nèi)外兼容：一個(gè)團(tuán)隊(duì)兩塊牌子

要做到上云，所有的思考都要考慮到對(duì)內(nèi)對(duì)外是一班人馬，一個(gè)團(tuán)隊(duì)會(huì)有兩個(gè)牌子，這是我們整個(gè)出發(fā)點(diǎn)的思路。

???思路之后我們選擇由APIServer把前面的發(fā)布、擴(kuò)容等都放在task，丟到Redis里，底層的Worker消費(fèi)一些任務(wù)，做到無(wú)狀態(tài)，得出來(lái)的結(jié)論就是架構(gòu)整體的設(shè)計(jì)大于語(yǔ)言的選擇。

???數(shù)據(jù)一致性里面，如果能做到了實(shí)時(shí)，數(shù)據(jù)應(yīng)該就是一致性的，為什么還要加全量來(lái)彌補(bǔ)這個(gè)過(guò)程？背后一個(gè)重要的原因就是物理機(jī)的硬件或者是軟件會(huì)經(jīng)常出故障，系統(tǒng)多了之后，很難保證故障的事件跟整個(gè)鏈路100閉環(huán)起來(lái)，就導(dǎo)致總有一些地方的數(shù)據(jù)不知道為什么不一致，有很多硬件、軟件的故障導(dǎo)致實(shí)踐的層面做不到一致性，就只好加一個(gè)全量彌補(bǔ)。還有另外一種方案不要全量，我們定時(shí)同步，但是有一個(gè)問(wèn)題，時(shí)間窗口怎么定，定幾分鐘。同步的一瞬間，數(shù)據(jù)會(huì)有一些比對(duì)，這個(gè)時(shí)候加鎖，成本維護(hù)會(huì)多一點(diǎn)。

? 狀態(tài)一致性問(wèn)題轉(zhuǎn)為存儲(chǔ)一致性的問(wèn)題最好的就是轉(zhuǎn)為存儲(chǔ)一致性，我們?yōu)槭裁凑f(shuō)要面向etcd，在很大的系統(tǒng)里面有很多的設(shè)備系統(tǒng)，沒(méi)有辦法面向事務(wù)去做，最好是分布式的存儲(chǔ)把這些問(wèn)題兜掉。

? 為什么說(shuō)簡(jiǎn)單夠用，后面會(huì)有數(shù)據(jù)給大家看一下，要承載的量很大，沒(méi)有辦法做到95%以上才上線，大家等不及，可能做到85%就要上線了。

???還有就是降級(jí)，前面我提到了阿里這么多的BU，每一個(gè)BU都提了很多的預(yù)算，去采購(gòu)，這就浪費(fèi)很多資源，這中間有一個(gè)共享的buffer，肯定會(huì)有搶占，這個(gè)在開(kāi)源里面也會(huì)有一些策略。

???內(nèi)外兼容，如果是創(chuàng)業(yè)公司會(huì)有體會(huì)，一部分東西是基于內(nèi)部的服務(wù)器，還有一些是購(gòu)買上云的服務(wù)，這個(gè)時(shí)候管理起來(lái)，不可能上云的是一套管理方式，自己內(nèi)部又是一套方式，至少在開(kāi)發(fā)理解上是一模一樣的，在設(shè)計(jì)和架構(gòu)的時(shí)候要屏蔽很多的差異?；谶@樣的思考，我們覺(jué)得這種方式相對(duì)來(lái)說(shuō)會(huì)比較好一點(diǎn)，不然嘗試換其他的方式，問(wèn)題解決可能會(huì)稍微麻煩一點(diǎn)。

???前面講了設(shè)計(jì)的架構(gòu)，接下來(lái)講的案例是一個(gè)真實(shí)的場(chǎng)景。

? 我們?cè)诎⒗镆鲆淮伟l(fā)布，比如說(shuō)一開(kāi)始要拉鏡像，就要關(guān)閉告警，可能有一些應(yīng)用要下線了，還要停止應(yīng)用。然后開(kāi)始容器升級(jí)，還要做業(yè)務(wù)邏輯的檢查，檢查完之后才把告警打開(kāi)。不管是上云還是內(nèi)部，這套流程肯定是公共的，具體對(duì)接的時(shí)候又不一樣，內(nèi)部和云上不一樣，云上提供一個(gè)SDK，云上的接口的異步性的流轉(zhuǎn)和內(nèi)部也不一樣，所以要抽出來(lái)。

???內(nèi)部和阿里云上面都是這樣的事情，阿里云比較特別的是什么呢？在before會(huì)做一些處理，我們核心的架構(gòu)是很固定的，在阿里主流的語(yǔ)言是JAVA，我們討論架構(gòu)的時(shí)候，沒(méi)有局限于上來(lái)就用JAVA，Golang，或者別的，我們把架構(gòu)想清楚，之后才選擇用什么樣的開(kāi)發(fā)語(yǔ)言。

???這是我們數(shù)據(jù)的表現(xiàn)

這個(gè)表現(xiàn)是任務(wù)量，數(shù)字隱去了，這個(gè)大概是雙十一的時(shí)候，發(fā)布的量非常大，平常的量比較小，可以看到它有周期性的規(guī)則，因?yàn)榘⒗锏捏w量有發(fā)布窗口期，那一天整個(gè)的發(fā)布量大了，會(huì)有一個(gè)全局的管控。

案例2



?? 調(diào)度里面核心的模塊之一是Scheduler，在很多物理機(jī)上面選最佳的物理機(jī)，把容器布上去，常規(guī)的做法就是要有過(guò)濾鏈，過(guò)濾完之后會(huì)有一個(gè)權(quán)重的鏈，最后拿到我想要的機(jī)器上去創(chuàng)建這個(gè)容器。因?yàn)橐?guī)模大，一個(gè)請(qǐng)求在一個(gè)機(jī)房里面去掃，這一個(gè)機(jī)房可能就是萬(wàn)級(jí)別的節(jié)點(diǎn)，肯定要考慮到性能的優(yōu)化，所以篩選的規(guī)模比較大一點(diǎn)。它是一個(gè)鏈?zhǔn)降?#xff0c;首先要選擇哪些服務(wù)器作為點(diǎn)，在這一塊，我們的想法就是要并發(fā)起來(lái)，怎么樣從工程上面做一個(gè)實(shí)踐。綠色的框是順序過(guò)程，紅色的框是并發(fā)的階段，或者是關(guān)鍵資源的鎖的過(guò)程。每一個(gè)并發(fā)的粒度看成是一個(gè)物理機(jī)，相當(dāng)于每一個(gè)物理機(jī)去篩選這個(gè)是否要，這是一種模式。

???另外一種模式是說(shuō)在整個(gè)機(jī)器的頂層加一個(gè)glock，是順序還是并行都不用管，這個(gè)鎖加在上面，前面的鎖是加在下面，兩者看起來(lái)好像沒(méi)有太大的區(qū)別，測(cè)試下來(lái)發(fā)現(xiàn)性能不一樣。有幾個(gè)因素，一個(gè)是下面要做過(guò)濾鏈或者做weight，看開(kāi)銷；還有每一次篩選的規(guī)模，比如一天下來(lái)有十萬(wàn)的請(qǐng)求，每個(gè)請(qǐng)求背景物理機(jī)是好幾萬(wàn)的規(guī)模還是幾百的規(guī)模，最后對(duì)整體的性能要求是不一樣的。





粗粒度并發(fā)的性能比較好，我們選擇了第二種場(chǎng)景。深入的思考的時(shí)候，我們發(fā)現(xiàn)第一種場(chǎng)景行不通，原因是有些全局的資源沒(méi)有在一個(gè)協(xié)程里面更改，另外一個(gè)協(xié)程不能立即可見(jiàn)。

案例3



???Golang最近幾年非常的火爆，但是在阿里大的氛圍里面更強(qiáng)調(diào)的是JAVA語(yǔ)言，我們引入Golang不可能一上來(lái)就大規(guī)模，需要有一個(gè)成功的案例，或者是小規(guī)模實(shí)踐的過(guò)程。在這種環(huán)境下面，我們想讓Golang有一席之地，首選的方式就是如何做到快速的打磨，跑得很慢的時(shí)候，語(yǔ)言構(gòu)架系統(tǒng)可能就會(huì)被淘汰掉了。這是我們上一個(gè)版本，有大概五個(gè)鏈路，有一個(gè)架子，每一條鏈路是做的過(guò)程當(dāng)中，一步一步完善出來(lái)。今天我們把鏈路搬出來(lái)跟k8s做比較的時(shí)候，很多地方都是相通的，但是具體框架的編碼實(shí)踐上面來(lái)說(shuō)是有很大的差異。我們?cè)缧r(shí)候摸索的這些東西，可能就是業(yè)務(wù)驅(qū)動(dòng)或者概念驅(qū)動(dòng)，沒(méi)有真正做到工程或是回饋社區(qū)的驅(qū)動(dòng)。未來(lái)我們換了一種方式，我們可能是以工程的方式驅(qū)動(dòng)，就是回饋社區(qū)。

案例4



???我講一下怎么解讀這個(gè)圖。分幾層，上面這一層更強(qiáng)調(diào)的怎么樣編排任務(wù)，中間的這一個(gè)層是講整個(gè)容器的；縱向有三個(gè)部分，最左邊是講怎么樣調(diào)度的，中間是一個(gè)容器的引擎，再后面是容器的運(yùn)行時(shí)。





???在PouchContainer里面，官方寫了很多的Features，這些Features是源于阿里真實(shí)的實(shí)踐。為什么叫富容器，容器經(jīng)典的代表大家可能想到Docker，那Docker之前呢？比如阿里的虛擬機(jī)比較流行，從虛擬機(jī)過(guò)渡到容器，這么大的規(guī)模，需要適應(yīng)運(yùn)維的習(xí)慣，要有這樣的感知、理念，這個(gè)時(shí)候容器的技術(shù)肯定要做很厚。然后再編排，現(xiàn)在我們了解的有k8s，大家覺(jué)得很完美，但是那在k8s之前是什么，阿里的體量并不是2015年那一刻才長(zhǎng)大的，2015年之前就很大了。

???我們有一個(gè)強(qiáng)隔離，為什么說(shuō)強(qiáng)隔離？我們平時(shí)和別人探討問(wèn)題的思路有兩種思路，第一種思路是一上去就排查，把問(wèn)題解決掉。還有就看自己的系統(tǒng)，拼命的證明不是我的問(wèn)題。在這個(gè)時(shí)候你強(qiáng)隔離就好說(shuō)了，問(wèn)題排查或者是黑盒子，特別是規(guī)模很大的時(shí)候就需要隔離很強(qiáng)，每個(gè)人在我的領(lǐng)域范圍內(nèi)很容易定位。從去年到今年，阿里做了很多混部的宣傳，混部沒(méi)有強(qiáng)隔離也有問(wèn)題的。

???還有就是為什么要引入P2P？最早P2P是在流媒體里面，為什么又跟容器關(guān)聯(lián)起來(lái)了，就是因?yàn)榛ヂ?lián)網(wǎng)里面有很強(qiáng)的思維，如果你慢的話，別人就會(huì)忍無(wú)可忍的。量少的話比工作更快一點(diǎn)。但是規(guī)模大的時(shí)候沒(méi)有辦法快，在鏈路上面來(lái)，包括業(yè)界也是一樣，連路瓶頸已經(jīng)在拉鏡像，由此阿里很自然的就推了P2P加速。

???還有內(nèi)核的兼容，外界有一個(gè)說(shuō)法——CTO說(shuō)阿里的商業(yè)成功，掩蓋了阿里的技術(shù)成功，這個(gè)話確實(shí)有道理。有些業(yè)務(wù)我們是在2011年的時(shí)候拿到2.6版本，現(xiàn)在業(yè)務(wù)最新的到了4.10，那些老的業(yè)務(wù)每天服務(wù)的人群量很小，不能說(shuō)這個(gè)業(yè)務(wù)不賺錢或者沒(méi)有前景。把它下掉了也不行，要給一個(gè)緩沖期，該升級(jí)了，這個(gè)沒(méi)有辦法一步到位。這個(gè)時(shí)候要做規(guī)?；纳?jí)，或者技術(shù)的換代，內(nèi)核必須要做兼容。

???前面的內(nèi)容只是把阿里巴巴自己的問(wèn)題解決了，并沒(méi)有把這些賦能給社區(qū)，所以要做標(biāo)準(zhǔn)化的思考，這個(gè)是為了未來(lái)把好東西回饋社區(qū)，所以必須要做標(biāo)準(zhǔn)化的兼容，再反過(guò)頭來(lái)比這張圖，就知道這個(gè)架構(gòu)怎么思考，為什么要兼容CRI。

代碼1

??前面我說(shuō)最難調(diào)的bug是低級(jí)錯(cuò)誤造成的，這個(gè)低級(jí)錯(cuò)誤什么意思呢？





Golang一開(kāi)始很多人用map循環(huán)的時(shí)候，就受到了指針變量的誤用，典型的表現(xiàn)就是，一個(gè)對(duì)象循環(huán)之后就會(huì)發(fā)現(xiàn)中間的所有的值一模一樣，大家首先想到的是業(yè)務(wù)邏輯是不是不對(duì)，根本不會(huì)想到for循環(huán)是不是出了問(wèn)題。后來(lái)我們發(fā)現(xiàn)我們對(duì)語(yǔ)言本身的理解還不是特別的到位，犯了低級(jí)的錯(cuò)誤，這個(gè)PPT下面有詳細(xì)的代碼案例。

代碼2





????還有map對(duì)象的異步序列化，現(xiàn)在看來(lái)本質(zhì)上是我們用法不對(duì)，當(dāng)時(shí)理解跟業(yè)務(wù)場(chǎng)景有關(guān)，我們每次篩選服務(wù)器有上萬(wàn)的規(guī)模，為什么選擇這條服務(wù)器，要用日志把它記下來(lái)。后面的優(yōu)化、迭代要進(jìn)行消息分析。我們就想到異步做這個(gè)事情，把對(duì)象存在異步里面去刷盤。但是我們犯了致命的錯(cuò)誤，就是Goroute對(duì)同一個(gè)map執(zhí)行了讀寫并發(fā)，這樣就出現(xiàn)了map讀寫的沖突。如果知道對(duì)象是共享的資源，我們就會(huì)加鎖，但是這種場(chǎng)景下面我們沒(méi)有考慮到這個(gè)資源也會(huì)導(dǎo)致問(wèn)題。

? 業(yè)務(wù)場(chǎng)景，特別是異步對(duì)象持久化的，要有這樣一個(gè)意識(shí)，規(guī)模大的時(shí)候要考慮這樣一個(gè)問(wèn)題。

代碼3





???我們做的過(guò)程當(dāng)中發(fā)現(xiàn)有一個(gè)資源泄露的問(wèn)題，是場(chǎng)景導(dǎo)致的，我們起了很多Goroute，我們有個(gè)主任務(wù)，主任務(wù)會(huì)起很多子任務(wù)，子任務(wù)做一些循環(huán)的操作。到阿里云買服務(wù)器，阿里云是異步接口，現(xiàn)在起很多任務(wù)去買服務(wù)器，買完之后把請(qǐng)求發(fā)貨去，它返還我一個(gè)異步的ID，我再請(qǐng)求他狀態(tài)執(zhí)行結(jié)果。比如說(shuō)我先請(qǐng)求，完了之后它分配我一些資源，啟動(dòng)這些資源。比如發(fā)起申請(qǐng)，然后start，看看這個(gè)start是不是完成，start也是有一個(gè)過(guò)程。比如阿里90分鐘再建一個(gè)淘寶，要拿到資源，肯定要很快。

? ?我們?yōu)槭裁磿?huì)遇到泄露呢？我們主任務(wù)要申請(qǐng)200個(gè)實(shí)例，我會(huì)發(fā)起200或50個(gè)并發(fā)的請(qǐng)求到阿里云，但是不可能等200個(gè)請(qǐng)求全部完成了，200個(gè)來(lái)了15個(gè)就已經(jīng)向業(yè)務(wù)交付，用戶的體驗(yàn)就很好。但是這種滾動(dòng)式的交付，不可能無(wú)休止的等待，你得一分鐘之內(nèi)完成。

? 除了滾動(dòng)式的交付，還有總體任務(wù)時(shí)間的控制，這就涉及到兩級(jí)的Goroute，第一級(jí)Goroute是總?cè)蝿?wù)，子任務(wù)也是Goroute,這就會(huì)涉及到泄露的問(wèn)題。假設(shè)主任務(wù)超時(shí)了，就不管子任務(wù)，子任務(wù)一直在跑就會(huì)把資源耗完。

???如果大家對(duì)k8s里面的代碼，關(guān)于定時(shí)任務(wù)的框架有所了解的話，就會(huì)有更強(qiáng)的體會(huì)。當(dāng)時(shí)我們如果看到這個(gè)的話就會(huì)借鑒他的方式，就不會(huì)采取我們自己造輪子的方式。這個(gè)案例最重要的就是以后寫Goroute的時(shí)候要注意是不是有泄露。

代碼4





???我們為什么要做Pod打散？Pod概念在阿里有幾級(jí)，第一級(jí)是物理層級(jí)，第二級(jí)是機(jī)框打散，往上還有核心交換機(jī)的打散。比如我有兩臺(tái)服務(wù)器，其中有一臺(tái)服務(wù)器掛掉以后，可用性一下子降到了50%，其實(shí)創(chuàng)業(yè)公司還是可以接受的。但是在阿里，如果今天掛了1%，就有非常多人投訴，所以要求非常高，所以哪怕是1%的流量受到損失了，客服的量就一下子多很多。硬件故障和軟件故障是天然的，我們無(wú)法規(guī)避怎么辦呢？所有的服務(wù)不要扎堆，物理機(jī)，核心交換機(jī)上面也不要扎堆，這就是Pod打散。

???Pod打散背后還有一層思考，比如說(shuō)這臺(tái)機(jī)器已經(jīng)有了相同的Pod，另外一臺(tái)Pod一定不會(huì)往里面部署，有很強(qiáng)的隔離，要么是0，要么是1，這個(gè)打散是強(qiáng)制的。但是這里講的Pod打散不是強(qiáng)制的，是盡力交付。默認(rèn)情況下盡可能地打散，如果打散不了，只能在一起，但是一旦有打散的機(jī)會(huì)，一定給你打散，我們的打散是在得分之后再做的事情，這個(gè)跟k8s不一樣，k8s是強(qiáng)硬的，要打散就一定打散，要不然交付不成功。

???阿里的服務(wù)量很大，服務(wù)器各個(gè)地方都有，其實(shí)它可以有一定的容忍度。假設(shè)有一萬(wàn)個(gè)實(shí)例，可以允許1%的實(shí)例有波動(dòng)偏差，這個(gè)時(shí)候Pod就可以滿足它。之所以能夠接受就是因?yàn)樗捏w量太大了，有扛波動(dòng)的能力，這個(gè)跟我們接觸到的k8s完全不一樣，這是規(guī)?；囊暯强吹降臇|西。

3.總結(jié)

• 設(shè)計(jì)層面：整體架構(gòu)層面優(yōu)先語(yǔ)言選擇

• 性能層面：任務(wù)粒度選擇

• 數(shù)據(jù)驅(qū)動(dòng)：狀態(tài)一致性轉(zhuǎn)移為存儲(chǔ)一致性

• 語(yǔ)言理解：Map異步序列化，Map循環(huán)指針

• 多層并發(fā)：可控超時(shí)

• 調(diào)度算法：規(guī)模下pod打散

• Pouch Container：擁抱開(kāi)源，回歸社區(qū)

【提問(wèn)環(huán)節(jié)】

提問(wèn)者1

???提問(wèn)：我想請(qǐng)教一下，你是利用redis實(shí)現(xiàn)數(shù)據(jù)一致性，數(shù)據(jù)一致性代替狀態(tài)移植，這個(gè)什么意思？

???李雨前：比如說(shuō)在k8s里面是面向結(jié)果交付的，我要三個(gè)實(shí)例我把數(shù)字改了你就可以擴(kuò)出來(lái)，但是在k8s沒(méi)有出來(lái)之前，阿里已經(jīng)存在了這些需求，那個(gè)時(shí)候是面向過(guò)程的，什么意思呢？我要拉鏡像，我要關(guān)報(bào)警，這一系列的動(dòng)作從容器交付周期來(lái)說(shuō)，就是事務(wù)的一部分，這個(gè)時(shí)候是有狀態(tài)的。比如說(shuō)，你想一種方式是每一個(gè)狀態(tài)都帶一個(gè)ID，一連串的串回去，不可能是并發(fā)的。每一個(gè)狀態(tài)都是并發(fā)的往前做，到一個(gè)階段再并發(fā)做另外一個(gè)階段的事情，這個(gè)我們理解為是有狀態(tài)的，這些狀態(tài)我們做的時(shí)候，做不出來(lái)很好效果。

? ?為什么要放在redis，我們做之前嘗試過(guò)一點(diǎn)一點(diǎn)去做，最后我們?cè)趺醋瞿?#xff1f;每一個(gè)狀態(tài)做完了就丟到redis里面去。下一個(gè)任務(wù)做的時(shí)候就知道上一個(gè)任務(wù)是什么，只要狀態(tài)滿足了就做下一個(gè)事情，最后你后面寫很多的任務(wù)，做的事情就很簡(jiǎn)單，上一個(gè)狀態(tài)任務(wù)是什么就完了，中間做什么事情，也不需要看到全局的交互關(guān)系，這個(gè)就放到存儲(chǔ)，包括維護(hù)的一致性。

???提問(wèn)：是不是變成異步任務(wù)，每完成一個(gè)任務(wù)就存下來(lái)？

???李雨前：可以這樣理解。

???

提問(wèn)者2

???提問(wèn)：其實(shí)Sigma的思路好像跟k8s有點(diǎn)像，我不知道Sigma有沒(méi)有像k8s這種封裝嗎？是怎么暴露服務(wù)的？

???李雨前：你覺(jué)得他們兩個(gè)很像，那說(shuō)明你對(duì)k8s或者Sigma有不錯(cuò)的理解。實(shí)際上包括Sigma，包括mesos，包括Omega,包括yarn，這些東西你比較的時(shí)候，很多地方有相似之處，從整體上架構(gòu)來(lái)理解，他們確實(shí)是相似的，但是我前面提到了Sigma肯定是在K8s出來(lái)之前，那個(gè)時(shí)候就有自己演進(jìn)的思路和方式，解決的問(wèn)題都是一樣的。第二個(gè)問(wèn)題，我們有沒(méi)有社區(qū)里面大家看到的方式方法，比如說(shuō)前面講的pouch最后一項(xiàng)就是標(biāo)準(zhǔn)化的兼容，這已經(jīng)反映了我們跟社區(qū)一些好的東西已經(jīng)要開(kāi)始吸收，把社區(qū)好的理念拿到阿里的場(chǎng)景進(jìn)行實(shí)踐，實(shí)踐好了就回饋給社區(qū)，從這社區(qū)里面學(xué)到的東西有很多很多，我們也努力向社區(qū)做一些反饋。

???

提問(wèn)者3

???提問(wèn)：Sigma底層可以用pouch，docker這種嗎？

???李雨前：可以的，前面我說(shuō)了現(xiàn)在出了一個(gè)CRI，那個(gè)已經(jīng)兼容了，實(shí)現(xiàn)了CRI的協(xié)議，你用起來(lái)是一樣的，你把Pouch起來(lái)的話，你用Remoteruntime配一下就可以了，我推薦你看一下pouch官方文檔，里面有一些案例。

?

---

2018年的 Gopher Meetup 將在深圳開(kāi)啟巡回第一站，這一次邀請(qǐng)了很多新的講師給大家一起交流分享Go的使用經(jīng)驗(yàn)?

點(diǎn)擊閱讀原文報(bào)名參加

總結(jié)

以上是生活随笔為你收集整理的Golang在阿里巴巴调度系统Sigma中的实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。