Reddit廣告服務系統是怎么構建的

本篇文章給大家分享的是有關Reddit廣告服務系統是怎么構建的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Reddit如何使用Go構建其廣告服務系統，以及從流程中汲取經驗教訓。

概要

Reddit工程團隊近段時間將Go引入其堆棧，以編寫新的廣告服務系統來取代第三方系統。 Deval Shah向我們介紹了這個新服務的架構、Reddit團隊第一次使用Go的經驗，以及他們使用Go構建這個廣告服務器所學到的所有課程。

Reddit簡介

Reddit是互聯網的首頁，它是一個擁有數萬個興趣社區的社交網絡，人們可以在那里討論對他們來說重要的事情。

Reddit的數字排名：

• 第5/18（美國/世界）Alexa排名

• 330M + MAU

• 138K活躍社區

• 每月1200w篇文章

• 每月2B投票

而Reddit構建的任何系統都必須能夠處理此級別的流量。

廣告架構概述

廣告服務器需要處理整個廣告流程。廣告服務器處理從廣告顯示到廣告之后的任何后處理的所有內容。

廣告服務@ Reddit

Reddit廣告服務器有幾個要求：

• 擴展：Reddit上的每個請求都會進入廣告系統，所以它必須應對大規模的需求。

• 速度：廣告服務器必須快速。他們不希望廣告成為降低用戶體驗的性能瓶頸。他們要求在30毫秒內回復廣告。

• 拍賣：確保服務器能夠根據出價選擇最佳廣告。

• 步調：服務器必須能夠以最佳方式分配廣告。

之前的廣告服務@ Reddit：

之前，每當用戶訪問reddit.com時，reddit 的monolith后端都會向第三方廣告服務器發送請求。第三方服務器將使用其選擇的一個或多個廣告進行響應，并將其返回給用戶。

過了一會兒，他們意識到繼續使用第三方廣告服務器對他們來說不會有用，因為它：

• 慢

• 可定制性較低：第三方不支持他們想要進行的許多更改。

• 操作上不透明：他們無法知道某些事情是如何實施的，無法控制廣告的質量等。

我們決定建立一個廣告服務器，建立一個由3人組成的團隊。從infra開始，編寫服務，然后將其推廣到正在生產的系統。

廣告服務基礎設施：

廣告服務器基礎架構中使用的一些值得注意的工具：

• 適用于所有RPC的Apache Thrift。 Thrift自2007年以來一直存在，Reddit從一開始就一直在使用它。

• RocksDB用于數據存儲。它是由Facebook構建的OSS鍵值存儲。它是一個可嵌入的數據存儲，它避免了網絡跳變，并針對高讀取和寫入進行了優化。

• 他們還決定使用Go作為主要的后端語言。這是Reddit第一次將Go用于生產。在此之前，Reddit主要使用Python和Java。該團隊希望確保Go成為Reddit使用的語言集中的一等公民，并支持Reddit所需的一切。

廣告服務器架構：

這是新廣告服務器的架構：

簡要概述它的工作原理：

• Reddit.com調用了一個名為廣告選擇器的服務。這是廣告投放基礎架構中的第一項服務。這是一種Thrift服務，并接收來自reddit.com的請求。然后，它調用一個名為getAds的函數，該函數處理獲取和返回要向用戶顯示的廣告。然后廣告選擇器調用充實服務。

• 充實服務負責獲取有關查找和選擇最相關廣告所需的請求、用戶和其他信息的更多數據和信息。它會收集所有這些信息并將其返回給廣告選擇器。

• 收到充實服務的響應后，廣告選擇器會選擇添加，然后將廣告返回給reddit.com以顯示給用戶。它還將回復發送給Kafka。

• 向用戶展示廣告后，需要進行一些后期處理。客戶端向事件跟蹤器服務發送事件HTTP請求。此活動可確認廣告已投放。此事件通知也被帶到Kafka。

• Kafka為兩個Apache Spark作業提供數據：

• 事件統計流作業始終在運行，它會寫入增強服務以提供用于學習選擇更好的廣告信息。

• 還有Pacing循環，它涉及Pacing Spark工作。這涉及一個流媒體工作，計算每個廣告客戶展示的廣告數量，以及另一個確保廣告最佳展示的工作。

在這種架構中，Go服務是：

• 廣告選擇器：

1. 有30ms的P99要求

2. 涉及用于定位和選擇的復雜業務規則

3. 進行競價：所有的廣告，業務邏輯規則，是在競爭得到廣告顯示，而廣告選擇器會處理此問題。

• 事件追蹤：

1. 1ms P99要求

2. 確認日志和事件

3. 需要高度可靠

• 充實服務：

1. 節儉服務

2. 將數據返回到廣告選擇器

3. 有一個嵌入的RocksDB數據庫

4. 4毫米P99

