Travis CI：最小的分布式系統(tǒng)（下）
大約1年之前，我們發(fā)現(xiàn)當(dāng)時(shí)的架構(gòu)有些不合理了。尤其是Hub，它上面承擔(dān)了太多的任務(wù)。Hub要接收新的處理請(qǐng)求，處理并推動(dòng)構(gòu)建日志，它要同步用戶信息到Github，它要通知用戶構(gòu)建是否成功。它跟一大群外部API打交道，全部都是在一個(gè)進(jìn)程中處理。
Hub需要繼續(xù)演化，但它卻不太可能自由擴(kuò)展。Hub只能以單進(jìn)程的方式運(yùn)行，也因此成為我們最有可能發(fā)生的單點(diǎn)錯(cuò)誤。
Github API是一個(gè)有趣的例子。我們是Github API的重度用戶，依靠這些API我們的構(gòu)建任務(wù)才能執(zhí)行。無(wú)論是獲取構(gòu)建配置信息，更新構(gòu)建狀態(tài)，還是同步用戶數(shù)據(jù)，都離不開(kāi)這些API。
回顧歷史，當(dāng)這些API中的某一個(gè)不可用，hub就會(huì)停止當(dāng)天正在處理的任務(wù)，而轉(zhuǎn)移到下一個(gè)任務(wù)上。所以，當(dāng)Github API不可用時(shí)，我們的很多構(gòu)建都會(huì)失敗。
我們對(duì)這些API賦予了很多信任，當(dāng)然現(xiàn)在也一樣，但是說(shuō)到底，這些是我們不能掌控的資源。這些資源不是我們自己來(lái)維護(hù)，而是由另外的一個(gè)團(tuán)隊(duì)，在另外的網(wǎng)絡(luò)系統(tǒng)中，有他們自身的弱點(diǎn)。
我們過(guò)去沒(méi)有這樣想。過(guò)去我們總是把這些資源當(dāng)做我們可以信賴的朋友，以為他們隨時(shí)都會(huì)響應(yīng)我們的請(qǐng)求。
我們錯(cuò)了。
一年之前，這些API無(wú)聲無(wú)息的對(duì)某個(gè)功能做了修改。這個(gè)一個(gè)雖然沒(méi)有文檔說(shuō)明，但是我們非常依賴的功能。這個(gè)功能就是這么消無(wú)聲息的被修改了，于是導(dǎo)致了我們這邊的問(wèn)題。
結(jié)果，我們的系統(tǒng)完全亂套了。原因很簡(jiǎn)單，我們把Github API當(dāng)做了自己的朋友，我們耐心的等待這些API回應(yīng)我們的請(qǐng)求。每一次新的提交，我們都等了很長(zhǎng)的時(shí)間，每次都有幾分鐘。
我們的超時(shí)設(shè)置太寬松了。因?yàn)檫@個(gè)原因，當(dāng)對(duì)Github API的請(qǐng)求最終超時(shí)時(shí)，我們的系統(tǒng)也已經(jīng)發(fā)生錯(cuò)誤。那天晚上我們花了很長(zhǎng)的時(shí)間處理這個(gè)問(wèn)題。
即便是小問(wèn)題，當(dāng)某個(gè)時(shí)刻湊到一塊了，也能夠破壞一個(gè)系統(tǒng)。
我們開(kāi)始隔離這些API請(qǐng)求，設(shè)置更短的超時(shí)時(shí)間。為了保證我們不會(huì)因?yàn)镚ithub方面的中斷而導(dǎo)致構(gòu)建失敗，我們同樣加了重試機(jī)制。為了保證我們能夠更好的處理外部的異常，我們的每一次重試都會(huì)依次延長(zhǎng)過(guò)期時(shí)間。
你應(yīng)該接受那些在你控制之外的外部API隨時(shí)可能失敗的現(xiàn)實(shí)。如果你不能將這些失敗完全隔離，你就有必要考慮如果去處理他們。
如何去處理每一個(gè)單點(diǎn)錯(cuò)誤場(chǎng)景是基于商業(yè)上的考慮。我們可以承受一個(gè)構(gòu)建出異常嗎？當(dāng)然，這不是世界末日。如果因?yàn)橥獠肯到y(tǒng)的問(wèn)題，我們能夠讓數(shù)百個(gè)構(gòu)建出現(xiàn)異常嘛？我們不能，因?yàn)闊o(wú)論什么原因，這些構(gòu)建異常夠影響到了我們的客戶。
Travis CI最初是一個(gè)好心的家伙。它總是很樂(lè)觀地認(rèn)為每一件事情總會(huì)正確的工作。
很不幸，那不是事實(shí)。每一件事在任何時(shí)刻都可能導(dǎo)致混亂，但是我們的代碼卻從來(lái)沒(méi)考慮過(guò)這一點(diǎn)。我們做過(guò)很多努力，現(xiàn)在我們?nèi)匀辉谂?，去改變這種情況，去提高我們的代碼處理外部API或者系統(tǒng)內(nèi)部異常的能力。
回到我們的系統(tǒng)，hub承擔(dān)的任務(wù)很容易導(dǎo)致異常，所以我們將其分割成很多的小應(yīng)用。每個(gè)小應(yīng)用都有其自身的目的和承擔(dān)的任務(wù)。
做好任務(wù)隔離，這樣我們就能更輕松的擴(kuò)展系統(tǒng)。大部分任務(wù)都是直接的從上到下運(yùn)行的。
現(xiàn)在我們有了三個(gè)進(jìn)程；處理新的提交，處理構(gòu)建通知，和處理構(gòu)建日志。
突然之間，我們有了新的問(wèn)題。
#p#
雖然我們的應(yīng)用已經(jīng)分割開(kāi)了，但是他們都依賴一個(gè)叫做travis-core的核心。核心包括數(shù)量很多的Travis CI所有部分的商業(yè)邏輯。這可真是一個(gè)big ball of mud。
對(duì)核心的依賴意味著核心代碼的改動(dòng)可能影響到所有應(yīng)用。我們的應(yīng)用是按照各自的任務(wù)進(jìn)行劃分，但是我們的代碼不是。
我們現(xiàn)在還在為最早的架構(gòu)設(shè)計(jì)而支付學(xué)費(fèi)。如果你增加功能，或是修改代碼，對(duì)公用部分的一點(diǎn)點(diǎn)改變都可能帶來(lái)問(wèn)題。
為了保證所有應(yīng)用的代碼都可以正常工作，當(dāng)travis-core做了修改，我們需要部署所有應(yīng)用去驗(yàn)證。
任務(wù)并不僅僅意味著你必須從代碼的角度將其分隔。任務(wù)本身也同樣需要物理分隔。
復(fù)雜的依賴影響了部署，同樣，它也影響了你交付新代碼、新功能的能力。
我們慢慢的將代碼的依賴變小，真正的從代碼隔離開(kāi)每個(gè)應(yīng)用間的任務(wù)。幸運(yùn)的是，代碼本身已經(jīng)有很好的隔離程度了，所以這個(gè)過(guò)程顯得容易多了。
有一個(gè)應(yīng)用需要特別關(guān)注，因?yàn)樗俏覀冏鰯U(kuò)展最大的挑戰(zhàn)。
日志的作用有兩個(gè)：當(dāng)構(gòu)建日志的數(shù)據(jù)塊通過(guò)消息隊(duì)列進(jìn)來(lái)時(shí)，更新數(shù)據(jù)庫(kù)對(duì)應(yīng)行，然后推送它到Pusher用于實(shí)時(shí)的用戶界面更新。
日志塊以流的形式在同一個(gè)時(shí)間從不同的進(jìn)程中進(jìn)來(lái)，然后被一個(gè)進(jìn)程處理。這個(gè)進(jìn)程每秒最高可處理100個(gè)消息。
一般情況下這樣處理日志流的方式也相當(dāng)OK，但是這也意味著我們很難處理某些時(shí)刻突然增長(zhǎng)的日志消息，因此這個(gè)唯一的進(jìn)程對(duì)于我們系統(tǒng)的擴(kuò)展會(huì)成為一個(gè)很大的障礙。
問(wèn)題在于，進(jìn)程是按照這些消息到達(dá)消息隊(duì)列的先后順序來(lái)進(jìn)行處理的，而Travis CI中的所有事情都依賴于這些消息。
更新數(shù)據(jù)庫(kù)里的一條日志流意味更新包含所有日志的一行數(shù)據(jù)。更新用戶界面的日志當(dāng)然意味著在DOM樹(shù)上附加一個(gè)新的結(jié)點(diǎn)。
為了解決這個(gè)棘手的問(wèn)題，我們需要改很多代碼。
但是首先，我們需要理清楚什么才是一個(gè)更好的解決方案，好的解決方案應(yīng)該是能夠讓我們很方便的擴(kuò)展日志處理的部分。
我們決定讓處理的順序作為消息本身的一個(gè)屬性，而不是隱含的依賴于它們被放進(jìn)消息隊(duì)列的順序。
這個(gè)想法是受到Leslie Lamport于1978年發(fā)表的一篇論文《Time, Clocks, and the Ordering of Events in a Distributed System》的啟發(fā)。
在這篇論文中，Lamport描述了在分布式系統(tǒng)中，使用遞增計(jì)數(shù)器來(lái)保留事件發(fā)生的順序的方法。當(dāng)一個(gè)消息被發(fā)送，發(fā)送者會(huì)在消息被接收者接收到之前增加計(jì)數(shù)器的值。
我們可以簡(jiǎn)化那個(gè)想法，因?yàn)樵谖覀兊膱?chǎng)景中一個(gè)日志塊只能來(lái)自一個(gè)發(fā)送者。進(jìn)程只要不斷增加計(jì)數(shù)器的值，就可以讓之后的日志收集工作變得簡(jiǎn)單。
剩下的工作就是根據(jù)計(jì)數(shù)器的值來(lái)對(duì)日志塊進(jìn)行排列了。
困難之處在于，這樣設(shè)計(jì)之后等同于允許向數(shù)據(jù)庫(kù)寫(xiě)入小的日志塊，這些小日志塊只有在對(duì)應(yīng)任務(wù)結(jié)束后才會(huì)寫(xiě)入到完整的日志中。
但是這會(huì)直接影響到用戶界面。我們不得不面對(duì)消息以無(wú)序的方式到來(lái)。這個(gè)變化的確影響的范圍大了些，但它反過(guò)來(lái)簡(jiǎn)化了很多部分的代碼。
從表面看，這個(gè)改動(dòng)似乎無(wú)關(guān)緊要。但是依賴于你本不需要依賴的順序會(huì)帶來(lái)更多潛在的復(fù)雜性。
我們現(xiàn)在不用依賴于信息是如何傳送的，因?yàn)楝F(xiàn)在我們可以在任何時(shí)間得到他們的順序。
我們修改了不少代碼，因?yàn)槟切┐a做了一個(gè)假設(shè)，任何信息都是順序過(guò)來(lái)的，而這個(gè)假設(shè)是完全錯(cuò)誤的。在分布式系統(tǒng)中，事件可以以任何順序在任何時(shí)間到達(dá)。我們只需要確保之后我們可以將這些片段重新組裝回去。
你可以從我們的博客獲取這個(gè)問(wèn)題更詳細(xì)的說(shuō)明。
到了2013年，我們每天已經(jīng)在運(yùn)行45000次構(gòu)建。我們還是在為早先的設(shè)計(jì)付出著代價(jià)，但是我們也在慢慢的改進(jìn)設(shè)計(jì)。
我們現(xiàn)在還有一個(gè)麻煩。系統(tǒng)所有的組件還是在共享同一個(gè)數(shù)據(jù)庫(kù)。如果數(shù)據(jù)庫(kù)出現(xiàn)問(wèn)題，自然的所有組件都會(huì)出現(xiàn)問(wèn)題。這個(gè)故障上周我們剛剛遇見(jiàn)一次。
這同樣意味著日志寫(xiě)入的數(shù)量(目前可以達(dá)到每秒300次)影響到了我們API的性能，當(dāng)用戶瀏覽我們的用戶界面時(shí)可能會(huì)慢一點(diǎn)。
另外，當(dāng)我們從構(gòu)建任務(wù)的數(shù)量上考慮時(shí)，我們的下一個(gè)挑戰(zhàn)就是如何去擴(kuò)展我們的數(shù)據(jù)容量。
Travis CI在500臺(tái)構(gòu)建服務(wù)器上運(yùn)行，這已經(jīng)不能再算是一個(gè)小的分布式系統(tǒng)了。我們現(xiàn)在正著手解決的問(wèn)題還是從一個(gè)相當(dāng)小的維度來(lái)考慮的，但即便在那個(gè)維度上，你也能夠遇到很多有趣的挑戰(zhàn)。根據(jù)我們的經(jīng)驗(yàn)，簡(jiǎn)單直接的解決方案總是比那些更復(fù)雜的要好。
原文鏈接：http://www.paperplanes.de/2013/10/18/the-smallest-distributed-system.html
