本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)

 一名新員工最近在午餐時(shí)問(wèn)筆者：“DigitalOcean的科技債務(wù)是什么樣子的?”

[[391160]]

聽(tīng)到這個(gè)問(wèn)題，筆者忍不住笑了。軟件工程師詢問(wèn)一家公司的科技債務(wù)相當(dāng)于詢問(wèn)信用評(píng)分。這是他們衡量一家公司可疑的過(guò)去和他們要背負(fù)何種包袱的方式，我們對(duì)技術(shù)包袱并不陌生。

作為一家管理自己服務(wù)器和硬件的云提供商，我們面臨著許多其他初創(chuàng)公司在云計(jì)算新時(shí)代沒(méi)有遇到的復(fù)雜問(wèn)題。這些艱難的處境最終使得我們不得不在生存初期做出權(quán)衡。任何一家快速發(fā)展的公司都知道，早期做出的技術(shù)決策往往會(huì)在日后趕上你。

看著桌子對(duì)面的新員工，筆者深吸了一口氣，說(shuō)到：“我來(lái)講講那個(gè)我們的數(shù)據(jù)庫(kù)有1500個(gè)直接連接的時(shí)候的故事……”

筆者給新員工講述的故事是DigitalOcean迄今為止最大規(guī)模的技術(shù)重建。全公司上下為其奮斗持續(xù)了多年，從中也學(xué)到不少。筆者希望這個(gè)故事將對(duì)處在棘手的技術(shù)債務(wù)難題的其他開(kāi)發(fā)人員有所幫助。

一切從哪里開(kāi)始

從一開(kāi)始，DigitalOcean就癡迷于簡(jiǎn)潔。這是其核心價(jià)值觀之一：力求簡(jiǎn)單而優(yōu)雅的解決方案。這不僅適用于我們的產(chǎn)品，也適用于我們的技術(shù)決策。在最初的系統(tǒng)設(shè)計(jì)中，這一點(diǎn)再明顯不過(guò)了。

像GitHub、Shopify和Airbnb一樣，DigitalOcean在2011年開(kāi)始作為Rails應(yīng)用程序。Rails應(yīng)用程序(內(nèi)部稱為Cloud)管理UI和公共API中的所有用戶交互。幫助Rails的是兩個(gè)Perl服務(wù)：Scheduler和DOBE(DigitalOcean后端)。

Scheduler計(jì)劃并分配Droplet給管理程序，而DOBE負(fù)責(zé)創(chuàng)建實(shí)際的Droplet虛擬機(jī)。當(dāng)Cloud和Scheduler作為獨(dú)立服務(wù)運(yùn)行時(shí)，DOBE在機(jī)隊(duì)的每臺(tái)服務(wù)器上運(yùn)行。

Cloud、Scheduler和DOBE都不能直接交流。他們通過(guò)MySQL數(shù)據(jù)庫(kù)進(jìn)行通信。這個(gè)數(shù)據(jù)庫(kù)有兩個(gè)作用：存儲(chǔ)數(shù)據(jù)和安排通信。這三個(gè)服務(wù)都使用一個(gè)數(shù)據(jù)庫(kù)表作為消息隊(duì)列來(lái)傳遞信息。

每當(dāng)用戶創(chuàng)建一個(gè)新的Droplet時(shí)，Cloud就會(huì)向隊(duì)列中插入一個(gè)新的事件記錄。Scheduler每秒連續(xù)調(diào)查數(shù)據(jù)庫(kù)以查找新的Droplet事件，并計(jì)劃在可用的管理程序上創(chuàng)建這些事件。

最后，每個(gè)DOBE事件將等待新的計(jì)劃Droplet被創(chuàng)建并完成任務(wù)。為了使這些服務(wù)器可以檢測(cè)到所有新改動(dòng)，它們都需要調(diào)查數(shù)據(jù)庫(kù)以查找表中的新記錄。

在系統(tǒng)設(shè)計(jì)方面，無(wú)限循環(huán)和給每個(gè)服務(wù)器一個(gè)與數(shù)據(jù)庫(kù)的直接連接，這可能是最基本的，很簡(jiǎn)單，而且很有效——特別是對(duì)于一個(gè)人手不足的技術(shù)團(tuán)隊(duì)來(lái)說(shuō)，他們面臨著緊迫的最后期限和快速增長(zhǎng)的用戶群。

