邊緣計算的資料模式，與現有系統的整合和共存

　　今天的企業正在競相將關係到使用者體驗的資料置於更接近終端使用者的位置，同時各類區域性資料隱私法規也紛紛出臺；在這樣的背景下，我們有必要審視資料中心的“同步資料檢索”“後續資料檢索”和“預取資料檢索”等企業資料模式。我們還應瞭解如何在將資料移植到邊緣的同時避免像資料中心那樣複雜地克隆整個架構，且能有效掌控控制平面、避免邊緣盲點。

　　企業的使用者體驗資料

　　上圖是現有的企業級資料圖景概況：其中服務 A 是多個服務的抽象表示，服務 B 表示訪問資料中心本地資料的服務層，訪問來自外部第三方供應商的資料的所有服務都抽象為服務 C。跨越這些服務的資料檢索操作又可以進一步分為以下類別：

　　同步資料檢索。這種模式中，使用者的所有資料都在一個單一或父級請求中檢索，這個請求可能是初始 html 負載呼叫或來自原生移動應用程式的服務呼叫。這種模式的一個例子是任意交易體驗或個性化使用者體驗：一個同步資料檢索的增強版本中，資料是逐步分塊或分頁提供給終端使用者的。

　　後續資料檢索。在這種模式中，系統首先檢索初始關鍵資料，後續資料則透過非同步呼叫檢索。該模式的一個例子是非初始頁面內容推薦（其中所需的內容是在終端使用者滾動頁面後才出現的），廣告或遊戲瓦片也適用於這種檢索模式。

　　預取資料檢索。第三種模式利用了使用者參與時間，基於預測性統計資料/排名/工作流程來預取或載入資料，這裡的資料可能是媒體資源/模板/個性化資料。

　　首先簡單介紹一下邊緣計算：如果 SDN 更接近終端使用者，且你或你的組織為邊緣計算做好了準備，那麼任何位於你的資料中心之外的位置都可以被看作是網路邊緣。例如，如果計算是在資料中心和邊緣元件之間的互動，而不像本地計算那樣基本在叢集的邊緣節點完成，這樣的計算就可以被看作是邊緣計算。

　　在我們深入研究邊緣和邊緣計算的資料模式之前，首先要看到行業正規化一直在向使用者裝置或瀏覽器的靜態資料集轉移，從而導致使用者資源和頻寬的開銷增加，同時也讓企業失去了對某個時間點上提供的資料的控制機制。

　　這篇文章試圖解釋的是，我們如何在邊緣計算模式中將傳統的控制旋鈕或語義保留給資料中心工程師與邊緣工程師，同時不讓使用者為你的最佳化付出代價。簡而言之，我們的目標是將資料範圍從 D 空間擴充套件到 E 空間，如圖 1 所示。這需要克服與以下方面有關的障礙：

　　有限的基礎設施 Capex

　　控制機制

　　故障排除

　　可觀察性

　　資料清洗

　　實驗

　　流量路由和升溫（Ramp Up）

　　遺留技術支援

　　這篇文章旨在介紹各種資料模式、解決相關的問題集合，並給出一些見解，告訴讀者可以利用哪些技術來擴充套件企業資料集。

　　邊緣資料模式

　　我們先來討論一下面向邊緣計算和使用者體驗最佳化的三種主要資料模式。

　　同步資料檢索

　　網際網路領域的大多數資料都屬於這個範疇。企業資料集包含許多相互依賴的服務，這些服務以分層的方式提取所需的資料集，這些資料集可以是個性化的，也可以是通用格式。傳統上，企業只能將靜態資源、標頭資料集或媒體檔案遷移到邊緣或 CDN，同時基礎資料集基本上是從源 DC 或雲提供商那裡檢索的。

　　談到使用者體驗，這方面的最佳化工作主要涉及關鍵渲染路徑和基於 web 體驗的導航時間線的相關改進，還關係到裝置體驗中有多少檢視模型被解除安裝到應用二進位制檔案上。在混合體驗中，狀態模型會透過伺服器推送或輪詢定期更新。本文討論的用例是我們如何從邊緣為個性化的資料集實現資料檢索。

　　模式

　　使用者體驗資料被劃分為非使用者上下文（NC）和使用者上下文資訊（UC），其中非使用者上下文資料指的是跨使用者或體驗的通用資訊，而使用者上下文資料是特定於裝置或使用者的資訊。非使用者上下文資料會被儲存、失效、即時清除，而相關的使用者上下文資訊則在父請求生命週期內縫合或定製。這裡的設計原則是，引入邊緣不應削弱網路和領域團隊實現各自的控制和最佳化旋鈕的能力。

　　元件

