GraphQL在微服務查詢中實現聚合器與搜尋索引的作用 -Netflix TechBlog

banq發表於2019-11-07

展示了Netflix如何利用GraphQL和Kafka和Elasticsearch來建立索引,透過總的查詢聚合器以跨多個松耦合服務搜尋資料。如何使用GraphQL中定義的關係和架構自動構建和維護搜尋資料庫。

Netflix的營銷技術
我們的目標是在全球推廣Netflix的內容。Netflix在該服務上擁有數千個節目,在190多個國家/地區運營,並支援大約30種語言。對於這些節目,國家和語言,我們需要找到與每個潛在觀眾產生共鳴的合適廣告素材。我們的團隊構建了在全球範圍內製作和分發這些營銷創意的工具,每個月為數十億次的展示提供動力!
為了使我們的營銷利益相關者能夠管理這些創意,我們需要將分佈在許多服務中的資料彙總在一起-GraphQL使這種聚合變得容易。
舉例來說,我們的資料以廣告素材服務為中心,以跟蹤我們製作的廣告素材。每個廣告素材都會透過其所推廣的節目的更多資訊得到增強,並且該節目在全球範圍內的排名也得到了進一步的提高。此外,我們的營銷團隊可以在需要調整時對廣告素材發表評論。我們維護著更多的關係,但在本篇文章中,我們將重點關注這些關係。

搜尋分散資料的挑戰
顯示一個廣告素材的資料很有幫助,但是我們有很多廣告素材可供搜尋。如果我們為Netflix支援的每個節目,語言和國家/地區僅製作少量變體,則將產生超過 5,000萬個廣告素材。我們需要一個合適的搜尋解決方案。
問題源於我們試圖跨鬆散耦合的多個獨立服務搜尋資料的事實。沒有任何一項服務可以完全瞭解系統的工作方式。每個服務都可能實現其自己的搜尋資料庫,但是我們仍然需要一個聚合器。該聚合器將需要執行更復雜的操作,例如即使排名資料儲存在另一服務中處,也可以透過排名搜尋創意。
如果我們有一個包含所有資訊的資料庫,那麼搜尋將很容易。我們可以編寫幾個join語句和where子句:問題已解決。但是,單體資料庫有其自身的缺點,主要是圍繞允許團隊獨立工作的有限靈活性和大規模的效能限制。
另一種選擇是使用自定義聚合服務,該服務將構建自己的資料索引。該服務將瞭解每個資料的來源,瞭解所有資料的連線方式,並能夠以多種方式組合資料。除了索引部分之外,這些特徵還完美描述了GraphQL中的實體關係。

索引資料
由於我們已經使用GraphQL,我們如何利用它來索引資料? 我們可以稍微更新GraphQL查詢以檢索單個廣告素材及其所有相關資料,然後對資料庫中的每個廣告素材呼叫一次該查詢,將結果索引到Elasticsearch中。透過批次處理和並行化請求以透過對GraphQL伺服器的單個查詢來檢索許多廣告素材,我們可以最佳化索引構建過程。
當為資料建立索引時,Elasticsearch有很多自定義選項,但是在許多情況下,預設設定可以提供很好的結果。至少,我們從GraphQL查詢中提取所有型別定義,並將它們對映到可供Elasticsearch使用的模式。
使用GraphQL查詢生成模式的好處是,任何依賴於此資料的現有客戶端都將獲得相同形狀的資料,無論它來自GraphQL伺服器還是直接來自搜尋索引。
索引完資料後,我們可以對任意欄位進行排序,分組和過濾;向我們的使用者提供提前建議;顯示構面以進行快速過濾;並逐步載入資料以提供無限的滾動體驗。最棒的是,由於所有內容都已快取在Elasticsearch中,因此我們的頁面可以載入得更快。

保持一切最新
僅索引一次資料是不夠的。我們需要確保索引始終是最新的。我們的資料不斷變化-營銷使用者對廣告素材進行編輯,我們的推薦演算法會重新整理以提供最新的標題受歡迎程度排名等。幸運的是,我們有Kafka事件,每次資料變化時都會發出該事件。第一步是聽這些事件並採取相應的行動。
當我們的索引器聽到更改事件時,它需要找到所有受影響的廣告素材並重新索引它們。例如,如果標題排名發生變化,我們需要找到相關的節目,然後找到其對應的廣告素材,並重新為其編制索引。我們可以對所有這些規則進行硬編碼,但是隨著資料的發展以及針對我們構建的每個新索引,我們都需要使這些規則保持最新。
幸運的是,我們可以依靠GraphQL的實體關係來找到需要重新索引的物件。我們的搜尋索引器透過訪問共享的GraphQL模式或使用自省查詢來檢索模式來理解這些關係。

設定
我們建立了所有這些邏輯,用於建立索引,與GraphQL進行通訊以及將更改處理到搜尋索引器服務中。為了設定搜尋索引器,有一些要求:

  1. 卡夫卡。索引器需要知道何時發生更改。我們使用Kafka來處理更改事件,但是任何可以將資料更改通知索引器的系統都足夠。
  2. GraphQL。為了應對變化,我們需要一個支援自省的GraphQL伺服器。該圖有兩個要求。首先,每個頂點必須具有唯一的ID,以使其易於在搜尋步驟中識別。其次,為使扇出正常工作,圖中的邊緣必須是雙向的。
  3. Elasticsearch。資料需要儲存在搜尋資料庫中以便快速檢索。我們使用Elasticsearch,但還有許多其他選項。
  4. 搜尋索引器。我們的索引器結合了以上三個專案。它配置有GraphQL伺服器的終結點,與搜尋資料庫的連線以及從Kafka事件到圖形頂點的對映。


具體詳細點選標題見原文


 

相關文章