四年來(lái)，數(shù)據(jù)庫(kù)消息隊(duì)列構(gòu)成了DigitalOcean技術(shù)棧的主干。在此期間，我們采用了一種微服務(wù)體系結(jié)構(gòu)，用gRPC替換了HTTPS作為內(nèi)部通信量，用Golang代替Perl作為后端服務(wù)。然而，所有的路仍然通向那個(gè)MySQL數(shù)據(jù)庫(kù)。

重要的是，不能僅僅因?yàn)槟承〇|西是陳舊的，就認(rèn)為它就是不正常的，應(yīng)該被取代的。Bloomberg和IBM擁有用Fortran和COBOL編寫(xiě)的遺留服務(wù)，它們所產(chǎn)生的收入比整個(gè)公司多得多。另一方面，每個(gè)系統(tǒng)都有一個(gè)比例限制。我們需要面對(duì)。

從2012年到2016年，DigitalOcean的用戶流量增長(zhǎng)超過(guò)10000%。我們?cè)诋a(chǎn)品目錄中增加了更多的產(chǎn)品，在基礎(chǔ)設(shè)施中增加了更多的服務(wù)。這增加了數(shù)據(jù)庫(kù)消息隊(duì)列上事件的進(jìn)入量。

對(duì)Droplet的需求增加意味著Scheduler正在加班加點(diǎn)地將它們?nèi)糠峙浣o服務(wù)器。不幸的是，對(duì)于Scheduler來(lái)說(shuō)，可用服務(wù)器的數(shù)量并不固定。

為了跟上不斷增長(zhǎng)的Droplet需求，我們?cè)黾恿嗽絹?lái)越多的服務(wù)器來(lái)處理流量。每個(gè)新的管理程序意味著另一個(gè)到數(shù)據(jù)庫(kù)的持久連接。到2016年初，該數(shù)據(jù)庫(kù)擁有超過(guò)15000個(gè)直接連接，每個(gè)連接每1到5秒查詢一次新事件。

如果這還不夠糟糕的話，那么每個(gè)管理程序用來(lái)獲取新的Droplet事件的SQL查詢也變得越來(lái)越復(fù)雜。它已經(jīng)變成了一個(gè)150多行的巨人，橫跨18張表格。它既令人印象深刻，又岌岌可危，難以維持。

不出所料，就是在這個(gè)時(shí)期前后，裂縫顯現(xiàn)。一個(gè)單一的故障點(diǎn)和數(shù)千個(gè)依賴項(xiàng)爭(zhēng)奪共享資源，不可避免地導(dǎo)致了一段混亂的時(shí)期。表鎖和查詢積壓導(dǎo)致中斷和性能下降。

而且由于系統(tǒng)中的緊密耦合，沒(méi)有一個(gè)明確或簡(jiǎn)單的解決方案。Cloud、Scheduler和DOBE都是瓶頸。僅修補(bǔ)一個(gè)或兩個(gè)組件只會(huì)將負(fù)載轉(zhuǎn)移到其余的瓶頸。于是，經(jīng)過(guò)反復(fù)考慮，工程人員想出了一個(gè)三管齊下的整改方案：

• 減少數(shù)據(jù)庫(kù)上的直接連接數(shù)。
• 重構(gòu)調(diào)度器的排序算法以提高可用性。
• 解除其消息隊(duì)列職責(zé)的數(shù)據(jù)庫(kù)。

開(kāi)始重構(gòu)

為了解決數(shù)據(jù)庫(kù)依賴性問(wèn)題，DigitalOcean工程師創(chuàng)建了事件路由器。事件路由器充當(dāng)區(qū)域代理，代表每個(gè)數(shù)據(jù)中心的每個(gè)DOBE實(shí)例輪詢數(shù)據(jù)庫(kù)。而不是成千上萬(wàn)的服務(wù)器每個(gè)查詢數(shù)據(jù)庫(kù)，將只有少數(shù)代理做查詢。

每個(gè)事件路由器代理將獲取特定區(qū)域中的所有活動(dòng)事件，并將每個(gè)事件委托給相應(yīng)的管理程序。事件路由器還將龐大的輪詢查詢分解得更小、更易于維護(hù)。

當(dāng)事件路由器上線時(shí)，它將數(shù)據(jù)庫(kù)連接的數(shù)量從15000多個(gè)銳減到不到100個(gè)。

接下來(lái)，工程師們將目光投向了下一個(gè)目標(biāo)：Scheduler。如前所述，Scheduler是一個(gè)Perl腳本，用于確定管理程序?qū)⒇?fù)責(zé)創(chuàng)建的Droplet。它通過(guò)使用一系列查詢對(duì)服務(wù)器進(jìn)行排名和排序來(lái)實(shí)現(xiàn)這一點(diǎn)。每當(dāng)用戶創(chuàng)建一個(gè)Droplet時(shí)，Scheduler就會(huì)用最好的機(jī)器更新表行。

