Zanzibar 是 google 開發和部署的一個全球授權系統，用于評估全球用戶對 google 數百個應用的訪問權限（包括：Calendar, Cloud, Drive, Maps, Photos, YouTube等）。目前已經存儲了上萬億條 ACL（access control list），每秒鐘處理來自數十億用戶的數百萬個請求，并且在過去的三年里做到了將 95% 分位的請求響應時延控制在 10ms以內，系統的可用性大于99.999%。能夠處理“每秒超過 1000 萬個客戶端查詢”，但要實現這一目標，還有很多工作需要。

應用程序權限簡史

有多種方法可以向應用程序添加權限。最常見的方法是為構建的每個應用程序創建臨時實現。對于動態權限，例如最終用戶可以授予的權限，這通常在源代碼中表現為解釋存儲在數據庫中的行。此代碼最終成為每個請求的關鍵部分，非常敏感，并且編寫起來可能很棘手。此代碼中的錯誤很容易導致應用程序中出現安全漏洞和漏洞。為了最大限度地減少所編寫的代碼的外圍區域和大量代碼，此代碼通常被抽象到一個庫中，該庫可以在許多此類應用程序之間共享。

一些公司有一個通用的授權庫，每當需要在其所有應用程序和服務中調用權限代碼時，他們都會重復使用該庫。這是 Google 在決定構建和部署Zanzibar 之前使用的方法。通常，這些庫通過將它們放在 IPC 接口后面而變得更加通用和與編程語言無關，然后采用策略引擎的形式。然而，庫和策略引擎在這種情況下有一個主要缺點：它們是無狀態的。庫和策略引擎的實現都要求它們獲得策略和全套所需數據，然后將它們組合起來以做出權限決策。對于標準 Web 應用程序，這意味著加載表示關系的數據庫行，并在每個權限決策時將它們傳遞給引擎。

由于此限制，下一個合乎邏輯的步驟是開始將與決策相關的信息存儲在權限引擎可直接訪問的位置。 現在，當需要做出權限決策時，應用程序只需向權限系統詢問它已經可以訪問的策略和數據。 例如，如果服務已經知道我是一篇文章的作者，并且應該允許作者編輯自己的文章，那么它已經擁有回答問題所需的所有信息：“杰克是否允許編輯這篇文章？ 這確實意味著您需要不斷“教導”權限系統有關用戶與數據之間關系的更改。 另一方面，權限系統實際上可以成為這些關系的唯一規范存儲！ 當您將其作為權限服務實現時，它會解鎖許多非常強大的屬性。

谷歌Zanzibar 是這種服務的實現，谷歌提出了一個強有力的案例，說明為什么在服務中計算權限的屬性對谷歌很重要。

為什么需要谷歌Zanzibar ？

在Zanzibar 的論文中，谷歌列出了決定他們將從權限服務中受益的許多原因。 首先，作為一項服務，他們已將代碼重復和版本偏差的數量減少到最低限度。 其次，谷歌擁有大量的應用程序和服務，他們經常需要檢查來自一個應用程序在另一個應用程序中的資源之間的權限。 例如，當您使用 Gmail 發送電子郵件并警告您收件人無法閱讀電子郵件中鏈接的文檔時，這有效，因為 Gmail 正在向Zanzibar 詢問鏈接的 Google 文檔的權限。類似的授權請求也發生在日歷、云端硬盤、地圖、照片、YouTube 等。 第三，谷歌在權限系統之上構建了通用基礎設施，只有當你有一個一致的 API 來編程時，你才能做到這一點。 最后，也是最重要的一點，權限很難。

人們希望任何權限實現都遵守一些常見要求。 首先，它應該是正確的。 有了權限，就很容易定義正確性。 所有授權用戶都應能夠與受保護的資源進行交互，并且不應允許未經授權的用戶與受保護的資源進行交互。 起初這似乎很容易，直到您開始考慮計算機（尤其是大規模托管應用程序）必須應對的挑戰。 例如網絡和復制延遲、節點故障和時鐘同步。

其次，如果您要對所有事情使用一個權限系統，它應該合理地允許您對應用程序所需的所有不同類型的基元進行建模。 就 Google 而言，它們至少具有以下權限模型：文檔中的點對點共享、YouTube 中的公開/私密/不公開視頻以及 Cloud IAM 中的 RBAC。 Google Zanzibar 足夠靈活，可以對不同類型的權限進行建模。

