本篇內(nèi)容介紹了“Uber用Go重寫Schemaless數(shù)據(jù)庫的分片層分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)公司專注于將樂企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,商城建設(shè)。將樂網(wǎng)站建設(shè)公司,為將樂等地區(qū)提供建站服務(wù)。全流程按需設(shè)計網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

摘要： 2014 年，Uber 構(gòu)建了可擴展的容錯數(shù)據(jù)庫 Schemaless，但隨著業(yè)務(wù)的增長，原實現(xiàn)方式對資源消耗更多，同時請求延遲也在增加，為了保持 Schemaless 的性能，Uber 在不影響生產(chǎn)服務(wù)的情況下用 Go 重寫了 Schemaless 數(shù)據(jù)庫的分片層，完成了將產(chǎn)品系統(tǒng)從舊實現(xiàn)遷移到新實現(xiàn)的 Frontless 項目。

2014 年，Uber 工程構(gòu)建了可擴展的容錯數(shù)據(jù)庫 Schemaless ，為公司的快速發(fā)展提供了便利。我們僅在 2016 年就部署了 40 多個 Schemaless 實例和數(shù)千個存儲節(jié)點。

隨著業(yè)務(wù)的增長，我們的資源消耗和延遲也在增長；為了保持 Schemaless 的性能，我們需要一個能夠很好的支持大規(guī)模應(yīng)用的解決方案。在明確了假如將現(xiàn)有 Schemaless“集群”的 Python 工作節(jié)點用 Go (一種支持輕量級并發(fā)特性的語言) 重寫的話，我們的數(shù)據(jù)庫可以獲得顯著的性能提升后，我們在不影響正常生產(chǎn)的情況下，完成了將產(chǎn)品系統(tǒng)從舊實現(xiàn)遷移到新實現(xiàn)的任務(wù)。這一任務(wù)被稱為 Frontless 項目，它證明了我們可以在不影響生產(chǎn)服務(wù)的情況下重寫大型數(shù)據(jù)庫的前端。

在本文中, 我們會討論如何將 Schemaless 分片層從 Python 遷移到 Go，這一改變可以使我們用更少的資源來處理更多的流量，從而改善用戶對我們服務(wù)的體驗。

Schemaless 的背景

作為 Mezzanine 項目 ，Schemaless 于 2014 年 10 月首次推出，當初計劃將 Uber 的核心 trip 數(shù)據(jù)庫從一個獨立的 Postgres 實例遷移到一個高可用的數(shù)據(jù)庫中。

包含核心 trip 數(shù)據(jù)的 Mezzanine 數(shù)據(jù)庫被構(gòu)建為第一個 Schemaless 實例。從那時算起，目前已經(jīng)部署了 40 多個 Schemaless 實例用于眾多客戶端服務(wù)。(關(guān)于我們內(nèi)部數(shù)據(jù)庫的完整歷史演進過程，請參閱我們的三篇系列文章，Schemaless 的 設(shè)計 、 架構(gòu) 和 triggers 概述)。

在 2016 年中，有數(shù)千個工作節(jié)點在 Schemaless 實例中運行，每個工作節(jié)點都消耗大量的資源。工作節(jié)點最初是使用 Python 和由 NGINX 交付的 uWSGI 應(yīng)用程序服務(wù)器進程中的一個 Flask 微框架構(gòu)建的，每個 uWSGI 進程一次處理一個請求。

該模型簡單易行，易于建立，但不能有效地滿足我們的需求。為了處理額外的同步請求，我們必須增加更多的 uWSGI 進程，每個進程都作為一個需要額外開銷的新的 Linux 進程，因而這從根本上限制了并發(fā)線程的數(shù)量。在 Go 中，goroutines 被用來構(gòu)建并發(fā)程序。goroutine 采用輕量級設(shè)計，是由 Go 的運行時系統(tǒng)管理的線程。

