Cloud Pub/Sub:Google 級訊息傳遞服務

總覽

Cloud Pub/Sub 是高度穩定且可擴充的一種非同步訊息傳遞服務。這項服務採用核心 Google 基礎架構元件建立而成,許多 Google 產品十多年來都以這個基礎架構元件為基礎。在這個基礎架構之上,Google 產品 (包括廣告、搜尋與 Gmail) 每秒可傳送 5 億多則訊息,總計 1 TB 以上的資料。Cloud Pub/Sub 之所以能夠穩定處理這麼大規模的資料,背後有一些重要的設計,詳見下文的說明。

發佈/訂閱服務的基本概念

Cloud Pub/Sub 是一種「發佈/訂閱 (Pub/Sub) 服務」:將訊息傳送者與訊息接收者分離的訊息傳遞服務。Pub/Sub 服務中有幾個重要概念:

  • 「訊息」:在服務中移動的資料。

  • 「主題」:一種具名實體,代表訊息來源。

  • 「訂閱項目」:一種具名實體,代表接收特定主題相關訊息的意願。

  • 「發佈者」(也稱為生產端):可建立訊息並將訊息傳送 (發佈) 至特定主題的訊息傳遞服務。

  • 「訂閱者」(也稱為消費端):可接收指定訂閱項目的訊息。

下圖摘列了 Cloud Pub/Sub 中的訊息基本流程:

在這個案例中,兩位發布者針對同一個主題發布了訊息。這個主題有兩個訂閱項目。第一個訂閱項目有兩位訂閱者,這表示訊息會在這兩者間進行負載平衡,而每位訂閱者會收到部分訊息。第二個訂閱項目則有一位訂閱者,這位訂閱者可接受所有訊息。粗體字母代表訊息。訊息 A 來自發佈者 1,並會透過訂閱項目 1 傳送至訂閱者 2,透過訂閱項目 2 傳送至訂閱者 3。訊息 B 來自發佈者 2,並會透過訂閱項目 1 傳送至訂閱者 1,透過訂閱項目 2 傳送至訂閱者 3。

判斷訊息傳遞服務的效能

如要判斷 Cloud Pub/Sub 等訊息傳遞服務的效能,可從三個方面著手:擴充性、可用性與延遲時間。這三個因素通常彼此不一致,需要在其中一個因素上做出讓步才能改善其他兩個因素。

「擴充性」、「可用性」與「延遲時間」這三個詞可能對應至系統中的不同屬性,因此下列各節將說明它們在 Cloud Pub/Sub 中的定義。

擴充性

可擴充的服務應能處理增加的負載,不會在延遲或可用性方面大幅退化。「負載」可能代表 Cloud Pub/Sub 之中各種不同的使用維度:

  • 主題數

  • 發佈者數

  • 訂閱項目數

  • 訂閱者數

  • 訊息數

  • 訊息大小

  • 發佈或讀取訊息的速率 (總處理量)

  • 任何指定訂閱項目的待處理作業大小

可用性

在分散式系統中,問題的類型與嚴重性可能會有很大不同。系統針對不同類型問題的處理成效、能否以使用者注意不到的方式順暢地進行容錯移轉,就成了系統可用性的評估依據。故障可能是因硬體 (如硬碟無法運作網路連線能力問題) 和軟體造成,也可能是由負載引起。當服務 (或在相同硬體中執行的其他軟體元件,或軟體依附元件) 流量激增導致資源不足時,即會發生由負載引起的故障。建立或部署軟體或設定時的人為疏失也可能會降低可用性。

延遲時間

延遲時間這項因素可讓您從時間層面測量系統的效能。服務通常會想要儘可能地將延遲時間降到最低。針對 Cloud Pub/Sub,兩個最重要的延遲時間指標為:

  1. 確認已發佈訊息花費的時間。

  2. 將已發佈訊息傳送至訂閱者花費的時間。

Cloud Pub/Sub 基本架構