　　我們先討論一下資料中心的各種元件，因為許多團隊已經有了資料中心的各種服務，所以這是一個很好的出發點。

　　資料中心元件服務 A

　　一般情況下這會是企業內部的前端層，它需要做一些變更來支援上述模式。首先，這一層需要將邊緣側流量識別符號頭傳播到底層服務、處理 cookie 管理事宜、確定並設定必要的快取控制值（如快取或不快取）、如果快取還要設定快取時長，這裡一般利用標準的 Cache-Control指令。這一層也負責刪除任何動態的全域性頭或通用模組，並重新插入相同的內容作為使用者上下文響應負載的一部分。就邊緣生態系統而言，前端層預計將主要處理以下四個資料流：

　　常規流量（非 POP）

　　常規的實驗控制流量

　　快取建立/寫入呼叫，這裡就是非使用者上下文的請求

　　使用者上下文請求

　　服務 B

　　這一層負責根據使用者和非使用者上下文資訊來分割資料，透過一個模組提供者組（如 CACHEABLE）讓業務團隊控制哪些資料段需要被快取，哪些不需要，並由 ValidationViewModel 作為先導，對不需要被快取的受限資料集施加規則和限制。實驗和跟蹤都是在這一層處理的，用於業務影響分析需求。這一層基於邊緣流識別符號頭來處理所需的資料響應、為分析提供相關的跟蹤，並用所需的快取 ttl 值和修訂 ID 對資料響應進行著色，以便於資料清除和拉取，從而讓業務團隊在移動到 POP 生態系統的邊緣時仍然可以管理資料。

　　邊緣元件

　　正如你在上面所觀察到的，資料中心的入口點要根據從邊緣傳播的不同標頭而表現出不同的行為，並根據路由而有不同的行動。同時我們要確保邊緣資料儲存與基於瀏覽器的快取指令相相容。為了在邊緣或 POP 上適應這一點，我們需要有一個可擴充套件的軟體負載均衡器，Envoy就是一個選項。它有強大的跨主叢集發現服務、路由、監聽器、金鑰管理和新增自定義過濾器的能力。就邊緣資料儲存叢集而言，考慮到資料儲存理解瀏覽器快取衍生物時要注意的事項，對我們來說ATS是一個有利的、可擴充套件的選擇。

　　SLB

　　如下圖所示，軟體負載均衡器負責以下操作步驟：

　　處理傳入的使用者請求

　　在業務特定的服務 E 上詢問可能的快取記憶體金鑰

　　如果快取被命中，檢索非使用者上下文資料給終端使用者

　　如果快取未命中，將基於雜湊的資料寫入邊緣資料儲存中，以便將來呼叫

　　在父請求生命週期中縫合使用者上下文

　　在更新或修訂 ID 變化時令快取失效

　　服務 E

　　這項服務在邊緣是必不可少的，它允許業務或領域團隊輸入與資料集相關的必要知識工程。如果你的資料或經驗是國際性的，那麼服務 E 就會負責處理不同的地域、識別實驗組的使用者部分、基於查詢引數自定義邏輯、檢測裝置以允許或不允許快取模式、生成使用者請求的快取金鑰。

　　邊緣資料儲存

　　邊緣資料儲存叢集主要需要處理基於 TTL 值設定的快取清除機制，並對資料中心進行必要的呼叫以檢索新的資料集（而不是快取資料集），即使在設定了相應的快取控制值並做出了快取呼叫嘗試的情況下也是如此。

　　在我們的用例中，鑑於 ATS 會為每個單獨的請求呼叫源資料，ATS 資料儲存被植入了一個自定義外掛，只在請求有 cache-key 頭值時才進行呼叫，從而允許 SLB 控制快取資料集的條件與時機。

　　小結

　　上述方法可以在邊緣快取非個性化（非使用者上下文）資料，並在請求生命週期中檢索使用者上下文資料，從而讓終端使用者看到相同的非 POP 體驗。給終端使用者提前檢索非使用者上下文資料可以讓瀏覽器構建 DOM，從而提高關鍵渲染路徑的效能，並允許未來的使用者資料滲入到瀏覽器渲染層，以獲得更好的使用者感知。在我們的高流量頁面中，我們能夠將延遲從>1500ms 降至<700ms。上述方法的額外優勢包括處理機器人流量，並能集中觀察全球流量，在流量與業務之間建立有效關聯。

　　後續資料檢索