為了研究重寫 Schemaless 分片層的優(yōu)化增益，我們創(chuàng)建了一個實驗性的工作節(jié)點，該節(jié)點實現(xiàn)了一個使用頻率較高、資源消耗也比較高的端點。重寫的結(jié)果顯示，延遲減少了 85%，資源消耗減少的甚至更多。

圖 1：該圖描述了 Frontless 形式實現(xiàn)的端點中值請求延遲情況

在進行了這個實驗之后，我們明確了重寫將使 Schemaless 通過釋放 CPU 和內(nèi)存來支持其所有實例中的依賴服務(wù)和工作節(jié)點。有了這些知識基礎(chǔ)，我們啟動了這個 Frontless 項目，用 Go 重寫整個 Schemaless 分片層。

Frontless 架構(gòu)設(shè)計

為了成功地重寫 Uber 技術(shù)堆棧 的這個重要部分，我們需要確保我們的重新實現(xiàn) 100% 與現(xiàn)有的工作節(jié)點兼容。我們做了一個關(guān)鍵的決定，以驗證新實現(xiàn)與原始代碼的關(guān)系，這意味著每個對新 Go 工作節(jié)點的請求都要得到跟之前對 Python 工作節(jié)點請求相同的結(jié)果。

我們估計一個完整的重寫會花費我們六個月的時間。在此期間，在 Uber 的生產(chǎn)系統(tǒng)中實現(xiàn)的新功能和 bug 修復(fù)將在 Schemaless 的情況下進行，所以我們的遷移有了一個動態(tài)的目標。我們選擇了迭代開發(fā)形式，這樣我們就可以一次性在一個端點上不斷的從遺留的 Python 代碼庫中遷移出功能，并同時在新的 Go 代碼庫中驗證。

最初，F(xiàn)rontless 工作節(jié)點只是在現(xiàn)有的 uWSGI Schemaless 工作節(jié)點前面的一個代理，所有請求都通過該節(jié)點。迭代將從重新實現(xiàn)一個端點開始，然后在生產(chǎn)中進行驗證；當不再有錯誤出現(xiàn)后，新的實現(xiàn)才會正式上線。

從部署的角度來看，F(xiàn)rontless 和 uWSGI Schemaless 的工作是一起構(gòu)建和部署的，這使得在所有實例中都可以實現(xiàn)統(tǒng)一的 Frontless，并同時支持所有生產(chǎn)場景的驗證。

圖 2：在我們的遷移過程中，一個名為 worker 節(jié)點的服務(wù)，其中 Frontless 和 Schemaless 在同一個容器中運行。Frontless 隨后收到請求，并決定是否應(yīng)該將其轉(zhuǎn)發(fā)給 Schemaless，或者由 Frontless 處理。最后，Schemaless 或 Frontless 從存儲節(jié)點獲取結(jié)果，并將其返回給服務(wù)。

讀取端點: 對比驗證

我們首先聚焦在用 Go 重新實現(xiàn)讀取端點上。在我們最初的實現(xiàn)中，Schemaless 實例上讀取端點處理平均占用 90% 的流量，并且它也是最消耗資源的。

當一個端點用 Frontless 實現(xiàn)后，將會啟動驗證進程，檢測與 Python 實現(xiàn)的差異性。Frontless 和 Schemaless 執(zhí)行請求操作時便會觸發(fā)驗證并對比響應(yīng)結(jié)果。

圖 3：當一個服務(wù)發(fā)送請求到 Frontless 時，它會將請求轉(zhuǎn)發(fā)給 Schemaless，該請求將通過查詢存儲節(jié)點生成響應(yīng)。然后，由 Schemaless 做出的響應(yīng)將返回到 Frontless，并將其轉(zhuǎn)發(fā)給服務(wù)。Frontless 還將通過查詢存儲節(jié)點來創(chuàng)建響應(yīng)。這兩種響應(yīng)是由 Frontless 和 Schemaless 構(gòu)建的，如果出現(xiàn)任何差異，結(jié)果將作為 bug 報告發(fā)送給 Schemaless 開發(fā)團隊。