5. 對于每個請求，它在Go中進行前綴掃描，并獲取一堆數據并進行計算和聚合。我們的想法是避免網絡跳變獲取信息，以確保我們快速提供響應。

Reddit的其他一些Go工具和服務則不會深入探討：

• 報告服務

• Vault管理工具

• 廣告事件生成服務

我們的Go經驗

這是Reddit與Go的第一次體驗。德瓦爾表示，到目前為止，這段經驗很棒。這項工作始于使用Go的兩到三名工程師，現在已經發展到大約十幾名在Go方面工作的工程師。

他們在Go看到的主要優勢是：

• 提高開發人員的速度：新工程師可以加入并快速熟悉代碼。 Go強調簡單性、快速部署和編譯時間意味著緊密的反饋循環，這有很大幫助。

• 開箱即用的出色表現：除了遵循最佳實踐外，沒有太多的工具或優化來快速運行。與他過去調整JVM和處理垃圾收集的經驗相比，這對Deval來說是一次不錯的體驗。

• 易于專注于業務邏輯：業務邏輯是困難的部分，Go的簡單性和開箱即用的性能有助于團隊專注于它。

• 最后，廣告服務會延遲大幅下降：響應時間從90毫秒降至10毫秒以下。

得到教訓

這是一系列面臨的問題，Reddit如何處理這些問題，以及從這些挑戰中學到的知識。

問題1：如何構建生產就緒的微服務？

Reddit以前有過為Python做過的經驗，但不是Go。

最初的原型通過大量的StackOverflow讀取和谷歌搜索工作，但顯然不會與開發人員一起擴展。

他們看到的一些問題是：

• 記錄、指標等都到處都是

• 改變傳輸層很難

• 我們需要可重復的模式

他們意識到Go社區已經解決了這些問題，因此他們研究了解決這些問題的現有框架。他們遇到的一些選擇：

他們認為Go-Kit最有意義。 Reddit選擇Go-Kit的主要原因是：

• 支持Thrift

• 是靈活的，不是非常有描述性。如果Reddit想要轉移到gRPC，他們希望能夠輕松遷移。

• 具有用于記錄、度量、速率限制、跟蹤、斷路等工具，這些是在生產中運行微服務時的標準要求。

• Go-Kit @ Reddit。這是使用Go-Kit的圖：

這個架構有一些值得注意的事情。中心服務有2個實現：內存實現（這很好并可以用于原型），以及用于生產實現的RocksDB實現。本地開發仍然存在內存中實現。

有幾個中間件層：跟蹤、日志記錄和度量。最后，Thrift運輸處于頂層。這種結構使得更改變得容易。例如，如果他們想要將傳輸層從Thrift更改為gRPC，他們只需要更改頂層。

使用Go-Kit是有益的，因為它為團隊提供了如何構建Go代碼的良好例證。他們以前沒有這方面的經驗，因此使用Go-Kit有助于理解Go服務的典型結構。

教訓1：使用框架/工具包。對于您使用Go的所有內容而言，并不是必需的，但對于需要度量、日志記錄等的生產服務，請使用已解決問題的庫而不是嘗試自己完成。

問題2：如何安全快速地推出新系統？

最終目標是推出新的廣告服務器，對Reddit用戶、支付廣告客戶、依賴廣告團隊的其他內部團隊影響最小。第三方廣告服務器是一個黑盒子，Reddit需要一種快速迭代、學習和改進的方法。

這就像在飛行途中改變飛機。他們慢慢地在他們的第三方服務周圍添加了新的基礎設施，當它準備就緒時，他們會把它撕掉：

• 他們首先將廣告選擇器注入請求路徑，將其純粹作為代理。系統執行的操作與以前相同，但廣告選擇器就位。這使他們可以通過廣告選擇器擴展請求，而無需實際執行任何操作。

• 然后，他們不僅僅是代理，而是在廣告選擇器服務中實施并推出了原生廣告選擇。現在，廣告選擇器將在內部處理請求，但仍充當代理并將請求傳遞給第三方，系統仍將使用第三方響應。

• 然后，他們添加了Event Logger來實現本機響應的日志記錄，并設置Kafka。

• 他們繼續構建其余的服務，從存根服務開始，并在此過程中添加邏輯。

• 最終，一旦一切就緒，他們就會切斷第三方廣告服務器。

在這些Go特性的幫助下，Go允許他們安全輕松地遷移到新的廣告服務器：

• Go編譯器很快

• 支持跨平臺編譯

• 自包含二進制文件

• 強并發原語

教訓2：Go使快速迭代變得簡單而安全。

問題3：如何調試延遲問題？

部署新廣告服務器后，他們確實看到了一些緩慢，網絡故障，部署不良等問題。