本節將說明 Cloud Pub/Sub 的設計,讓您瞭解該服務如何在保持可用性的同時,仍能具備擴充性與低延遲時間。系統設計為「可水平擴充」,也就是在主題、訂閱或訊息數增加時,可增加運作中伺服器執行個體的數量加以因應。

Cloud Pub/Sub 的伺服器分散於世界各地的多個 Google 資料中心。每個資料中心都包含一或多個「叢集」執行個體;叢集是機器邏輯群組,當中的機器一般會共用相同的故障網域 (例如,共用區域網路與共用電源)。Cloud Pub/Sub 是一種「全球服務」:用戶端並不知道任何伺服器或資料的實際位置 (或資料中心位置),且可從世界任一處進行發佈及訂閱,發佈作業的目標與訂閱項目的來源也不受地理位置限制。

Cloud Pub/Sub 分為兩大部分:「資料層」負責處理發佈者與訂閱者之間訊息的移動;「控制層」則處理發佈者與訂閱者指派至資料層伺服器的操作。資料層中的伺服器稱為「轉寄站」,而控制層中的伺服器稱為「路由器」。當發佈者與訂閱者連線至指派的轉寄站時,不需要路由器的任何資訊 (只要這些轉寄站保持連線即可)。因此,您可以在不影響已連線且正在傳送或接收訊息的任何用戶端的情況下,升級 Cloud Pub/Sub 的控制層。

控制層

Cloud Pub/Sub 控制層能夠採用為所有用戶端提供擴充性、可用性與低延遲時間的方式,將用戶端分配到轉寄站。針對任何主題或訂閱,所有轉寄站都可為用戶端提供服務。當用戶端連線至 Cloud Pub/Sub 時,路由器可根據最短的「網路距離」(對兩點之間連線延遲時間進行測量),來決定用戶端應連線的目標資料中心。在任何指定的資料中心內,路由器都會嘗試將總負載分配至整個可用轉寄站集。執行這項作業時,路由器必須平衡兩個不同的目標:(a) 負載的統一性 (即最好均等載入每個轉寄站);與 (b) 指派作業的穩定性 (即負載變更或可用轉寄站集變更時,受影響的現有指派作業越少越好)。透過 Google 研究團隊開發的一種一致性雜湊演算法,路由器得以在一致性和統一性間達到可微調的平衡。路由器會向用戶端提供一份清單,依序列出適合連線的目標轉寄站。這份排序清單可能會根據轉寄站可用性與用戶端負載型態而發生變更。

用戶端會依據這份清單連線至其中的一或多個轉寄站。用戶端一般會優先連線至路由器最推薦的轉寄站,但也會考慮過去發生的任何故障情況,例如,如果經過數次嘗試均無法順利連線至距離最近的轉寄站,它可能會決定嘗試連線至不同資料中心的轉寄站。為了讓 Cloud Pub/Sub 用戶端不受這些實務細節影響,系統在用戶端與轉寄站之間設有一個服務 Proxy,用來代表用戶端執行這個連線最佳化的作業。

資料層 - 訊息的生命週期

資料層會接收發佈者的訊息,並將訊息傳送至用戶端。瞭解 Cloud Pub/Sub 資料層最好的方法可能是,查看從服務收到訊息開始,到訊息不再顯示於服務中為止的訊息生命週期。讓我們來追蹤處理訊息的步驟。為實現本節的目的,我們假設發佈訊息的主題已附加至少一個訂閱項目。一般而言,訊息會經過下列步驟:

  1. 發佈者傳送訊息。

  2. 將訊息寫入儲存空間。

  3. Cloud Pub/Sub 傳送確認給發佈者,表明它已收到訊息,並保證會將訊息傳送至所有附加的訂閱項目。

  4. 在將訊息寫入儲存空間的同時,Cloud Pub/Sub 會將訊息傳送至訂閱者。

  5. 訂閱者傳送確認給 Cloud Pub/Sub,表明他們已處理訊息。

  6. 在每個訂閱項目至少有一位訂閱者確認訊息之後,Cloud Pub/Sub 會從儲存空間中刪除訊息。

