Polaristech 劉洋：基於 OpenResty/Kong 構建邊緣計算平臺

2019 年 3 月 23 日，OpenResty 社區聯合又拍雲，舉辦 OpenResty × Open Talk 全國巡迴沙龍·北京站，Polaristech 技術專家劉洋在活動上作了《基於 OpenResty / Kong 構建邊緣計算平臺》的分享。

OpenResty x Open Talk 全國巡迴沙龍是由 OpenResty 社區、又拍雲發起，邀請業內資深的 OpenResty 技術專家，分享 OpenResty 實戰經驗，增進 OpenResty 使用者的交流與學習，推進 OpenResty 開源項目的發展。活動將陸續在深圳、北京、上海、杭州、成都、武漢等城市巡迴舉辦。

劉洋，Polaristech 技術專家，曾就任於 Redhat、阿里雲，10 餘年研發經驗，近期加入 Polaristech 投入邊緣計算領域。做爲 RHCA，不只在 Linux 領域擁有豐富的技術積累，同時在工做中也積累了大量的市場經驗。

如下是分享全文：

你們好，我是劉洋，首先介紹一下咱們 Polaristech 團隊作的幾件事情，第一是 Nginx as a Service，由於不少傳統的廠商大量使用 Nginx 做爲網關，可是流量上來以後管理很是困難；第二是 API 網關，一方面是你們常理解的網關，另外部分是微服務的治理，好比 Service Mesh，咱們用提供了一個優雅的方式解決微服務的網關問題；第三個部分就是邊緣計算。

邊緣計算與邊緣節點

什麼是邊緣節點

邊緣計算是一種將主要處理和數據存儲放在網絡的邊緣節點的分佈式計算形式。跟雲計算側重的點是不一樣的，「邊緣」是一個相對的概念，好比數據源、數據中心、雲等等，從最邊上的節點開始，均可以叫作邊緣。相對於傳統「中心計算「，數據上傳到數據中心，經過中心的資源完成存儲和計算。

但隨着萬物互聯時代的到來，智慧城市、智能製造、智能交通、智能家居，5G 時代、寬帶提速、IPv6 的不斷普及，致使數百億的設備接入網絡，在網絡邊緣產生 ZB 級數據，傳統計算難以知足物聯網時代大帶寬、低時延、大鏈接的訴求，在這種狀況下，今天的技術架構還能不能支撐那時你們的想象當中的計算機的世界？因此，咱們想作一些架構上的創新，或者是嘗試。

上圖能夠看到從 2015-2019 年，邊緣計算的趨勢一直往上走。關於邊緣計算，有不少定義的方式,首先定義邊緣節點：非數據中心的計算資源， 都是邊緣節點。須要注意的是做爲邊緣計算平臺，不只僅由邊緣計算節點組成，也包含數據中心的節點，在實際中，咱們遇到了許多的邊緣節點場景，好比說樓宇、園區、基站、監控設備、車輛等，把這些的非中心的計算資源、網絡資源、存儲資源都叫作邊緣節點。

邊緣節點的環境和特色

我認爲環境是邊緣計算的最大前提，數據中心一般是可靠計算環境，包括電力、網絡、溫度、專業運維等。若是把計算放到邊緣，好比在一個居民樓中有邊緣節點，咱們總結了幾點：

• 電力不可靠，可能停電或者是插線板壞了。
• 網絡不穩定，帶寬沒有保障，延遲沒有保障。
• 物理環境缺少統一的條件，包括溫度、溼度、氣壓等。
• 算力不統一，今天兩核的，明天可能弄一個四核的。
• 鏈接方式以 TCP/IP 爲主，包括基於移動通訊的 4G 和 WIFI，或經過 IoT 的協議 LoRa、NB-IoT 等。

總結起來，邊緣節點處於不可靠計算環境中，並且沒有專業的運維，在中關村還方便找運維，萬一若是在攀枝花、牡丹江呢？很差說。

爲何基於 OpenResty / Kong

基於數據中心的「雲計算」是以「計算資源」爲中心的，而邊緣計算本質是以「網絡資源」爲中心的，是面向網絡的計算。那麼爲何咱們選擇 OpenResty 和 Kong 爲核心來構建邊緣計算平臺？

第一，由於 OpenResty 是面向應用的網絡架構，如今有一個流行詞叫作應用交付網絡簡稱 ADN。OpenResty 具備小巧、靈活、可靠、高效穩定的網絡處理能力，由於 OpenResty 下面都是 Nginx 很是高效一個包不到 20 兆，基本上能夠穩定運行在一切可以支持 Linux 的平臺上。

第二，OpenResty 是可擴展的，數據到達邊緣節點後，OpenResty 能夠把各類數據和常見的計算框架結合起來。

第三，Kong 能夠當作是 OpenResty 領域裏的 Struts(類比 Java)或者 Rails(類比 Ruby)，提供了不少配置能力和開發框架，對於數據的處理很是方便。