因為您通常需要檢查每個請求的權限，并且未能收到肯定的權限檢查成功必須解釋為拒絕（失敗關閉），因此您需要此系統具有高度的可靠性和速度。

最后，隨著 Google 的運營規模極大，Google Zanzibar 還必須擴展到每秒數百萬個授權請求，跨數十億用戶和數萬億個對象。

對開發人員來說，Google 桑給巴爾是什么？

Google Zanzibar 的核心是一個全球分布式授權系統，能夠處理“每秒超過 1000 萬次客戶端查詢”，但從開發人員的角度來看，它是一個 API。該 API 允許您外包用戶和數據關系，然后讓您在訪問點快速準確地做出權限決策。例如，當新用戶注冊時，您告訴 Google Zanzibar。當該用戶創建受保護的資源（例如文檔、視頻或銀行帳戶）時，您告訴 Zanzibar。當該用戶與其他用戶共享資源或創建相關資源時，您告訴 Zanzibar。最后，當需要回答以下問題時：“是否允許 X 讀取/寫入/刪除/更新 Y？”，桑給巴爾已經擁有快速回答問題所需的所有信息。

Zanzibar計算權限的方式有些新穎。 應用程序開發人員寫入服務的關系信息用于構建用戶、其他實體和資源之間關系的有向圖表示形式。 一旦此圖可用，權限檢查就變成了一個圖遍歷問題。 我們試圖通過圖表找到從請求的資源和關系（例如所有者、讀取者等）到用戶（通常是發出請求的用戶）的路徑。

通常，一種關系意味著其他關系。 例如，如果允許用戶寫入一條數據，則幾乎（但并非總是）意味著他們也可以讀取相同的數據。 為了減少必須存儲的冗余信息量，Zanzibar提供了一種稱為關系重寫的機制，該機制描述了一種重新解釋圖中某些邊緣和關系的方法。 重寫的另一個示例是說：“嵌套文檔所在文件夾的讀者也應被視為文檔的讀者。以這種方式消除冗余信息的過程更正式地稱為規范化。

到目前為止，我們只討論了如何檢查權限，但現在我們有了應用程序中所有實體的規范化圖版本，我們還可以對這些數據執行其他作，Zanzibar也公開了這些概念的 API。 在Zanzibar的論文中，第 2.4.1 和 2.4.5 節描述了讀取和擴展 API，它們允許直接查詢圖數據，從而允許基于存儲的數據構建 UI 和下游進程。 第 2.4.3 節描述了監視 API，它可用于通知底層圖數據的更改，這是 Zanzibar 實現中描述的一些性能改進的基礎。

本文中最后一個面向開發人員的部分是 Zookies。 Zookies（大概是Zanzibar和 cookie 的合成詞）允許開發人員為允許的數據過時性設置下限。 這里的主要見解是，通過允許將稍微過時的數據用于常見權限檢查，可以大大提高這些作的性能。 在某些情況下，您絕對不希望在計算權限時使用過時的數據，在這些情況下，您可以通過顯式指定 Zookie 來強制 Zanzibar 使用更新的數據。 如果您想了解更多關于 Zookies 以及它們如何強制保持一致性的信息，通過原子方式將代表用于保護特定版本內容的確切權限的令牌與內容本身組合在一起，我們可以確保將來用于檢查對該內容的訪問權限的權限至少與創建內容時的權限一樣新鮮。

具體來說，Authzed 允許人們在發出權限檢查請求時傳遞 Zookie，并保證用于計算答案的策略和單個關系至少與所呈現的 Zookie 要求一樣新鮮。 現在，每次內容更新時，我們的代碼大致遵循以下偽代碼約定：

def write_content(user, content_id, new_content): is_allowed, zookie = authzed.content_change_check(content_id, user) if is_allowed: storage.write_content(contentd_id, new_content, zookie) return success return forbidden

在訪問數據時，我們使用以下偽代碼：

def read_content(user, content_id): content, zookie = storage.get_content(content_id) is_allowed = authzed.check(content_id, user, zookie) if is_allowed: return content return forbidden

現在我們已經熟悉了Zanzibar 的 API，讓我們來看看Zanzibar 是如何實現的，以實現大規模的低延遲。