首先,發佈者會將主題的訊息傳送至 Cloud Pub/Sub。Proxy 層會對訊息進行加密並傳送至發佈轉寄站,即發佈者連線的目標轉寄站。為了確保傳送,會將訊息立即寫入儲存空間。轉寄站一開始會將訊息寫入 N 個叢集 (其中 N 為奇數),並在將訊息寫入至少 ⌈N/2⌉ 個叢集時,將訊息視為常駐。在訊息為常駐之後,發佈轉寄站會重新向發佈者發送確認,表明已收到訊息,屆時,Cloud Pub/Sub 會保證將訊息傳送至所有附加的訂閱。背景程序會將不在所有 N 個叢集中的任何訊息定期寫入遺失訊息的叢集。

在每個叢集內,都會將訊息寫入 M 個獨立磁碟 (其中 M 為奇數),且資料必須位於 ⌈M/2⌉ 個磁碟上,才能視為在該叢集中常駐。至少要將任何發佈的訊息寫入共 ⌈N/2⌉ 個叢集中的 ⌈M/2⌉ 個獨立磁碟才能視為常駐,並最終複製到 N*M 個磁碟。

發佈轉寄站擁有附加至主題之所有訂閱的清單。您有責任保留發佈的訊息,以及說明每個訂閱項目已確認哪些訊息的中繼資料。針對特定主題發佈轉寄站所接收及儲存的訊息集,以及對確認訊息的追蹤,統稱為「發佈訊息來源」。根據主題的總處理量需求,單一發佈者可能會將訊息傳送至多個發佈轉寄站,並將訊息儲存在多個發佈訊息來源中。相同主題的不同發佈者也可能會將訊息傳送至不同的發佈轉寄站。每則訊息都只會傳送至一個發佈轉寄站。Cloud Pub/Sub 會在總處理量變更時,動態調整接收特定主題訊息的發佈轉寄站數。

訂閱者可透過連線至訂閱轉寄站 (將訊息從發佈者傳送至訂閱者的轉寄站) 來接收訊息。若為提取訂閱者,「連線」就表示發出提取要求。若為推送訂閱者,「連線」就表示向 Cloud Pub/Sub 註冊推送端點。建立訂閱項目即保證會將之後發佈的任何訊息都傳送至該訂閱項目,我們將這稱為同步處理點保證。

每個訂閱轉寄站都需要從擁有主題發佈訊息來源的發佈轉寄站要求訊息。與發佈者相同,訂閱者也可以連線至多個訂閱轉寄站來接收訊息。如此一來,並非每個訂閱轉寄站都需要瞭解或接收來自主題的每個發佈訊息來源的訊息,而這是 Cloud Pub/Sub 能夠水平擴充的一個重要屬性。根據傳送至訂閱者的訊息總處理量,Cloud Pub/Sub 會在總處理量變更時,動態調整訂閱者接收特定主題訊息的訂閱轉寄站數。

訂閱轉寄站會向擁有主題發佈訊息來源的一或多個發佈轉寄站提出要求,要求它們提供需要的訊息。發佈轉寄站會將未確認的訊息傳送至訂閱轉寄站,然後訂閱轉寄站會將訊息轉發給訂閱者。

訂閱者處理完訊息之後,會重新向訂閱轉寄站傳送確認。訂閱轉寄站會將這份確認轉發給發佈轉寄站,進而將確認儲存在發佈訊息來源中。在主題的所有訂閱均已確認訊息之後,會以非同步的方式將訊息從發佈訊息來源與儲存空間中刪除。

由於在將訊息從發佈者傳送至訂閱者時涉及到數次連線,因此訊息的生命週期相當複雜。在發佈者、訂閱者與轉寄站之間透過連線傳送訊息的方式如下:

