歡迎光臨
每天分享高質量文章

實時接口資料也能就近訪問?細說如何用CDN提升App性能

導讀:邊緣計算是在靠近物或資料源頭的一側,就近提供計算服務。其應用程式在邊緣側發起,產生更快的網絡服務響應,滿足行業在實時業務、應用智慧、安全與隱私保護等方面的基本需求。本文作者介紹了在CDN節點上做實時資料處理的一些方式,值得架構師學習。


CDN-Content Delivery Network

我們先來定義下什麼是CDN。內容分髮網絡(CDN)是一種由分佈式服務器構成的系統,它會根據用戶所處的地理位置,資料內容(通常是網頁)的來源,來向用戶分髮網頁內容。但目前這個互聯網發達的時代,CDN已經不僅僅用來分髮網頁內容。

以Cloudflare Workers【1】為例,除了利用它的網絡來分發內容,你甚至還可以在它的邊緣節點上部署運行你的代碼。“可以部署或運行Javascript代碼,這能夠幫助你將代碼與用戶終端設備解耦合,比如支持通過編程實現路由、過濾等功能”。

在當前這個爆炸式發展的互聯網時代,高可擴展性是至關重要的能力。CDN和邊緣計算(Edge Computing)將會進一步融合式發展。


實時資料的獲取——推、拉


目前很多強調實時性的應用需要推送和拉取的資料。被動推送和主動拉取都是非常常見及簡單的工程問題,比如應用初始化的過程中可以從CDN拉取歷史資料,然後再由其他服務來推送更新資料。

但是,我們想一想能否將這兩種機制組合在一起呢?

通過代理來連接Fastly和Fanout


Fastly是一個邊緣計算平臺(Edge Cloud Platform),它可以使應用在網絡的邊緣節點執行和提供服務。 本質上,它提供的是高度可擴展的“資料拉取-響應”服務,可以實時監聽和響應用戶的請求。 相比傳統的CDN,Fastly也可以快取靜態內容,同時可以部署和運行應用邏輯。

另一方面,Fanout則是具備高度可擴展性的資料推送服務,比如用作高性能的反向代理服務,通過長鏈接為客戶端實時推送資料。

Fastly和Fanout可以組合使用。它們作為一個整體可以當作源服務器的反向代理,通過Fastly來代理到Fanout的流量,這樣客戶端就不用直接請求你的源服務器。這會帶來一些好處:


  • 高可用和高可擴展性,這點毋庸置疑

  • 快取初始資料

  • 快取Fanout的指令,這點需要特別說明:Fanout的一些行為是通過指令來配置的。比如傳輸樣式,訂閱的channel等等。通常,這些指令是通過源服務器的response來獲取(一類特殊的essay-header,被稱為Grip)。Fastly可以在獲取一次response後快取這些指令。


映射網絡流


通過組合使用Fanout和Fastly,我們就可以重構這個“推-拉”模型中的網絡資料流,下麵我們來仔細看看它們是如何工作的:

假設我們有一個HTTP Endpoint是 /stream,它會傳回一些初始資料,並且在有新資料產生後推送給連接的客戶端。配合Fanout,我們可以讓這個Endpoint傳回帶有instruction的response:(以response essay-header為例)

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 29
Grip-Hold: stream
Grip-Channel: updates

{"data": "current value"}

當Fanout從源服務器收到這樣的response,會將它轉換成HTTP streaming的response:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: Transfer-Encoding

{"data": "current value"}

這樣,Fanout到源服務器的請求就完成了,但是客戶端到Fanout的請求(連接)仍然是open的狀態,用這樣的時序圖來表示:


因為Fanout到源服務器是短鏈接的請求/響應樣式,可以通過Fastly來轉換成長連接:

這樣當再有客戶端請求/stream這個endpoint時,源服務器就完全不會參與進來:

換句話說,Fastly會給Fanout傳回相同的response,帶著特殊的essay-headers已經那些初始資料,Fanout到客戶端則維護streaming連接。

上述過程,我們只解決了“拉”的過程,還需要實現新資料被實時“推送”給Fanout(客戶端)。

清除fastly的快取

當源服務器的資料改變時我們需要清除掉fastly上的快取來更新它。

還是上文的例子,假如/stream endpoint的資料產生變化,我們就需要清除fastly的快取並同時將新資料廣播給fanout。

下麵這個時序圖描述了一個更複雜的場景,已有的客戶端將被推送新的資料,之後再來一個新客戶端連接:


高效的實現流控

在這種混合架構下,為了提高效率,理想的資料讀寫模型是:

  • 資料訪問:每秒若干新的讀

  • 資料更新:每分鐘若干寫

  • 資料分發:毫秒級投遞

如果你的資料每秒都會產生變化,那最好是不要每次資料變更都清除快取。(容忍一定程度的資料不一致性)

例如在高峰時期,我們可以限制清除的頻率,大部分讀請求還是由快取資料來響應,稍候再更新資料。

Demo

這裡提供了托管在GitHub上的demo應用原始碼,它利用fastly和fanout提供一個live 

counter服務。
請求會先到fanout,然後到fastly,最終傳遞到一個由Django實現的backend server。這個服務實現了簡單的計數器邏輯,當計數器的值更新了,fastly的快取會被清除掉,同時再通過fanout發送出去。清除和更新的過程都由流控來限制,以盡可能提高快取的效率。

腦洞一下

我們可以設計一個訊息內容分髮網絡,它由完全是地理位置分佈的若干組server構成,可以提供近實時的動態內容和靜態內容分發。

這種新型別的CDN網絡可以使得資料處理延伸到網絡邊緣,不用管應用本身的源服務位於哪裡。這將為移動應用和IoT應用形態帶來巨大的想象空間。

英文原文:

https://hackernoon.com/powering-your-app-with-a-realtime-messaging-cdn-13d92a6df5f3


相關閱讀:

本文作者Justin Baker,由魏佳翻譯,轉載本文請註明出處,技術原創及架構實踐文章,歡迎通過公眾號選單「聯繫我們」進行投稿。


高可用架構

改變互聯網的構建方式

長按二維碼 關註「高可用架構」公眾號


赞(0)

分享創造快樂