Uber在微服務架構中如何利用多租戶玩轉生產現場測試？

banq發表於2020-03-19
微服務架構

在面向租戶的微服務體系結構中，將租戶上下文如tenant-id附加到傳入請求，並在請求的整個生命週期中傳播該上下文，這使使用者能夠基於該上下文路由請求。當請求呼叫鏈中任何服務收到請求時，某些服務可能會評估請求上下文以繞過某些業務邏輯。例如，驗證使用者電話號碼的稽核服務可能希望繞過測試流量的檢查，因為測試請求中涉及的使用者是測試使用者。此外，透過交易處理服務執行測試流量時，需要與銀行閘道器進行通訊以為使用者轉移資金，我們可能希望將銀行閘道器存根，或者與銀行的登臺閘道器（如果可以進行測試）進行通訊，以便防止任何真實的資金轉移。
當然，可以使用諸如OpenTracing和Jaeger之類的開源工具來實現租用上下文傳播，但是這些工具可以以某種語言和傳輸不可知的方式進行分散式上下文傳播。
租戶上下文如tenant-id還應傳播到其他傳輸中的資料物件，例如Apache Kafka訊息傳遞佇列中的訊息。較新版本的Kafka支援新增標頭，並且可以使用開源跟蹤工具向訊息新增上下文。對於像Kafka這樣的訊息傳遞佇列系統，我們可以透明地為某個tenant-id推出一個新主題，也可以為tenant-id專門分配一個單獨的Kafka叢集。
透過租戶上下文如tenant-id可以隔離資料儲存，劃分不同資料庫，一種是真正生產資料庫，另外一種是用於生產測試資料庫，或金絲雀階段的資料庫。
每個基礎架構元件都可以理解租期並能夠基於tenant-id路由隔離流量，從而允許在我們的平臺內進行更大的控制以執行不同的微服務，例如度量和日誌。微服務架構中使用的典型基礎架構元件是日誌記錄，指標，儲存，訊息佇列，快取和配置。根據其tenant-id隔離資料需要分別處理基礎結構元件。這有助於開發人員根據tenant-id進行篩選，這可能有助於避免錯誤警報或防止啟發式或訓練資料出現偏差。
Uber的多租戶實施帶來了各種好處，例如使程式碼自動釋出和配置安全，從而提高了開發人員的速度。多租戶架構的隔離保證使Uber可以出於各種目的（包括測試流量）重新利用同一微服務堆疊。
banq注：雖然多租戶帶來靈活方便，但是常在河邊走哪有不溼腳？將設計開發測試推遲到生產實施階段，風險異常放大。

相關文章