第四，OpenResty / Kong 除了適應邊緣節點環境，一樣適用各類級別數據中心環境。在數據被最終存儲以前，OpenResty / Kong 能夠構建整個應用數據的傳輸鏈路，並完成各個環節的計算任務。

最後，OpenResty / Kong 很「皮實」，基於 OpenResty / Kong 組成的計算節點，能夠作到「RESET即恢復功能」 咱們但願作到什麼？就是若干年前你們去網吧，網管只會一招"重啓"。由於在邊緣，沒有專業的人員，因此但願當這個東西壞了，重啓一下就能夠恢復了。基於這幾點，咱們最後選擇了 Kong 加 OpenResty。

除了 OpenResty / Kong 還用了什麼

首先是使用 CentOS 做爲操做系統。PostgreSQL 是 Kong 原生支持的一個數據庫，Kong 原生支持兩種數據庫，一種是 PostgreSQL，一種是 Cassandra。

還有咱們本身加了一個MySQL，由於國內 MySQL 的用戶羣體很是大。PostgreSQL 是咱們最經常使用和主推的數據庫，雖然在國內不是特別火，可是 PostgreSQL 會有很是多的支持，效率也很高。

第三個是 RocksDB，主要部署在邊緣節點，用於以 k/v 形式緩存數據，包括上行和下行數據。還有是基於 Nodejs 的調度程序，調度程序是邊緣計算的核心能力。

最後是 Kubernetes，用於數據中內心計算資源管理，提供多租戶的數據中心計算能力。

核心架構採用三層或者是 1+N+1，最上層是數據中心，不管是在本身的本地數據中內心面仍是在雲上均可以。這一層使用 K8S 作數據的核心應用包括 ESS 和 OSS，作多租戶的計量計費、數據的調度、節點管理等，而後是標準的 X86 服務器。

中間是中繼節點，它的應用是多種多樣的，好比一個小地方的數據中心，或者像一些雲廠商，會提供邊緣節點，在邊緣節點和數據中心之間，上行和下行數據經過一層或者多層的中繼節點中轉和處理，從中繼節點到數據中心很像 CDN，雖然不是專線，可是它的網絡質量會比純公網傳輸好一些。

最下面是邊緣節點，作終端的流量下發以及上行流匯聚，在這一層首先是作靜態或者是動態內容的緩存，靜態緩存很簡單，像 CDN 同樣有圖片、視頻等的緩存，動態緩存是上行請求的數據，它能夠把 HTTP body 、head 等緩存在邊緣節點，這樣就不用再走一遍 CDN 或者到數據中心進行請求了，大大加速用戶的訪問，同時咱們也會用 RocksDB 把數據緩存下來。

整體來說，首先咱們作了集成管理系統，作邊緣計算應用的交付與下發並把應用部署到邊緣節點上，並對遠程邊緣的設備的進行管理、監控、調度、計量計費等，核心都是在這個中心繫統來完成的。設備管理，主要是對設備狀態的管理、應用的下發、配置的下發等。咱們基於 HTTP 的框架，去實現邊緣節點數據的上下行，特別是上行採起了相似 MQTT 的方式，簡稱叫 HTTPQ，在本地上傳數據的時候先把數據存在 Q 裏面。由於網絡有可能會斷掉，因此會經過 Q 的方式，先把數據放在邊緣節點，而後經過 Q 的方式傳回數據中心。在邊緣用 FASTCGI 的方式，提供一個標準的應用方式，主要仍是考慮到了邊緣的不可靠環境。最後就是調度、監控和流量分發，也是最主要的核心點。

總結

咱們的邊緣計算平臺是雲計算加邊緣計算，既有中心節點又有邊緣節點；不一樣點就在於雲或者是數據中心面對的是數據的計算和存儲，邊緣計算是面向數據流動；另外，經常使用的數據中心軟件，不適合在邊緣的環境裏應用，它對環境和運維的要求比較高；在面對不肯定、不可靠的計算環境，異步很重要，因此咱們用 MQ 的方式去作數據的上行； 「Reset-To-Work」 這個核心的設計觀念，由於管理配置和下發都是經過中心節點作的，邊緣節點出現了任何問題，只需重啓就能夠直接恢復了，由於在中心有對它的監控和配置的集中管理；邊緣計算和雲計算同樣最重要的就是監控加調度，因此咱們以網絡監控爲主去監控邊緣節點的可用性，以及緣節點的適用應用、設備、環境、使用率等；系統中雲計算是面向 SLA 的，邊緣計算是面向流量的：把流量交付出去，和把流量收集上來，是邊緣計算的核心述求。若是雲計算是一個航母集羣的話，那邊緣計算就是一把 AK，適應於各類環境，可以用最小的代價去解決最核心的問題。

觀看演講視頻和 PPT 可前往：

基於 OpenResty /Kong 構建邊緣計算平臺​