谷歌Zanzibar 是如何實施的？

由于這項服務不斷被訪問，并且處于處理請求的關鍵路徑中，因此它必須速度很快。對于 Google 的Zanzibar ，檢查請求的第 50 個和第 99 個百分位延遲分別為 3 毫秒和 20 毫秒，同時在峰值時每秒提供來自世界各地的 1240 萬個權限檢查和讀取請求。Zanzibar 如何實現如此低延遲和高規模？

通過運行Zanzibar 服務器的許多副本來實現高規模：

Zanzibar 將這種負載分布在全球數十個集群中的 10,000 多臺服務器上。每個集群的服務器數量從不到 100 臺到超過 1,000 臺不等，中位數接近 500 臺。集群的大小與其地理區域的負載成比例。

全球分發是通過使用 Google 的全球規模數據庫系統 Spanner 來處理的。借助 Spanner，寫入地球上任何地方的數據可以立即獲得，并且外部一致。雖然這些屬性非常適合權限系統的存儲層，但這并不意味著存儲在 Spanner 中的數據在Zanzibar 的延遲要求范圍內可用。F1（Google 的另一項服務）從 Spanner 感知到的讀取延遲在中位數為 8.7 毫秒，標準差為 376.4 毫秒。Zanzibar 通常必須對數據存儲進行多次往返才能計算一次權限檢查。顯然，如果沒有一些嚴重的緩存，它就無法實現 20 毫秒的 99.9 個百分位延遲。

Zanzibar 在服務的多個層都有緩存。 緩存的第一層位于服務級別。 當服務收到最近計算的權限檢查請求時，該請求的結果仍可被視為有效（這意味著計算它的時間不早于傳遞的 Zookie），可以直接返回該值。 這消除了對數據存儲的所有往返。 服務級別緩存是提高性能的有效方法，但以Zanzibar 的運營規模而言，它本身并沒有多大幫助。 如果允許從任何緩存提供任何請求，流經Zanzibar 的龐大數據量將導致非常低的命中率或令人望而卻步的內存要求。

為了提高命中率，Zanzibar 使用一致的哈希將請求（以及生成的緩存條目）分發到特定服務器。 我們從中獲得的第一個好處是緩存的命中率要高得多。 如果我們期望特定類型的請求僅由Zanzibar 副本的一小部分提供服務，那么我們更有可能在緩存中擁有該值。 這提供的第二個也是更微妙的改進是允許合并重復的請求，并且該值僅計算一次并返回給所有調用者。 在本例中，我們攤銷所有重復數據刪除請求的后端數據存儲往返。

Zanzibar 執行的服務器端緩存的最終形式是特定于 Google 用例的一種特殊非規范化。 當工程師注意到組（如 Docs、Cloud IAM 和產品組所使用）通常嵌套很深時，他們創建了一個名為 Leopard Indexing System 的服務。 Leopard 保留所有組的內存中傳遞閉包，這些組是更高級別組的子組。 默認情況下，Zanzibar 的嵌套關系需要向后備 Spanner 數據庫發出多個串行請求，因為您需要先加載直接子級，然后才能計算其子級。 通過將所有頂級和中間組的所有子組保留在內存中，Leopard 允許桑給巴爾將所有嵌套組解析減少到對索引的一次調用。 由于 Leopard 將數據存儲在內存中，并且作為與Zanzibar 分開的服務運行，因此它使用本文第 2.4.3 節中的監視 API 來不斷更新對底層組結構數據的更改。

Zanzibar 還做了一個巧妙的技巧來減少尾部延遲：請求對沖。當Zanzibar 檢測到來自 Spanner 或 Leopard 的響應花費的時間比平時更長時，它會向一個或多個其他服務器發送另一個請求，要求完全相同的數據，這些服務器有望響應得更快。

邁向更安全、更一致的未來

Zanzibar （服務）正在大規模直接解決 Google 真正的靈活性、可擴展性、可測試性和可重用性問題。Zanzibar 的論文寫得非常出色且易于理解，以至于當我第一次閱讀它時，我認為所提出的解決方案可以解決我過去構建的系統中的權限靈活性和可擴展性問題。Authzed 是這一旅程的下一步，它將Zanzibar ：Google 一致的全球授權系統......帶給其他人。