啟動並執行 Cloud Pub/Sub

確保像 Cloud Pub/Sub 之類的分散式系統可以持續運作,並為所有客戶有效提供服務,需要非常清楚地瞭解系統並且能夠控制系統。維護服務是我們網站可靠性工程師 (SRE) 的責任。Cloud Pub/Sub 工程師分布在世界各地,提供全年無休的支援服務。

環境

Cloud Pub/Sub 這類系統的維護作業的第一個部分,就是在客戶使用軟體之前對軟體進行測試。為了實現這個目的,Cloud Pub/Sub 提供三個環境:測試、準備和實際執行。測試和準備不包含任何客戶流量;它們僅包含我們持續運作的測試與監控來協助找出版本的任何問題。這兩個環境會在實際執行之前收到軟體的新版本。測試與準備之間的差異在於,後者完全複製了實際執行環境中現有或即將發佈的內容,其中包括軟體版本與指令列標記。其中前者所啟用的功能,可能正由開發人員進行處理,並規劃在未來發佈。

發佈

推出及測試 Cloud Pub/Sub 的程序在設計上希望將潛在影響降到最低。讓我們來看看推出 Cloud Pub/Sub 新版本的一般步驟:

  1. 確保通過所有單元測試與整合測試。

  2. 建立所有伺服器的新版本。

  3. 將新伺服器部署至測試與準備環境。

  4. 在測試與準備環境中執行伺服器數天時間。

  5. 如果沒有已知問題,請將伺服器發佈為 Canary 版,即擁有少量客戶流量的實際執行環境子集。

  6. 如果在 Canary 版中未偵測到問題,請在幾天時間內將伺服器逐步推出至更多的實際執行環境中,直到將伺服器發佈到所有位置為止。

由於 Cloud Pub/Sub 擁有絕佳的復原能力 (例如透過區隔控制層與資料層),因此客戶可以順暢轉換至新推出的伺服器版本,且他們眼前的效能也不會受到任何影響。

監控

啟動並執行 Cloud Pub/Sub 的關鍵在於,在客戶發現問題之前,自動偵測並解決問題。完成這項工作需要對系統進行嚴密監控。SRE 可維護一組「服務水準指標」(SLI),即說明系統行為之明確定義指標。指標可能包含「完成 CreateSubscription 要求花費的時間」或「發佈要求產生的錯誤率」。這些指標會以各種方式測量。其中一些完全是我們轉寄站與路由器的內部項目。例如,它們會測量將訊息寫入磁碟花費的時間。共有十個 SLI 與數百個其他指標用於監控 Cloud Pub/Sub 的運作狀態。

所有這些測量都有助於定義內部「服務水準目標」(SLO),即 SLI 的特定目標。例如,「完成 CreateSubscription 要求不應花費超過五秒鐘的時間」。若發生違反 SLO 的情況,SRE 會收到通知,且必須在五分鐘內採取相關行動。

「服務水準協議」(SLA) 會列出 SLO,其中定義我們向客戶保證的效能,以及我們未達保證效能時的後果。請參閱 Cloud Pub/Sub 服務水準協議

我們維護了一組稱為「探測器」的工作,這組工作會如用戶端一般運作,且預期會進行發佈及訂閱作業。資料層與控制層都存在探測器。我們共有十種類型的探測器,每一種都會像客戶一樣執行特定動作,並會測量作業花費的時間。例如,其中一個探測器會建立新訂閱項目、發佈訊息,並查看建立訂閱項目及接收訊息花費的時間。如果探測器判斷出三十個測量指標中的任何一個與預期不同,SRE 就會收到通知。

我們伺服器與探測器的指標摘要列於數個內部資訊主頁中,而這是 SRE 在診斷潛在問題時第一個查看的位置。這些頁面可讓您快速存取整個服務的統計資料與圖表,如下圖所示。您也可以依照主題、資料中心或個別工作對它們進行劃分。

