電子郵件API服務供應商Mailgun開源了Gubernator,這是一個原生雲端分散式速率限制微服務,官方提到,微服務架構可以在不影響服務獨立性的情況下,提供通用速率限制服務。

當客戶端或服務,向Gubernator發出速率限制請求的時候,請求會被賦予鍵值,並應用雜湊演算法,決定出速率限制請求的擁有節點(Owner)。官方提到,選擇單一節點來處理速率限制較為快速,且能避免分散式計數帶來的複雜性以及延遲。

而客戶端的每個請求都會帶有速率限制配置,速率限制的配置便會與現階段速率限制狀態,一起被存在速率限制擁有節點的本地記憶體中,這些配置具有時效性,當時限到期且沒有再次收到速率限制配置,配置便會從快取中被刪除。

Gubernator的架構被設計成,適合在同儕分散式叢集中運作,其利用記憶體快取所有當前階段啟用的速率限制,Gubernator無狀態,沒有資料會被同步至磁碟中,官方提到,多數網路速度限制持續的時間只有數秒中,因此當重新啟動或是計畫性停機,而使得記憶體內資料丟失,並不是大問題,對於Gubernator來說,也僅是幾秒鐘的時間,一小部分的流量可能發生過度請求的狀況。

Gubernator可以均勻的分散速率限制請求到整個叢集,也就是說,用戶只要為叢集增加一個節點,就能簡單地擴展系統,Gubernator不依賴Memcache或是Redis等外部快取,也不會在磁碟上儲存狀態,其配置來自客戶端傳遞請求,並且能支援極高吞吐量的應用。

之所以不使用Redis的原因,官方解釋,Redis用在速率限制的最佳解決方案,是在Redis上儲存一個速率限制腳本,每次速率限制請求都呼叫該腳本,大部分的工作都會由Redis完成,速率限制微服務只是作為存取Redis的代理。而以Redis實作速率限制功能,將會產生額外的流量,因為每次單一請求,都會產生至少一次往返Redis的存取,而速率限制微服務也需要至少存取Redis一次,因此會在服務中增加至少兩次的存取往返。

Gubernator能夠處理高吞吐量的請求,官方提到,在正式生產環境中,他們為請求API服務設下兩個速率限制條件,一個是HTTP請求速率,另一個則是用於評估用戶在特定時間內,用戶發送電子郵件的收件人數量,單個Gubernator節點每秒可以處理超過2,000次請求,大多數都在1毫秒內回應。

Mailgun也提到,當用戶使用Go語言,也能把Gubernator當作函式庫使用,並在頂層使用自有特定模型的速率限制服務,這樣不只能使用Gubernator的功能,還可以將商業邏輯分開,並整合專門領域問題到速率限制服務中。

熱門新聞

Advertisement