使用此方法驗證，將使發(fā)送到存儲工作節(jié)點的請求數(shù)量增加一倍；為了使請求數(shù)量增加后工作正常，我們添加了配置標志來激活每個端點的驗證，并調(diào)整請求驗證的百分比閾值。這樣便可以在幾秒內(nèi)啟動或禁用對指定端點任意部分的驗證功能。

寫入端點：自動集成測試

Schemaless 的寫入請求只能一次性成功，所以為了驗證這些我們不能再使用以前的策略了。然而，由于與讀取端點相比，在 Schemaless 中寫入端點要簡單得多，因此我們決定通過自動化集成測試來測試它們。

我們建立起了集成測試環(huán)境，這樣 Schemaless Python 和 Frontless Go 就可以運行相同的測試場景了。測試是自動化的，可以在本地執(zhí)行，也可以在幾分鐘內(nèi)通過持續(xù)的集成來執(zhí)行，這可以加快開發(fā)周期。

為了規(guī)模化測試我們的實現(xiàn)，我們設(shè)置了一個 Schemaless 測試實例，其中流量測試模擬了生產(chǎn)流量。在這個測試實例中，我們將 Schemaless 的 Python 流量寫入實現(xiàn)遷移到了 Frontless 上，并運行驗證來確保寫入的正確性。

最后，一旦所有實現(xiàn)都滿足生產(chǎn)環(huán)境時，我們就可以通過運行時配置將 Schemaless 的 Python 實現(xiàn)的流量寫入功能緩慢地遷移到 Frontless 上，這樣便可以在幾秒鐘內(nèi)將部分流量寫入工作移動到新的實現(xiàn)中。

Frontless 的成果

到 2016 年 12 月為止，所有的 Mezzanine 數(shù)據(jù)庫都是由 Frontless 處理的。如圖 4 所示，所有請求的中值延遲降低了 85%，p99 請求延遲降低了 70%:

圖 4：上圖展示了由 Python(Schemaless 的工作語言，用紅色表示) 和 Go(Frontless 的工作語言，用藍色表示) 實現(xiàn)時數(shù)據(jù)庫請求處理的時間。

隨著我們 Go 的實現(xiàn)，Schemaless 的 CPU 使用率下降了 85% 以上。這種效率的增加讓我們減少了在所有 Schemaless 實例中使用工作節(jié)點的數(shù)量，這些節(jié)點也是基于與以前相同的 QPS，這從而提高了節(jié)點利用率。

圖 5：上面的圖展示了在我們的數(shù)據(jù)庫中由 Python(Schemaless 工作語言，紅色的) 和 Go(Frontless 的工作語言，藍色的) 處理的一個穩(wěn)定的請求流中的 CPU 使用情況。

Frontless 的未來

Frontless 項目表明，我們有可能在零停機的情況下，用一種全新的語言重寫一個關(guān)鍵系統(tǒng)。通過重新實現(xiàn)服務(wù)而不改變 Schemaless 的現(xiàn)有客戶端，我們能夠在幾天內(nèi)而不是數(shù)周或幾個月內(nèi)實現(xiàn)、驗證和啟用端點。重點是，驗證過程 (新的端點實現(xiàn)與現(xiàn)有生產(chǎn)中的實現(xiàn)進行比較) 給了我們信心，因為 Frontless 和 Schemaless 可以得到相同的結(jié)果。

然而，最重要的是，我們在生產(chǎn)中重寫關(guān)鍵系統(tǒng)的能力證明了 Uber 迭代開發(fā)過程的可伸縮性。

“Uber用Go重寫Schemaless數(shù)據(jù)庫的分片層分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

網(wǎng)站名稱：Uber用Go重寫Schemaless數(shù)據(jù)庫的分片層分析-創(chuàng)新互聯(lián)
分享URL：http://jinyejixie.com/article14/jesde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、靜態(tài)網(wǎng)站、商城網(wǎng)站、關(guān)鍵詞優(yōu)化、面包屑導(dǎo)航、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)