服務使用者最感興趣的指標會透過 Google Cloud Monitoring 呈現。事實上,甚至我們自己的探測器也會顯示像以下這樣的圖表:

控制方式

我們可以利用多種控制方式來協助調整 Cloud Pub/Sub 的效能。其中一些控制方式的設計有助於處理資料中心或機器的服務中斷情形。我們可以對一些或全部主題設定「轉送限制」,即指定可以且/或無法連線至轉寄站集之用戶端集的規則。我們可以使用轉送限制來從無法如預期般運作的個別轉寄站工作或整個資料中心排除流量。

我們擁有的另一項可微調功能是流量控制。這項功能允許我們在防止服務發生超載時,最大化總處理量。流量控制是一種流量成形方式,透過此方式可以隨時間消除負載中非預期的突然激增,以獲得更好的服務穩定性。流量控制可在整個系統中或根據各主題或各訂閱者運作,來限制已轉移或未解決的訊息數或位元組數。在這種情況下,「未解決」表示已傳送至用戶端,但尚未確認。透過流量控制與轉送限制,我們得以最佳化 Cloud Pub/Sub 的效能,也讓客戶免於處理這些低層級的運作細節。

摘要

Cloud Pub/Sub 等服務在擴充性、可用性與延遲時間方面的優點,定義了該類產品的價值主張,可用來吸引考慮移至代管雲端服務的客戶。任何非同步訊息傳遞服務都必須在考慮這些功能的情況下,從頭開始建立。Cloud Pub/Sub 小組擁有可靠、快速傳送許多訊息十多年的經驗,所創立及維持的服務能夠符合 Google 大多數基礎產品的要求。現在,世界上想傳送訊息的所有外部客戶都可以使用這項服務,而不必擔心他們的訊息傳遞系統是否有能力可以處理目前負載 2 倍、10 倍或 100 倍的負載。

詞彙

詞彙 說明
叢集 一般共用相同故障網域 (例如,共用區域網路與共用電源) 的機器邏輯群組。
控制層 Cloud Pub/Sub 層級,處理發佈者與訂閱者指派至資料層伺服器的操作。
資料層 Cloud Pub/Sub 層級,處理發佈者與訂閱者之間的訊息移動。
轉寄站 資料層中的伺服器。
全球服務 用戶端不必瞭解或指定連線地區 (或資料中心) 就可以使用此項服務。
可水平擴充 透過增加服務元件執行個體數來順暢處理更多負載的服務能力。
訊息 在 Cloud Pub/Sub 中移動的資料。
網路距離 對兩點之間連線延遲時間的測量。
探測器 如用戶端一般運作並預期會對 Cloud Pub/Sub 伺服器執行一或多個動作的工作。
發佈訊息來源 發佈轉寄站接收及儲存的訊息集,以及所有附加訂閱確認的訊息 ID 集。
發佈/訂閱 (Cloud Pub/Sub) 服務 將訊息傳送者與訊息接收者分離的訊息傳遞服務。
發佈者 建立訊息並將訊息傳送 (發佈) 至指定主題中的 Cloud Pub/Sub 用戶端。
路由器 控制層中的伺服器。
轉送限制 規則清單,表示應該或不應該由路由器傳送至用戶端做為可能連線端點的轉寄站。
服務水準協議 (SLA) SLO 的清單,定義向客戶保證的系統效能並概要說明不符合條件時的後果。
服務水準指標 (SLI) 說明系統行為之明確定義的指標。
服務水準目標 (SLO) 服務水準指標的特定目標。
訂閱者 接收指定訂閱中訊息的 Cloud Pub/Sub 用戶端。
訂閱 表示對接收特定主題中的所有訊息感興趣的已命名實體。
同步處理點保證 建立訂閱者的時間,在此之後發佈的所有後續訊息都會傳送至該訂閱者。
主題 一種具名實體,代表訊息來源。
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Pub/Sub