7月18日深圳，由InfoQ主辦的ArchSummit全球架構(gòu)師峰會(huì)拉開帷幕，此次會(huì)議重點(diǎn)選擇了6個(gè)當(dāng)前最受關(guān)注的領(lǐng)域，包括：游戲、電商、移動(dòng)互聯(lián)網(wǎng)等等。UCloud作為國(guó)內(nèi)專注服務(wù)上述垂直領(lǐng)域的云服務(wù)商，受邀參加了本次大會(huì)。會(huì)上，UCloud資深工程師邱模炯還以《UCloud云平臺(tái)的內(nèi)核實(shí)踐》為主題，給大家揭開了UCloud云平臺(tái)內(nèi)核技術(shù)的神秘面紗。其中，“UCloud內(nèi)核熱補(bǔ)丁技術(shù)”更是引發(fā)了全場(chǎng)架構(gòu)師們的極大關(guān)注。

如何零代價(jià)修復(fù)海量服務(wù)器的Linux內(nèi)核缺陷?

對(duì)于一個(gè)擁有成千上萬(wàn)臺(tái)服務(wù)器的公司，Linux內(nèi)核缺陷導(dǎo)致的死機(jī)屢見不鮮。讓工程師們糾結(jié)的是，到底要不要通過給服務(wù)器升級(jí)內(nèi)核來(lái)修復(fù)缺陷?升級(jí)意味者服務(wù)器重啟、業(yè)務(wù)中斷以及繁重的準(zhǔn)備工作;不升級(jí)則擔(dān)心服務(wù)器死機(jī)，同樣造成業(yè)務(wù)中斷和繁重的善后工作。不管是升級(jí)來(lái)修復(fù)內(nèi)核缺陷還是重啟都會(huì)有風(fēng)險(xiǎn)，都是很頭疼。

云計(jì)算時(shí)代了，一臺(tái)宿主機(jī)往往運(yùn)行多個(gè)云主機(jī)，每一次重啟不管是主動(dòng)升級(jí)還是被動(dòng)死機(jī)，都意味著中斷其上運(yùn)行的所有云主機(jī)。因此，宿主機(jī)內(nèi)核缺陷的修復(fù)更加棘手。

而作為一個(gè)支撐著上萬(wàn)家企業(yè)用戶IT基礎(chǔ)架構(gòu)的云服務(wù)商，UCloud云平臺(tái)上的海量宿主機(jī)又是如何修復(fù)內(nèi)核缺陷的呢?

邱模炯透露，如果按照傳統(tǒng)的重啟方式來(lái)修復(fù)，那么無(wú)論是對(duì)于UCloud或是用戶，都意味著繁重的運(yùn)維和業(yè)務(wù)中斷。但是，UCloud通過“內(nèi)核熱補(bǔ)丁技術(shù)”——即給運(yùn)行中的內(nèi)核打上二進(jìn)制補(bǔ)丁，UCloud已經(jīng)做到了零代價(jià)免重啟修復(fù)海量服務(wù)器的內(nèi)核缺陷!目前為止，UCloud對(duì)所發(fā)現(xiàn)的上游內(nèi)核10+個(gè)缺陷全以熱補(bǔ)丁方式修復(fù)，累計(jì)數(shù)萬(wàn)臺(tái)次，無(wú)一例失敗且無(wú)任何副作用;理論上避免了相應(yīng)次數(shù)的宿主機(jī)重啟及所隱含的云主機(jī)業(yè)務(wù)中斷。這項(xiàng)技術(shù)在UCloud已經(jīng)成熟，解決了修復(fù)內(nèi)核缺陷的兩難問題。

UCloud內(nèi)核熱補(bǔ)丁技術(shù)揭秘：

UCloud的熱補(bǔ)丁技術(shù)基于多年前的開源ksplice加以定制優(yōu)化而來(lái)，通過加載一個(gè)特殊準(zhǔn)備的熱補(bǔ)丁模塊來(lái)修復(fù)內(nèi)核。其過程如下圖所示：

熱補(bǔ)丁模塊由ksplice程序編譯生成，包含有缺陷的二進(jìn)制指令和修復(fù)后的二進(jìn)制指令(這些二進(jìn)制按函數(shù)級(jí)別組織);模塊加載后，自動(dòng)定位到內(nèi)核的缺陷處并以修復(fù)指令動(dòng)態(tài)替換缺陷指令。

除了免重啟修復(fù)，熱補(bǔ)丁還用于內(nèi)核開發(fā)過程的性能分析和故障定位。比如，加上性能統(tǒng)計(jì)代碼生成熱補(bǔ)丁，就可以在線分析感興趣的性能問題;加入額外調(diào)試代碼捕捉運(yùn)行中內(nèi)核的異常。這些非常有用，更是海量服務(wù)器里捕捉不可重現(xiàn)內(nèi)核異常的不二法寶。由于熱補(bǔ)丁不需要重啟服務(wù)器，既可打入也可撤銷，所以不會(huì)有副作用。

UCloud對(duì)開源Ksplice的優(yōu)化主要在以下三個(gè)方面：

支持高版本內(nèi)核

熱補(bǔ)丁技術(shù)與內(nèi)核緊密耦合。不同版本的內(nèi)核在指令結(jié)構(gòu)體，符合表結(jié)構(gòu)體和一些特性上(比如早期內(nèi)核沒有ftrace)有所不同，直接影響熱補(bǔ)丁成敗。UCloud研究了各版本內(nèi)核的區(qū)別，使得同一份ksplice支持各個(gè)版本的Linux內(nèi)核。值得一提的是，解決了ftrace與ksplice不兼容的問題。

允許熱修復(fù)頻繁調(diào)用的函數(shù)

不管什么樣的熱補(bǔ)丁技術(shù)，兩種類型的內(nèi)核函數(shù)難以熱補(bǔ)�。侯l繁使用的內(nèi)核函數(shù)如schedule, hrtimer;經(jīng)常處于線程棧內(nèi)核部分頂部的函數(shù)，如sys_poll, sys_read。UCloud更改了ksplice相關(guān)內(nèi)核代碼和用戶態(tài)工具，成功解除了這些限制，比如UCloud現(xiàn)網(wǎng)服務(wù)器已打入了三個(gè)hrtimer熱補(bǔ)丁。

減少業(yè)務(wù)中斷時(shí)間

ksplice是在stop_machine后替換二進(jìn)制指令的。雖然單次stop_machine對(duì)業(yè)務(wù)造成的中斷在一毫秒左右，但有些頻繁使用的內(nèi)核函數(shù)需要大量重試才能碰到合適的熱補(bǔ)丁時(shí)機(jī)，于是會(huì)造成最長(zhǎng)達(dá)上百毫秒的中斷。UCloud在此做過一點(diǎn)優(yōu)化，使得業(yè)務(wù)中斷時(shí)間控制在十毫秒級(jí)別。

海量服務(wù)器環(huán)境下熱補(bǔ)丁技術(shù)可用來(lái)零代價(jià)且無(wú)副作用地修復(fù)內(nèi)核缺陷，而且內(nèi)核開發(fā)也因熱補(bǔ)丁能走得更遠(yuǎn)更好。以前因?yàn)槿狈�輔助分析手段和懼怕內(nèi)核BUG，即使適合在內(nèi)核實(shí)現(xiàn)的特性也被告誡移到用戶態(tài)實(shí)現(xiàn)，然而有了熱補(bǔ)丁，相關(guān)觀念也可以適當(dāng)調(diào)整，內(nèi)核開發(fā)也可以更加大膽和跳脫。