Rust中的高吞吐量流處理
作者 | Noz編譯 | 王瑞平本篇文章主要介紹了Rust中流處理的概念、方法和優化。作者不僅介紹了流處理的基本概念以及Rust中常用的流處理庫，還使用這些庫實現了一個流處理程序
本文來源于《華為云 DTSE?》第五期開源專刊，更多文章請查看：https://bbs.huaweicloud.com/blogs/435823
作者：徐飛華為云高級軟件工程師，KubeEdge 社區 TSC
摘要：由于邊緣計算場景需求的日益增長，傳統架構面臨諸多問題，KubeEdge 將云原生應用擴展到邊緣計算，利用 Kubernetes 的能力來高效的管理和調度邊緣設備上的工作負載。通過提供邊緣設備的本地計算、存儲和網絡能力，減少云與邊緣之間的數據傳輸延遲，提升應用的效率和響應速度。未來，KubeEdge 將持續創新，進一步加強可擴展性、安全性和多樣化的場景支持，推動云原生邊緣計算領域的發展。
1.背景與挑戰
傳統邊緣計算行業多層級獨立控制、設備缺乏開放性，系統集成復雜等問題，導致邊緣應用開發成本高，上線速度慢，缺乏智能。華為從 2016 年開始研究如何將易擴展、易遷移的云原生技術架構運用到邊緣計算領域。
華為云于 2018 年 11 月開源業界首個云原生邊緣計算項目 KubeEdge，并在 2019 年 3 月捐獻到云原生計算基金會（CNCF）。KubeEdge 將 Kubernetes 原生的容器編排和調度能力拓展到邊緣，完整的打通了邊緣計算中云、邊、設備協同的場景，為用戶提供一體化的云邊端協同解決方案。
自開源以來，社區一直秉承開源開放的治理模式，在開放協作的理念下蓬勃發展，目前已被廣泛應用于智能交通、智慧園區、工業制造、金融、航天、物流、能源、智能 CDN 等行業，本文結合天翼云大規模 CDN 場景，介紹 KubeEdge 社區行業落地實踐。
創新使能，開放共治的云原?邊緣計算社區
2.KubeEdge 的布局和核心技術
KubeEdge 基于 Kubernetes 原生的容器編排和調度能力之上，擴展實現了邊云協同、計算下沉、海量邊緣設備管理、邊緣自治等能力，完整的打通了邊緣計算中云、邊、設備協同的場景。將云原生技術延伸到了邊緣計算領域，實現了云原生生態與邊緣計算生態的互通。
KubeEdge 基于 Kubernetes 之上，在 100% 兼容 Kubernetes API 的基礎上，結合邊緣計算中網絡不穩定、資源受限、海量邊緣設備等場景，實現的技術點包括：
1、基于 Kubernetes 構建平臺，提供云-邊-端一致的業界標準云原生應用管理框架，解決云邊協同架構中云平臺廠商綁定問題；
2、大幅優化邊緣節點組件資源占用，支持管理小規格邊緣網關節點；
3、在云邊之間引入雙線多路復用通道，重新實現 K8s 控制面與節點通信機制，引入可靠校驗機制，解決邊緣節點與云上組件連接帶寬受限、網絡質量不可靠等問題；
4、邊緣節點支持數據本地持久化，支持邊緣節點離線自治；
5、北向基于 Kubernetes CRD 引入設備管理 API，支持以 Kubernetes 的 API 標準管理邊緣設備；
6、南向提供物聯網設備接入框架，內置多種主流物聯網通信協議實現，并支持用戶自定義擴展，解決異構設備接入復雜性問題。
3.多領域、多行業生產落地
KubeEdge 目前已被應用于廣泛應用智能交通、智慧園區、工業制造、金融、航天、物流、能源、智能 CDN 等行業，完成業界最大規模云原生邊云協同高速公路項目（統一管理 10 萬邊緣節點 / 50 萬邊緣應用）、業界首個云原生星地協同衛星、業界首個云原生車云協同汽車、業界首個云原生油田等行業代表項目。
3.1 天翼云基于 KubeEdge 的大規模 CDN 場景落地實踐
3.1.1 天翼云 CDN 業務背景
中國電信以“2+4+31+X”的資源布局加速云網融合。“X”是接入層面，把內容和存儲放到離用戶最近的地方，實現網隨云動、入云便捷、云間暢達，滿足用戶按需選擇和低時延需求。目前天翼云基本的 CDN 功能已一應俱全，且資源儲備豐富，支持精準調度，秉承質量優先，整體業務發展正步入快車道。
3.1.2 邊緣服務容器化背景
與其他云廠商和傳統的 CDN 廠商不同，天翼云 CDN 起步較晚，但也恰逢云原生理念大行其道。因此，我們選擇了通過容器與 Kubernetes 編排技術構建 CDN PaaS 平臺，但是 CDN 邊緣服務尚未完成云原生改造。
存在的問題：1）如何納管大規模分布在邊緣的 CDN 節點？2）如何對 CDN 邊緣服務進行可靠的部署和升級？3）如何構建統一、可擴展資源調度平臺？
3.1.3 基于 KubeEdge 的邊緣節點管理
CDN 物理節點架構
CDN 提供的緩存加速服務，解決最后一公里加速問題。為了滿足就近接入和快速響應，大部分 CDN 節點需要部署到近用戶側，通過 CDN 全局流量調度系統將用戶訪問接入到就近節點。通常 CDN 節點具有呈離散分布的特點，大部分以各地區域 IDC 和地市級別 IDC 機房資源為主，每個邊緣機房根據出口帶寬和服務器資源規劃，搭建多個 CDN 服務集群。
邊緣服務容器化技術選型
在考慮做容器化的過程中，我們前期進行了技術選型和研究，主要是三個方向：標準 K8s：邊緣節點以標準 worker 節點加入到 master，但這種方式也會存在問題，如果連接過多容易造成 Relist，K8s master 端負載壓力大；網絡波動，造成 pod 被驅逐，導致不必要重建；分節點接入 CDN 邊緣節點：分集群部署 K8s 或 K3s。這種方式的控制面與集群過多，無法構建統一的調度平臺，而且每個 KPI 集群若按高可用方式部署也至少需要 3 臺，會過度占用機器資源；云邊接入：通過 KubEedge 方式接入，按照這種方式，可以收斂邊緣節點連接，接入統一的 K8s 集群，并且提供云邊協同，邊緣自治等能力，還保留了大部分 K8s 的原生能力。
3.1.4 基于 KubeEdge 邊緣節點納管方案
上圖是我們目前架構的示意圖，我們在各區域中心及數據中心建若干個 K8s 集群，K8s 集群下面是邊緣按就近規劃的接入到區域的集群。為了避免單點接入，以及單 K8s 集群 CloudCore 負載過大的問題，在各大區建設 K8s 集群，用于邊緣節點的接入和應用編排管理。但在社區早期 1.3 版本中，當時提供的高可用方案只是單組多重這種高可用方式，而實際是無法滿足我們大規模納管的性能要求，因此我們后面在社區推出多組部署方式。這種部署方式在早期使用的過程中并沒有問題，但當接入的邊緣節點，還有部署的容器數量過多時，這個問題就逐漸暴露出來：
CloudCore 多副本部署連接不均衡問題
上圖為 hub 到 upstream 最終提交到 apiserver 的示意圖。中間 upstream 模塊有一部分的分發，它是用單線程的方式來運行，中間 upstream 模塊，因為只有單線程，會導致消息提交過慢，邊緣節點的一些 node 無法及時提交給 apiserver，最終引起我們部署方面的一些異常。后面我們把 CloudCore 按多副本去部署，又出現了在 CloudCore 進行升級或者一些意外重啟過程中，會發現連接不均衡的問題。為了解決這個問題，我們在多副本之前，部署了 4 層的 lb，并在 lb 上配置了諸如 listconnection 的負載均衡策略，但實際上像 ls 這種負載 4 層的負載平衡，它都有一些篩選的緩存機制，并不能保證連接的均衡的分配。基于以上背景我們進行了優化：
CloudCore 多副本均衡優化方案
①CloudCore 每個實例在啟動后各自通過 Configmap 的方式上報實時的連接數等信息；②CloudCore 結合本地實例與其他實例的連接數，計算每個機器的期望連接數③計算本地連接數與期望連接數的相差比例，相差比例大于最大可容忍連接數差，進入連接待釋放階段，并進入一個 30s 觀察周期；④觀察過后，進入下一個檢測周期，直到連接均衡。
3.1.5 邊緣應用服務部署
CDN 加速服務整體流程
CDN 它主要分為兩大核心系統：調度系統和緩存系統。調度系統會實時采集全網的 CDN 鏈路情況，實時的節點的情況，以及節點的帶寬成本的情況，從而決策出最優調度的覆蓋數據，將這個數據推給 Local Dns 或 302 或 hds 的一個的調度器。Local Dns 拿到最優數據后，來進行 Dns 的解析響應，用戶端通過解析響應可就近接入到邊緣集群，邊緣集群因為涉及到緩存，有可能涉及到 miss，如果 miss 后，它會回到上一層的緩存，一般會有兩層或者三層的中轉的緩存，最終回到原狀。
如果中轉的緩存也沒有，數據會再回到云站，這是 CDN 服務的整體流程。在緩存系統，一般不同產品的緩存會使用不同的服務，比如面向直播的流媒體的加速服務和一些靜態的加速會有一些區別。這也給開發和維護造成了一些成本，后面它們的融合可能也是一個趨勢。CDN 緩存服務的特點：
1、資源獨占：緩存服務是要最大利用存儲，機器上的存儲和帶寬的資源的一個服務，所以說它需要獨占
2、大規模高服用：規模很大，覆蓋廣，同個軟件或同一臺機器的緩存服務，可能要承接上萬個域名，甚至 10 萬域名
3、容災分區故障：容忍組內小部分節點的緩存丟失，或者是全局有少量的節點緩存失效，緩存過多會造成擊穿，反之擊穿就回到上層的緩存，造成訪問延遲變大，最終引起服務異常。
4、高可用：4/7 層 LB 具備實時探測和切流、引流能力；L4 LB 保證組內主機間的流量均衡；L7 LB 通過一致性哈希盡量保證讓每個 url 在組內只存一份副本
從以上的特征，我們看到 CDN 在部署中，要解決以下問題：1）如何讓節點容器有序和可控的升級？2）如何進行版本的 A / B 測試？3）如何對升級過程進行校驗？
我們的升級部署方案包括
分批升級與組內升級并發控制：創建分批升級任務；
控制器按指定機器進行升級、細粒度版本設置：創建主機粒度版本映射；
控制器增加 pod 版本選擇邏輯，優雅升級：通過 lifecycle 的 prestop / postStart 實現常規切流與恢復，特殊場景聯動 GSLB 進行切流；
升級校驗：Controller 與監控系統聯動，升級過程發現服務異常，及時終止與回滾；
編排安全防護：Workload 粒度與 pod 粒度通過 Adminsion Webhook 增加校驗是否符合期望修改與刪除；
3.1.6 基于 KubeEdge CDN 邊緣容器容災與遷移
遷移步驟：
1.備份 etcd，在新集群中 restore；
2.切換接入 DNS；
3.重啟 CloudCore 斷開云邊 hub 連接；
優點：1、成本低，由于 KubeEdge 的邊緣自治特性，邊緣容器無重建，服務無中斷；2.流程簡單，可控，服務安全性高；
3.1.7 CDN 大規模文件分發
需求場景：?CDN 邊緣服務配置?GSLB 調度決策數據?容器鏡像預熱任務
3.1.8 未來架構演進方向思考
邊緣計算挑戰
資源管理：分布廣泛，種類多，架構、規格不統一
網絡時延、可靠：異構網絡，移動網絡等弱網環境，帶寬受限，穩定性不足
安全：邊緣服務更難形成統一的安全防護體系
業務多樣：場景、業務種類多樣
基于 CDN 的邊緣計算平臺基礎能力
資源：CDN 節點覆蓋廣、潮汐特性特性資源冗余；通過 Kubeedge 提供了云邊協同；可延伸端側，具有異構資源部署與管理能力；
調度與網絡：專用 EDNS 支持地市級精準調度，實現真正就近接入；CDN 服務與邊緣計算服務統一調度；云邊專用網絡，管理通道、數據回傳、動態加速網絡更可靠；大規模 V6 支持；
安全能力：CDN Waf 抗 D、流量清洗、近源攔截等; 證書加速與安全，SSL 硬件卸載、keyless 無私鑰方案，提供邊緣安全接入；
網關：邊緣調度與豐富的負載均衡能力；通用協議處理能力，常規流媒體協議，滿足大多互聯網加速場景。
業務探索
未來將在離線計算類、視頻編轉碼、視頻渲染、批量作業、撥測、壓測類持續探索實踐。
4.總結
作為業界首個云原生邊緣計算社區，KubeEdge 社區目前已完成包括業界最大規模云原生邊云協同高速公路項目（統一管理 10 萬邊緣節點 / 50 萬邊緣應用）、業界首個云原生星地協同衛星、業界首個云原生車云協同汽車、業界首個云原生油田項目等在內的諸多行業代表項目。截至目前，KubeEdge 在全球已有超 1600 名開發者參與代碼貢獻，覆蓋中國、美國、德國、韓國、日本、土耳其、意大利、波蘭、墨西哥、俄羅斯、英國、西班牙、印度、尼加拉瓜等國家，100 余家企業與科研機構參與項目合作。
在未來，KubeEdge 社區將在固定邊緣、移動邊緣、邊緣 AI 等領域不斷探索，KubeEdge 社區期待與你協作創新，共同促進云原生邊緣計算發展！
附：KubeEdge 社區貢獻和技術交流地址
網站:https://kubeedge.io
GitHhub 地址:https://github.com/kubeedge/kubeedge
本文鏈接：http://www.www897cc.com/showinfo-26-125108-0.htmlKubeEdge：云原生邊緣計算賦能多行業、多場景的智能化升級
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號