雖然聽(tīng)起來(lái)很簡(jiǎn)單，但Scheduler有一些缺陷。它的邏輯很復(fù)雜，很難處理。它是單線程的，在流量高峰時(shí)性能會(huì)受到影響。最后，只有一個(gè)Scheduler實(shí)例而它必須服務(wù)于整個(gè)機(jī)隊(duì)。這是一個(gè)不可避免的瓶頸。為了解決這些問(wèn)題，工程團(tuán)隊(duì)創(chuàng)建了Scheduler V2。

更新后的Scheduler徹底修改了排名系統(tǒng)。它沒(méi)有在數(shù)據(jù)庫(kù)中查詢服務(wù)器度量，而是從管理程序聚合并將其存儲(chǔ)在自己的數(shù)據(jù)庫(kù)中。此外，Scheduler團(tuán)隊(duì)通過(guò)并發(fā)和復(fù)制使他們的新服務(wù)可在負(fù)載下運(yùn)行。

事件路由器和Scheduler V2都取得了巨大的成就，解決了許多體系結(jié)構(gòu)的故障。即便如此，還是有一個(gè)明顯的缺陷。到2017年初，集中式MySQL消息隊(duì)列仍在使用中，甚至很繁忙。它每天處理多達(dá)40萬(wàn)條新記錄，每秒更新20次。

不幸的是，刪除數(shù)據(jù)庫(kù)的消息隊(duì)列并非易事。第一步是阻止服務(wù)直接訪問(wèn)它。數(shù)據(jù)庫(kù)需要一個(gè)抽象層。它還需要一個(gè)API來(lái)聚合請(qǐng)求并代表它執(zhí)行查詢。如果任何服務(wù)想要?jiǎng)?chuàng)建一個(gè)新事件，它就需要通過(guò)API來(lái)創(chuàng)建。于是，Harpoon誕生了。

得到入股的時(shí)間比你想象的要長(zhǎng)

但是，為事件隊(duì)列構(gòu)建接口是最簡(jiǎn)單的部分。事實(shí)證明，要得到其他團(tuán)隊(duì)的入股更加困難。與Harpoon集成意味著團(tuán)隊(duì)必須放棄對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)，重寫(xiě)部分代碼庫(kù)，并最終改變他們一直以來(lái)的工作方式。那并不容易。

一個(gè)團(tuán)隊(duì)接著一個(gè)團(tuán)隊(duì)，一個(gè)服務(wù)接著一個(gè)服務(wù)，Harpoon工程師成功地將整個(gè)代碼庫(kù)遷移到他們的新平臺(tái)上。這花了大約一年時(shí)間，但到2017年底，Harpoon成為數(shù)據(jù)庫(kù)消息隊(duì)列的唯一發(fā)布者。

現(xiàn)在真正的工作開(kāi)始了。完全控制事件系統(tǒng)意味著Harpoon可以自由地重新設(shè)計(jì)Droplet工作流。

Harpoon的第一個(gè)任務(wù)是將消息隊(duì)列職責(zé)從數(shù)據(jù)庫(kù)提取到自身中。為此，Harpoon創(chuàng)建了自己的內(nèi)部消息傳遞隊(duì)列，該隊(duì)列由RabbitMQ和異步工作站組成。當(dāng)Harpoon把新事件推到一邊的隊(duì)列中時(shí)，工作站把它們從另一邊拉了出來(lái)。

由于RabbitMQ取代了數(shù)據(jù)庫(kù)的隊(duì)列，工作站可以自由地直接與Scheduler和事件路由器通信。因此，Harpoon沒(méi)有使用Scheduler V2和Event Router輪詢數(shù)據(jù)庫(kù)中的新更改，而是直接將更新推送到數(shù)據(jù)庫(kù)中。2019年撰寫(xiě)本文時(shí)，這就是Droplet事件體系結(jié)構(gòu)所處的位置。

在過(guò)去的七年里，DigitalOcean已經(jīng)從庫(kù)樂(lè)隊(duì)的根基成長(zhǎng)為今天的老牌云提供商。與其他轉(zhuǎn)型期科技公司一樣，DigitalOcean定期處理遺留代碼和科技債務(wù)。無(wú)論是打破整體，創(chuàng)建多區(qū)域服務(wù)，或消除單一故障點(diǎn)， DigitalOcean工程師始終致力于制定優(yōu)雅和簡(jiǎn)單的解決方案。