本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

 一名新員工最近在午餐時問筆者：“DigitalOcean的科技債務是什么樣子的?”

[[391160]]

聽到這個問題，筆者忍不住笑了。軟件工程師詢問一家公司的科技債務相當于詢問信用評分。這是他們衡量一家公司可疑的過去和他們要背負何種包袱的方式，我們對技術包袱并不陌生。

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

看著桌子對面的新員工，筆者深吸了一口氣，說到：“我來講講那個我們的數據庫有1500個直接連接的時候的故事……”

筆者給新員工講述的故事是DigitalOcean迄今為止最大規模的技術重建。全公司上下為其奮斗持續了多年，從中也學到不少。筆者希望這個故事將對處在棘手的技術債務難題的其他開發人員有所幫助。

一切從哪里開始

從一開始，DigitalOcean就癡迷于簡潔。這是其核心價值觀之一：力求簡單而優雅的解決方案。這不僅適用于我們的產品，也適用于我們的技術決策。在最初的系統設計中，這一點再明顯不過了。

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

Scheduler計劃并分配Droplet給管理程序，而DOBE負責創建實際的Droplet虛擬機。當Cloud和Scheduler作為獨立服務運行時，DOBE在機隊的每臺服務器上運行。

Cloud、Scheduler和DOBE都不能直接交流。他們通過MySQL數據庫進行通信。這個數據庫有兩個作用：存儲數據和安排通信。這三個服務都使用一個數據庫表作為消息隊列來傳遞信息。

每當用戶創建一個新的Droplet時，Cloud就會向隊列中插入一個新的事件記錄。Scheduler每秒連續調查數據庫以查找新的Droplet事件，并計劃在可用的管理程序上創建這些事件。

最后，每個DOBE事件將等待新的計劃Droplet被創建并完成任務。為了使這些服務器可以檢測到所有新改動，它們都需要調查數據庫以查找表中的新記錄。

在系統設計方面，無限循環和給每個服務器一個與數據庫的直接連接，這可能是最基本的，很簡單，而且很有效——特別是對于一個人手不足的技術團隊來說，他們面臨著緊迫的最后期限和快速增長的用戶群。

四年來，數據庫消息隊列構成了DigitalOcean技術棧的主干。在此期間，我們采用了一種微服務體系結構，用gRPC替換了HTTPS作為內部通信量，用Golang代替Perl作為后端服務。然而，所有的路仍然通向那個MySQL數據庫。

重要的是，不能僅僅因為某些東西是陳舊的，就認為它就是不正常的，應該被取代的。Bloomberg和IBM擁有用Fortran和COBOL編寫的遺留服務，它們所產生的收入比整個公司多得多。另一方面，每個系統都有一個比例限制。我們需要面對。

從2012年到2016年，DigitalOcean的用戶流量增長超過10000%。我們在產品目錄中增加了更多的產品，在基礎設施中增加了更多的服務。這增加了數據庫消息隊列上事件的進入量。

對Droplet的需求增加意味著Scheduler正在加班加點地將它們全部分配給服務器。不幸的是，對于Scheduler來說，可用服務器的數量并不固定。

為了跟上不斷增長的Droplet需求，我們增加了越來越多的服務器來處理流量。每個新的管理程序意味著另一個到數據庫的持久連接。到2016年初，該數據庫擁有超過15000個直接連接，每個連接每1到5秒查詢一次新事件。

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

不出所料，就是在這個時期前后，裂縫顯現。一個單一的故障點和數千個依賴項爭奪共享資源，不可避免地導致了一段混亂的時期。表鎖和查詢積壓導致中斷和性能下降。

而且由于系統中的緊密耦合，沒有一個明確或簡單的解決方案。Cloud、Scheduler和DOBE都是瓶頸。僅修補一個或兩個組件只會將負載轉移到其余的瓶頸。于是，經過反復考慮，工程人員想出了一個三管齊下的整改方案：

• 減少數據庫上的直接連接數。
• 重構調度器的排序算法以提高可用性。
• 解除其消息隊列職責的數據庫。

開始重構

為了解決數據庫依賴性問題，DigitalOcean工程師創建了事件路由器。事件路由器充當區域代理，代表每個數據中心的每個DOBE實例輪詢數據庫。而不是成千上萬的服務器每個查詢數據庫，將只有少數代理做查詢。

每個事件路由器代理將獲取特定區域中的所有活動事件，并將每個事件委托給相應的管理程序。事件路由器還將龐大的輪詢查詢分解得更小、更易于維護。

當事件路由器上線時，它將數據庫連接的數量從15000多個銳減到不到100個。

接下來，工程師們將目光投向了下一個目標：Scheduler。如前所述，Scheduler是一個Perl腳本，用于確定管理程序將負責創建的Droplet。它通過使用一系列查詢對服務器進行排名和排序來實現這一點。每當用戶創建一個Droplet時，Scheduler就會用最好的機器更新表行。

雖然聽起來很簡單，但Scheduler有一些缺陷。它的邏輯很復雜，很難處理。它是單線程的，在流量高峰時性能會受到影響。最后，只有一個Scheduler實例而它必須服務于整個機隊。這是一個不可避免的瓶頸。為了解決這些問題，工程團隊創建了Scheduler V2。

更新后的Scheduler徹底修改了排名系統。它沒有在數據庫中查詢服務器度量，而是從管理程序聚合并將其存儲在自己的數據庫中。此外，Scheduler團隊通過并發和復制使他們的新服務可在負載下運行。

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

不幸的是，刪除數據庫的消息隊列并非易事。第一步是阻止服務直接訪問它。數據庫需要一個抽象層。它還需要一個API來聚合請求并代表它執行查詢。如果任何服務想要創建一個新事件，它就需要通過API來創建。于是，Harpoon誕生了。

得到入股的時間比你想象的要長

但是，為事件隊列構建接口是最簡單的部分。事實證明，要得到其他團隊的入股更加困難。與Harpoon集成意味著團隊必須放棄對數據庫的訪問，重寫部分代碼庫，并最終改變他們一直以來的工作方式。那并不容易。

一個團隊接著一個團隊，一個服務接著一個服務，Harpoon工程師成功地將整個代碼庫遷移到他們的新平臺上。這花了大約一年時間，但到2017年底，Harpoon成為數據庫消息隊列的唯一發布者。

現在真正的工作開始了。完全控制事件系統意味著Harpoon可以自由地重新設計Droplet工作流。

Harpoon的第一個任務是將消息隊列職責從數據庫提取到自身中。為此，Harpoon創建了自己的內部消息傳遞隊列，該隊列由RabbitMQ和異步工作站組成。當Harpoon把新事件推到一邊的隊列中時，工作站把它們從另一邊拉了出來。

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

在過去的七年里，DigitalOcean已經從庫樂隊的根基成長為今天的老牌云提供商。與其他轉型期科技公司一樣，DigitalOcean定期處理遺留代碼和科技債務。無論是打破整體，創建多區域服務，或消除單一故障點， DigitalOcean工程師始終致力于制定優雅和簡單的解決方案。