如果你確切知道哪個服務有問題，pprof就很棒。另一方面，分布式跟蹤使您可以查看服務。他們沒有支持廣告方面的分布式跟蹤，但他們確實在Reddit的堆棧上的其他地方支持它。

為什么跟蹤有用？

• 識別導致高總體延遲的熱點

• 幫助發現其他錯誤/意外行為

跟蹤通常很容易，你有一個客戶端和服務器。在客戶端，您提取跟蹤標識符，并將它們注入您發送的服務器的請求中。在服務器端，當您獲得請求和標識符時，將它們放入上下文對象并傳遞它們。使用HTTP和gRPC非常簡單，沒有理由不這樣做。

但是，reddit正在處理Thrift，所以他們遇到了一些問題。

他們看了一下Thrift替代品，Facebook Thrift和Apache Thrift。他們正在尋找的兩個關鍵功能是對標題和上下文對象的支持：

他們嘗試使用FB thrift，但是存在一些問題，主要是缺少上下文對象，導致代碼混亂和復雜化。在Apache thrift中，支持上下文對象，但它不支持頭文件。因此，解決方案是：向Apache Thrift添加標頭。這已經針對其他語言完成，但不適用于Go。因此，他們將THeader添加到Apache Thrift。這意味著現在支持上下文對象，并且頭文件可以存儲跟蹤標識符。

如果您想查看這些更改，可以查看https://github.com/devalshah88/thrift。 Deval希望通過貢獻流程獲得更改并將其合并到上游。

這是一個跟蹤代碼。客戶端包裝器只從上下文對象中提取跟蹤信息，并將其添加到headers：

服務器包裝器從頭部獲取信息并將其注入上下文對象，以便它可以傳遞：

此代碼來自https://github.com/devalshah88/thrift-tracing。

完成所有這些工作后，分布式跟蹤被證明在調試延遲問題方面非常有用。然而，我們得到的結論是第三課:使用節儉和Go進行分布式跟蹤是很困難的。

問題4：如何處理緩慢/超時？

在Reddit，他們希望系統能夠優雅地處理緩慢。他們從不希望用戶受到影響，因此如果速度緩慢，Reddit寧愿不展示廣告也不愿降低用戶體驗。

他們的兩個目標是：

• 不要讓用戶等待太久

• 不要浪費資源做不必要的工作

使用上下文對象來強制服務中的超時：這是來自充實服務的代碼，用于向上下文對象添加截止日期，傳遞它，并在截止日期到期時提前退出。

這樣的結果是好的，但還不夠：

第一張圖顯示了從充實服務獲得響應所需的時間。這個特定的時間框架有一些緩慢，但它沒有讓用戶等待超過25毫秒。

第二個圖表顯示，在服務器端，增強服務正在處理最長70毫秒的請求，因此服務器在客戶端已經超時并且在不再需要響應之后，有些浪費資源。

通常要做的是使用HTTP傳播截止日期。此代碼添加了一個超時，它通過上下文對象傳遞給服務器：

Thrift使這很難。這里沒有使用上下文對象。如果客戶端超時，goroutine不知道并且不退出：

這個方法不是特別好，但有辦法來解決這個問題：

一種選擇是為請求有效負載添加截止時間。客戶需要在請求中包含截止日期。服務器會將截止日期注入上下文對象，并使用它。這并不是很好，因為必須在所有端點進行此更改。

相反，他們通過截止日期作為節儉標題。這與它們傳遞跟蹤標識符的方式類似。在此更改之后，在服務器端，他們看到類似于客戶端的延遲：

教訓4：在服務內部和服務之間使用截止日期。

問題5：如何確保新功能不會降低性能？

快速迭代和復雜的業務邏輯可能導致性能問題。廣告服務團隊需要流程和工具，以確保他們能夠快速移動而不會違反延遲SLA。為此，他們使用了負載測試和基準測試。

使用彎曲器進行負載測試：

這就是你從Bender那里得到的回應：

負載測試對于在重負載下測試更改非常有用，并且允許開發人員再推送到生產之前優化新功能以實現高負載。

他們還利用所有關鍵系統的基準測試。此基準測試代碼：

獲取此輸出：

基準測試有助于：

• 通過改變減慢速度來防止降級

• 讓您了解事情隨時間的變化情況

• 告知開發人員有關不同實現存在的權衡

教訓5：基準測試和負載測試很容易。做吧！

回顧：

1. 使用框架/工具包

2. Go使快速迭代變得簡單而安全

3. 使用Thrift和Go進行分布式跟蹤很難

4. 在服務內部和跨服務使用截止日期

5. 使用負載測試和基準測試

結論：

• Go幫助reddit構建和擴展新的廣告服務平臺 - 易于構建和快速

• 我們分享了我們在此過程中學到的5個重要經驗教訓

• 嘗試在下一個Go項目中至少使用其中一個

以上就是Reddit廣告服務系統是怎么構建的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。