　　與同步資料檢索不同，這種檢索模式中快取的力量更集中在重複呼叫資料內容以獲得更高的快取命中率上。如果你有一個長尾訪問模式，並且檢索的資料在本質上是獨特的，這種模式可能就不合適了。大多數此類場景可以透過更早傳送關鍵內容來最佳化，後續資料集可以根據需要從邊緣檢索。這種模式有一個額外的優勢——即使資料是唯一的且只訪問一次（例如廣告），也能實現邊緣資料的檢索。我們可以透過驗證使用者體驗的內容檢索的常規時間線來判斷在這種模式中能否看到延遲預算的改善。在下圖中，正如你所看到的，當瀏覽器發出請求時（1-2），初始頁面內容被檢索出來，併為將來的資料內容呼叫提供相關的識別符號（5）（主要在頁面 onload事件後觸發）。瀏覽器端用於構建 DOM 和網路延遲的時間被認為是從服務 B 層檢索資料集的並行呼叫的一個額外優勢。

　　如上圖所示，遷移到邊緣可以讓內容在邊緣可用，並讓不同的識別符號以較低的 ttl（短時交易資料集）來支援終端使用者體驗，如果可行的話，將服務 B 遷移到離第三方供應商更近的地方可以在服務 B 層更快提供資料。

　　模式

　　具體來說，來自服務 B 的資料中心資料在可用時被推送到各自的邊緣叢集，以便快速檢索；如果出現任何失敗就返回到傳統的由資料中心呼叫的模式。所有的讀和寫操作都透過相同的軟體負載均衡器轉移，以實現一致的雜湊和單點可觀察性。

　　元件

　　我們來看看實現上述模式的資料中心元件和邊緣元件。

　　資料中心元件服務 A

　　該服務嵌入到現有的架構模式中，以支援建立動態識別符號，用於放置或分頁對終端使用者的最終響應上的模組。在一些用例中，這一層可以容納使用者資訊，以定製與終端使用者相關的頁面模組響應。同時該層管理邊緣流識別符號頭到下游的傳播。

　　服務 B

　　服務 B 的抽象適用於來自第三方系統或競標引擎的資料檢索。這裡要有並行的、支援 FIFO 的資料檢索。

　　服務 C

　　服務 C 容納從資料中心寫入和讀取的資料內容。

　　服務 E

　　服務 E 將邊緣洞察力嵌入業務團隊，使資料在終端使用者本地可用。該層提供了基於父級原始請求的複製和資料可用性。

　　邊緣元件SLB

　　在這種模式下，軟體負載均衡器負責

　　針對響應 HTTP 204 處理無內容場景

　　處理預檢請求和響應頭，以儘早確定允許的域

　　傳播上游服務的 POP 叢集資訊，以確定未來呼叫的會話親和性

　　邊緣資料儲存（ATS）的 POST 到 PUSH 轉換

　　處理快取命中、快取丟失、寫入、讀取路徑、資料大小的可觀察性

　　例如，在下面的場景中，每段內容都是唯一的，邊緣的命中率大於 82%，寫操作被路由到父請求 POP，沒有複製到該區域的其他 POP。

　　然而，當業務團隊減少對邊緣資料的推送時，同樣的情況在邊緣側響應程式碼中很明顯，這樣異常檢測系統就很容易發現它。

　　邊緣資料儲存

　　在這種場景中，我們要利用 ATS 的 PUSH 模式來儲存相關的 TTL 值的資料內容，關鍵點是透過資料中心的 POST 或 PUT 進行寫入操作。同樣的操作被轉換為 ATS，以支援 PUSH 方法在插入時 drop HTTP 201、在複製時 drop HTTP 200、在內容丟失場景 drop HTTP 204。

　　小結

　　上述方法可以支援將資料轉移到邊緣的目的，即使資料集只被訪問或使用一次（短時交易記錄），或者在使用者無法確定（如訪客或系統新使用者）的情況下也是可行的。

　　預取資料檢索

　　在預取的場景中，重點是可以提供下一個確定的資料集。考慮下圖中的服務 Z，它是由服務 A、B 或 C 驅動的頁面請求的前置服務。在基於下一步內容的漏斗或工作流中，相關的（預測的或排名的）資料集被預取並在邊緣提供。一般來說，這適用於載入遊戲瓦片、推薦、頂級搜尋結果和載入媒體檔案等場景。

　　這種模式的效率取決於相關資料集是如何被快取或儲存在邊緣的，被提供的資料應利用同步資料檢索、後續資料檢索或離線資料模式提供。

　　總結

　　我們正進入一個資料爆炸的時代，在未來幾年內邊緣平臺將承載大部分新增資料。只有適應邊緣計算的組織才能轉變為圍繞邊緣智慧的持續創新體系。正如你在上面的邊緣資料模式中所看到的，現在任何組織都可以改造他們現有的傳統系統來利用邊緣計算的優勢。由於我們正在處理的是底層資料，就可以適應不斷變化的技術棧。另外這些資料模式可以讓資料本地化，以應對資料隱私法案的要求。