Netflix技術博客:服務全球超1.5億用戶的微服務實踐

在全球,Netflix擁有超過1.5億的用戶,因此,創新和速度是我們優先考慮的。這樣才能爲用戶帶來最佳體驗。

這意味着我們的微服務不斷髮展和變化,但不變的是我們的責任。我們有責任提供高可用性服務,這些服務每天向訂閱用戶提供1億小時以上的流媒體內容。

爲實現這種級別的可用性,我們利用了N+1的體系結構。在這種結構中,我們將Amazon Web Services (AWS:亞馬遜的雲服務)上的區域視爲很多的故障域,這種策略允許我們承受單個區域的故障。

在單個獨立的區域發生故障時,我們首先在健康區域對微服務進行規模預擴展,之後我們就可以將流量從那個故障區域轉移出去。

這種預先規模擴展是必要的,因爲我們使用了自動規模擴展的方式,這通常意味着我們提供的區域服務規模正好能夠處理它們區域當前的需求,在區域流量轉移過來之後,它們的流量會增加,原有的服務規模也就可能不夠用了。

雖然我們現在已經有了這種流量疏散能力,但這種彈性並非API一開始就有的。2013年,我們首次開發了多區域可用性策略(multi-regional availability strategy,以防止當年的故障再次發生,並加速了我們重新構建服務運營的進程。在過去6年,Netflix和我們的客戶羣一起不斷地成長和發展,推翻了我們預先擴展微服務能力的核心假設。這兩個假設是:

  • 所有微服務的區域需求(即請求、消息和連接等需求)都可以通過我們的關鍵性能指標(每秒流啓動:stream starts per second,縮寫爲SPS)提取出來。
  • 在流量疏散過程中,可以統一地擴展健康區域內的微服務。

這些假設簡化了預擴展機制,讓我們用統一的方式對待微服務,而忽略了需求的獨特性和區域性。在2013年,由於當時的服務以及客戶羣也相當統一,這種方法運行得很好,但隨着Netflix的發展,這種方法變得不那麼有效了。

無效的假設

區域性的微服務需求

我們的大多數微服務都在某種程度上與服務的數據流相關,因此SPS似乎是簡化區域性的微服務需求的合理方式。對於大型單體服務尤其如此。例如,播放器日誌記錄、授權、許可協議和書籤最初由一個單體服務處理,該服務的需求與SPS高度相關。

然而,爲了提高開發人員的速度、可操作性和可靠性,我們把這個單體服務分解爲更小的、具有不同功能特定需求的服務,這些服務都是爲了某個目標專門構建的。

我們的邊緣網關(zuul)也通過功能分片取得了類似的成績。下圖說明了每個分片的需求、綜合需求和SPS。從綜合需求和SPS線來看,SPS大致相當於一天中大部分時間的綜合需求。但從單個分片來看,使用SPS作爲需求指標而引入的錯誤,其數量差異很大。

Zuul分片在一天中的標準化需求示意圖

統一的疏散擴展方式

由於我們使用SPS作爲需求指標,因此若假定我們可以在健康區域統一地預擴展所有微服務,這個假定看起來似乎也是合理的。爲了說明這種方法的缺點,讓我們看看回放許可(playback licensing:DRM)和授權的情況。

DRM與設備類型密切相關,比如消費電子(CE)、Android和iOS均使用不同的DRM平臺。此外,CE與移動流媒體的比例在區域上存在差異;例如移動端在南美更受歡迎。因此,如果我們把南美的流量轉移到北美,對CE和Android DRM的需求將不會同步增長。

另一方面,回放授權是所有設備在請求許可之前使用的功能。雖然它確實有一些特定的設備行爲,但更主要的是,疏散期間的需求是區域性的需求總體變化的函數。

縮小差距

爲了解決前述方法中的問題, 我們需要更好地描述特定微服務的需求,搞清楚當我們疏散流量時這些需求是如何變化的。前者要求我們捕捉區域對微服務的需求,而不是依賴於SPS。後者需要更好地理解按設備類型劃分的微服務需求,以及疏散過程中跨區域設備需求的變化。

特定微服務的區域性需求

因爲服務是不統一的,我們知道了使用諸如SPS這樣的代理需求指標是站不住腳的,我們需要針對特定微服務的需求指標。不幸的是,由於服務的多樣性,其混合了Java(帶有Ribbon/gRPC的Governator/Springboot等)和Node (NodeQuark),我們無法依賴單個需求指標來覆蓋所有的用例。爲了解決這個問題,我們構建了一個系統;對每個微服務,該系統都允許我們將其關聯到能代表其需求的指標上。

微服務指標是配置驅動的、自服務的,並且允許確定範圍,這樣的話可以讓微服務在不同的分片和區域之間具有不同的配置。然後我們的系統查詢Atlas(這是我們的時間序列遙感勘測平臺)以收集所需要的歷史數據。

按設備類型劃分的微服務需求

由於區域性的設備偏好會影響需求,我們需要解析微服務需求,以揭示特定於設備的組成部分。我們採用的方法,是根據聚合的設備類型(CE、Android、PS4等)劃分微服務的區域需求。

不幸的是,現有的指標不能統一地揭示出按設備類型劃分的需求,所以我們利用分佈式跟蹤來揭示所需的詳細信息。使用這些採樣得到的跟蹤數據,我們可以解釋微服務的區域設備類型需求如何隨時間變化。下圖突出顯示了某個微服務的相對設備需求在一天中的變化情況。

按設備類型劃分的區域性微服務需求

設備類型的需求

我們可以使用以前的設備類型流量,來了解如何擴展服務需求的組成部分,這些組件都是特定於設備的。例如,下圖顯示了當我們疏散us-west-2的流量時,us-east-1中的CE流量是如何變化的。

將nominal traffic線和evacuation traffic線進行標準化,使1表示最大(nominal traffic),需求擴展比例表示疏散過程中需求的相對變化(即evacuation traffic/nominal traffic)

在US-East-1區域中,Nominal vs Evacuation CE流量

特定於微服務的需求擴展比例

我們現在可以將按設備劃分的微服務需求,和特定於設備的疏散擴展比例組合起來,從而更好地表示疏散過程中微服務區域需求的變化——即微服務的設備類型加權的需求擴展比例。

爲了計算這個比率(一天中的特定時間),我們取服務的設備類型百分比,乘以設備類型疏散擴展比例,生成每種設備類型對服務的擴展比例的貢獻。將這些組成部分相加,就得到微服務的設備類型加權疏散擴展比例。爲了提供一個具體的示例,下表顯示了一個虛構的服務的疏散擴展比例計算。

服務疏散擴展比例計算

下圖突出顯示了,使用特定於微服務的疏散擴展比例,與之前使用的基於SPS的簡化方法的影響對比。在服務A的情況下,舊的方法可以很好地逼近這個比率,但在服務B和服務C的情況下,舊的方法將分別導致預測需求過高和過低。

設備類型加權與以前的方法

接下來做什麼?

對微服務需求獨特性的理解提高了我們的預測質量,並以額外的計算複雜性爲代價實現了更安全、更有效的疏散。然而,這種新方法本身就是一種近似,它也帶有自己的一組假設。

例如,它假設設備類型的所有類別的流量(例如Android日誌記錄和回放流量)都具有相似的形狀。隨着Netflix的發展,我們的假設將再次受到挑戰,我們必須適應,繼續爲客戶提供他們所期望的可用性和可靠性。

原文鏈接:

Evolving Regional Evacuation

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章