當(dāng)前位置：首頁(yè) > 科技 > 軟件

B站邊緣網(wǎng)絡(luò)四層負(fù)載均衡器的探索與應(yīng)用

來(lái)源：責(zé)編：時(shí)間：2023-12-09 15:23:22 288觀看

導(dǎo)讀01 背景介紹B站的 CDN 下行邊緣節(jié)點(diǎn)過去是非集群化架構(gòu)。這種架構(gòu)下有幾個(gè)弊端：增加調(diào)度邏輯復(fù)雜性；同機(jī)房流量/負(fù)載難以均衡；暴露過多的公網(wǎng)IP，增加安全隱患 (盜鏈等)；灰度流量比例分配粒度大；針對(duì)以上問題，我們調(diào)研了常見

01 背景介紹

B站的 CDN 下行邊緣節(jié)點(diǎn)過去是非集群化架構(gòu)。這種架構(gòu)下有幾個(gè)弊端：

增加調(diào)度邏輯復(fù)雜性；
同機(jī)房流量/負(fù)載難以均衡；
暴露過多的公網(wǎng)IP，增加安全隱患 (盜鏈等)；
灰度流量比例分配粒度大；

針對(duì)以上問題，我們調(diào)研了常見的四層負(fù)載均衡器，傳統(tǒng)的 SLB，LVS，DPVS 這類四層負(fù)載均衡器，在功能上也能滿足我們現(xiàn)有的需求。但是以上幾個(gè)負(fù)載均衡器均需要獨(dú)占機(jī)器，進(jìn)而造成成本升高，資源浪費(fèi)。

有沒有一種既不增加成本，又能解決邊緣節(jié)點(diǎn)四層負(fù)載需求的方案呢？由 Cloudflare 提出的基于 Express Data Path (XDP) 的高性能四層負(fù)載均衡器 Unimog[1]性能優(yōu)異，并且可以和后端服務(wù)同機(jī)部署，在性能上也完全滿足我們邊緣場(chǎng)景的要求。所以我們參考 Cloudflare Unimog 的思想，在其基礎(chǔ)上自研了適用于B站的邊緣四層負(fù)載均衡器 Nickel (以下簡(jiǎn)稱 Ni) 。

與業(yè)務(wù)服務(wù)同機(jī)部署，更劃算；
只保留業(yè)務(wù)需要功能，更輕量；
可針對(duì)業(yè)務(wù)特點(diǎn)優(yōu)化，更靈活；

目前已部署在自建動(dòng)態(tài)加速，及自建點(diǎn)直播 CDN 集群化生產(chǎn)環(huán)境中。其支持與后端服務(wù)同機(jī)部署，底層使用 XDP、Traffic Control (TC) 進(jìn)行包粒度轉(zhuǎn)發(fā)，支持 Direct Server Return (DSR) 模式，支持根據(jù) CPU/QPS (或其他業(yè)務(wù)維度) 動(dòng)態(tài)調(diào)整流量分配。

下面左圖為傳統(tǒng) DSR 模式，右圖為自研負(fù)載均衡器 Ni 的 DSR 模式，不需獨(dú)占資源，支持與服務(wù)同機(jī)部署，更符合邊緣場(chǎng)景。

圖片

02 架構(gòu)設(shè)計(jì)

2.1 總體設(shè)計(jì)

四層負(fù)載均衡器 Ni 由兩部分組成，控制面和數(shù)據(jù)面。控制面主要負(fù)責(zé)服務(wù)發(fā)現(xiàn)、配置管理、數(shù)據(jù)上報(bào)，及LB規(guī)則的動(dòng)態(tài)維護(hù)等。數(shù)據(jù)面主要由 LoadBalance (XDP) , Redirect (TC Traffic Control) 等模塊組成，主要用來(lái)負(fù)責(zé)數(shù)據(jù)包的轉(zhuǎn)發(fā)。控制面和數(shù)據(jù)面根據(jù)預(yù)定義的接口傳輸數(shù)據(jù)。

圖片

開始介紹之前先明確幾個(gè)下文中用的到名詞及其意義：

VIP (virtual IP) ：用于統(tǒng)一接受用戶請(qǐng)求，代表當(dāng)前集群流量入口，下文中VIP指LB所在機(jī)器的IP（目前邊緣沒有支持真正虛擬IP的建設(shè)）。
DIP (direct IP) ：業(yè)務(wù)服務(wù)所在機(jī)器的 IP。

2.2 控制面

控制面基于開源框架 kglb[2] 結(jié)合邊緣網(wǎng)絡(luò)特點(diǎn)做的改造和開發(fā)，其核心為生成和維護(hù)供數(shù)據(jù)面使用的轉(zhuǎn)發(fā)表。為了保證轉(zhuǎn)發(fā)表的數(shù)據(jù)的正確性、實(shí)時(shí)性、高效性，控制面使用以下幾個(gè)功能和模塊更新信息：

服務(wù)發(fā)現(xiàn)、管理

Ni 控制面需要維護(hù)同集群邊緣節(jié)點(diǎn)的所有服務(wù)器信息 (VIP，DIP，Hostname，運(yùn)營(yíng)商，權(quán)重等)，以及需要感知當(dāng)前邊緣機(jī)房?jī)?nèi)機(jī)器或者服務(wù)的狀態(tài)變化，如標(biāo)記為下線的機(jī)器不再接受新的連接請(qǐng)求，但是需要維護(hù)當(dāng)前已經(jīng)建立的連接直至其主動(dòng)斷開；

健康檢查

處于異常狀態(tài)的服務(wù)在確認(rèn)其不可用后應(yīng)該盡快從轉(zhuǎn)發(fā)表中刪除，避免影響范圍擴(kuò)大。因此機(jī)房?jī)?nèi)需要有服務(wù)器級(jí)別的健康狀態(tài)檢查。目前 Ni 提供多種協(xié)議類型的健康檢查方式，如 Http、Tcp 等。以下為 Http 健康檢查的相關(guān)配置字段：

{    "checker": {        "http": {            "scheme": "http",            "uri": "/",            "check_port": 9080,            "codes": [                200            ]        }    },    "fall_count": 2,    "interval_ms": 2000,    "rise_count": 2}

支持基于機(jī)器使用率/QPS等做負(fù)載均衡

Ni定期收集機(jī)房?jī)?nèi)各服務(wù)器的資源使用情況，以便于根據(jù)資源使用率做動(dòng)態(tài)調(diào)整。使用收集的信息計(jì)算機(jī)房?jī)?nèi)機(jī)器負(fù)載，讓負(fù)載偏低的服務(wù)分配更多的連接，偏高則反之，從而保證一個(gè)邊緣機(jī)房?jī)?nèi)所有服務(wù)器的負(fù)載收斂。QPS類似。

基于轉(zhuǎn)發(fā)表Beamer[3]的負(fù)載均衡

第一步首先需要一個(gè)穩(wěn)定高效的 Hash 計(jì)算方法，輸入四元組 (源 IP、源 port、目的 IP、目的 port) 后得到對(duì)應(yīng)的 Hash 索引值，第二步使用索引值轉(zhuǎn)換為 DIP。

圖片

支持按照配置的 DIP 權(quán)重做負(fù)載均衡，也可以動(dòng)態(tài)根據(jù) DIP 所在機(jī)器的CPU進(jìn)行實(shí)時(shí)的權(quán)重調(diào)整，也就是調(diào)整 Hash 值在整個(gè)轉(zhuǎn)發(fā)表中的比例。

圖片

如圖所示，比例變化后 Hash 值對(duì)應(yīng)的DIP也會(huì)改變。原本應(yīng)該發(fā)往 DIP A 的數(shù)據(jù)包，發(fā)給了 DIP B。如果這和數(shù)據(jù)包是發(fā)起建連的 (TCP SYN) ，則B服務(wù)器與該數(shù)據(jù)包的 Client 端三次握手建立新連接。但如果數(shù)據(jù)包屬于之前與 A 服務(wù)器建立連接的 Client，因?yàn)?B 服務(wù)器沒有對(duì)應(yīng)的 TCP socket，會(huì)向 Client 發(fā)送 RST 斷開連接。

要解決這個(gè)問題，需要 B 服務(wù)器收到的數(shù)據(jù)包不屬于自己的 socket 后，將這類數(shù)據(jù)包二次轉(zhuǎn)發(fā)給A服務(wù)器。也就是說(shuō) B 服務(wù)器需要知道二次轉(zhuǎn)發(fā)的數(shù)據(jù)包應(yīng)該發(fā)給誰(shuí)，如果把這個(gè)信息存下來(lái)，A 服務(wù)器與 Client 的連接就可以繼續(xù)保持。

為了實(shí)現(xiàn)這一點(diǎn)，我們擴(kuò)展了轉(zhuǎn)發(fā)表。使用四元組 Hash 之后的值，對(duì)應(yīng)兩個(gè) DIP，動(dòng)態(tài)更新后的稱為第一跳，動(dòng)態(tài)更新前的稱為第二跳。

圖片

如果第一跳和第二跳的DIP是一樣的，即使在判斷后發(fā)現(xiàn)數(shù)據(jù)包不屬于第一跳服務(wù)器，也不需要做第二跳的判斷和轉(zhuǎn)發(fā)，因此實(shí)際我們只需要保留發(fā)生變化的部分。

圖片

關(guān)于二次轉(zhuǎn)發(fā)的邏輯，主要分為以下三個(gè)部分：

如果數(shù)據(jù)包是 SYN，則在第一跳服務(wù)器上新建一個(gè)連接，保證新連接的數(shù)據(jù)包都在第一跳服務(wù)器上處理。
非SYN的數(shù)據(jù)包，需要檢查第一跳服務(wù)器上是否存在相應(yīng)的 socket。如果存在，則交由第一跳服務(wù)器處理。
第一跳不存在對(duì)應(yīng)的 socket，則將該數(shù)據(jù)包轉(zhuǎn)發(fā)給第二跳服務(wù)器。如果發(fā)現(xiàn)第二跳為空則將該數(shù)據(jù)包丟棄。

如果出現(xiàn)需要轉(zhuǎn)發(fā)到第二跳的情況，因?yàn)槎噢D(zhuǎn)發(fā)了一次數(shù)據(jù)包，所以在一定程度上會(huì)造成帶寬的增大。但是隨著新連接的建立，老連接的斷開，需要二次轉(zhuǎn)發(fā)的數(shù)據(jù)包比例會(huì)很快降低。

圖片

同時(shí)從理論上來(lái)說(shuō)，只要某個(gè) Client 的連接時(shí)間足夠長(zhǎng)，經(jīng)過多次轉(zhuǎn)發(fā)表動(dòng)態(tài)調(diào)整，比如第一跳和第二跳都不是A服務(wù)器，那么這個(gè) Client 會(huì)因?yàn)槭盏?RST 而斷開。基于當(dāng)前的調(diào)整策略，這種情況是不可避免的。對(duì)此我們?cè)谡{(diào)整頻率和調(diào)整策略上都做了以下優(yōu)化：

控制最快調(diào)整時(shí)間間隔；
優(yōu)先選擇通過第一跳和第二跳對(duì)換即可實(shí)現(xiàn)調(diào)整目標(biāo)的桶；
優(yōu)先選擇最近調(diào)整次數(shù)最少的桶；
避免表項(xiàng)大規(guī)模調(diào)整，小步迭代；
盡可能保證表項(xiàng)連續(xù)性，減少碎片等；

2.3 數(shù)據(jù)面

控制面維護(hù)的轉(zhuǎn)發(fā)表是來(lái)指導(dǎo)底層做數(shù)據(jù)轉(zhuǎn)發(fā)的，我們的數(shù)據(jù)轉(zhuǎn)發(fā)模塊使用 XDP 來(lái)實(shí)現(xiàn)，XDP之前在 QUIC 使用其做性能收發(fā)包優(yōu)化[4]時(shí)也有介紹，它是 Linux 內(nèi)核網(wǎng)絡(luò)棧的最底層集成的數(shù)據(jù)包處理器。當(dāng)網(wǎng)絡(luò)包到達(dá)內(nèi)核時(shí)，XDP 程序會(huì)在早期被執(zhí)行，跳過了內(nèi)核協(xié)議棧，提高了包處理的效率，XDP 共有3種模式：

Offload：XDP 的 eBPF 程序直接 hook 到可編程網(wǎng)卡硬件設(shè)備上，而不是在主機(jī) CPU 上執(zhí)行。因?yàn)樵撃Ｊ綄?zhí)行從 CPU 上移出，并且處于數(shù)據(jù)鏈路的最前端，過濾效率與性能最高。
Native：XDP的 eBPF 程序在網(wǎng)絡(luò)驅(qū)動(dòng)程序的早期接收路徑之外直接運(yùn)行。
Generic：可以在沒有硬件或驅(qū)動(dòng)程序支持的主機(jī)上執(zhí)行上執(zhí)行 XDP 的 eBPF 程序。缺點(diǎn)：仿真執(zhí)行，需要分配額外的套接字緩沖區(qū)，導(dǎo)致性能下降。

Offload 模式雖性能最優(yōu)但需要特定硬件的支持，Native 模式為最常用的模式，掛載在驅(qū)動(dòng)路徑上，需要驅(qū)動(dòng)的支持，Generic 模式是內(nèi)核模擬出的一種模式，不依賴于網(wǎng)卡驅(qū)動(dòng)，不過掛載點(diǎn)靠后，性能在三種模式種最差。綜合邊緣節(jié)點(diǎn)機(jī)器網(wǎng)卡、系統(tǒng)等因素，我們?cè)谏a(chǎn)環(huán)境選用Native 模式。

圖片

控制面維護(hù)的轉(zhuǎn)發(fā)表，傳遞到XDP模塊時(shí)，其本身是一個(gè)類型為 map in map 的 eBPF map。外側(cè)的 map key 為用戶訪問的服務(wù)二元組，即服務(wù)的 IP 和 Port，外側(cè)的 map value 對(duì)應(yīng)內(nèi)側(cè)的 eBPF map對(duì)象；內(nèi)側(cè)的 map key 為桶的編號(hào)，即 Hash 的索引值，value 為一個(gè) simple C struct, 內(nèi)部存儲(chǔ)了第一跳和第二跳的IP地址。數(shù)據(jù)面在進(jìn)行相應(yīng)的 hash value calculation 之后，找到一對(duì) Hop IPs，將用戶的原始數(shù)據(jù)包封入由該 Hop IPs 組成的 GUE header 中。

GUE header[5] 為 Github LB 使用的一個(gè)私有頭格式，詳細(xì)見下圖。在封包完成后，XDP 將該數(shù)據(jù)包傳輸給對(duì)應(yīng)機(jī)器，在該機(jī)器上，由 TC 通過四元組判斷該連接是否已存在；如果存在，則將該數(shù)據(jù)包解封并傳輸給上層；如果不存在，則根據(jù) GUE header 轉(zhuǎn)發(fā)給下一跳。

圖片

在 TC 解封完成后，如果此邊緣集群支持 VIP，并且服務(wù)監(jiān)聽了該 VIP，其已經(jīng)可以正常通過 Linux 網(wǎng)絡(luò)協(xié)議棧的 Socket 拿到數(shù)據(jù)包，由于目前我司邊緣集群尚不支持 VIP，除非通過 ip_transparent 等特殊手段，否則后端服務(wù)器上的服務(wù)無(wú)法監(jiān)聽作為 LB 的機(jī)器的 IP。為了使后端服務(wù)無(wú)感，我們選擇使用過渡手段的 netfilter conntrack 對(duì) ingress 數(shù)據(jù)包進(jìn)行 SNAT (Source Network Address Translation) ，并對(duì) egress 數(shù)據(jù)包進(jìn)行 DNAT (Destination NAT) 。由于 conntrack 本身的性能瓶頸，會(huì)限制 Ni 作為 LB 的能力。不過在當(dāng)前線上的業(yè)務(wù)場(chǎng)景下，并不會(huì)達(dá)到 conntrack 的性能瓶頸，邊緣節(jié)點(diǎn)支持 VIP 也在和相關(guān)部門推進(jìn)中，未來(lái)支持后，去掉 NAT 轉(zhuǎn)換 Ni 的性能會(huì)進(jìn)一步提高。

圖片

03 應(yīng)用場(chǎng)景

3.1 動(dòng)態(tài)加速的應(yīng)用

動(dòng)態(tài)加速是在傳統(tǒng) CDN 基礎(chǔ)上實(shí)現(xiàn)的對(duì)數(shù)據(jù)網(wǎng)絡(luò)加速進(jìn)一步優(yōu)化的智能管理服務(wù)，通過全方位的 CDN 質(zhì)量監(jiān)控，以及智能易用的節(jié)點(diǎn)調(diào)度等功能，提供穩(wěn)定快速的網(wǎng)絡(luò)訪問服務(wù)。

動(dòng)態(tài)加速的節(jié)點(diǎn)分布在全國(guó)的各個(gè)地區(qū)，每個(gè)節(jié)點(diǎn)都由多臺(tái)機(jī)器組成。如果將節(jié)點(diǎn)內(nèi)所有機(jī)器全都對(duì)外暴露，可能會(huì)有以下問題：

增加動(dòng)態(tài)智能選路服務(wù)的運(yùn)算量，一定程度上增加排查問題的復(fù)雜度；
如果單臺(tái)機(jī)器不可用時(shí)需要通過遠(yuǎn)端探測(cè)發(fā)現(xiàn)并反饋到選路服務(wù)，進(jìn)而計(jì)算新的路并下發(fā)，流程較長(zhǎng)，造成路徑切換變慢；
動(dòng)態(tài)加速機(jī)房多為過保機(jī)器，存在硬件配置殘次不齊的情況，性能好的機(jī)器應(yīng)該處理更多的業(yè)務(wù)請(qǐng)求；

部署Ni之后

將機(jī)房?jī)?nèi)機(jī)器組成一個(gè)集群，收斂流量入口；
通過主動(dòng)健康檢查實(shí)時(shí)將不可用服務(wù)摘流，集群外部無(wú)感，服務(wù)恢復(fù)后自動(dòng)加回；
檢查集群內(nèi)機(jī)器的 CPU 使用情況，并根據(jù)配置參數(shù)做出實(shí)時(shí)調(diào)整；

圖片

下圖為紅色部分代表機(jī)器 CPU 升高超出閾值后，自動(dòng)將該機(jī)器接流占比減小的監(jiān)控。

圖片

3.2 點(diǎn)直播CDN集群化場(chǎng)景的應(yīng)用

單個(gè)點(diǎn)直播集群內(nèi)可能有幾臺(tái)或幾十臺(tái)機(jī)器，調(diào)度服務(wù)從感知資源池內(nèi)機(jī)器狀態(tài)變化到對(duì)用戶的請(qǐng)求做出反應(yīng)，可能會(huì)有分鐘級(jí)的延遲，存在一定的滯后性。且在多機(jī)房、多機(jī)器的調(diào)度場(chǎng)景下，基于調(diào)度服務(wù)的負(fù)載均衡也難以完全將流量打均。將負(fù)載均衡能力下沉到機(jī)房?jī)?nèi)之后，反應(yīng)時(shí)間可以降低到秒級(jí)，靈敏度更高。同時(shí)流量調(diào)度的的控制粒度也可以做到更加精細(xì)，更有利于提升邊緣集群的利用率。

圖片

下圖為某機(jī)房部分機(jī)器部署Ni前后48小時(shí)的的 QPS 對(duì)比，可以看到部署之后可以將請(qǐng)求平均分配到各機(jī)器，進(jìn)而平衡 CPU 使用率。

圖片

說(shuō)明：因業(yè)務(wù)特性未開啟根據(jù)負(fù)載動(dòng)態(tài)調(diào)整功能。在均衡請(qǐng)求量相同的情況下，因視頻資源不同等因素，CPU 會(huì)存在一定的差異。

04 未來(lái)展望

目前 Ni 已在動(dòng)態(tài)加速大節(jié)點(diǎn)及點(diǎn)直播 CDN 集群化場(chǎng)景全量。穩(wěn)定運(yùn)行保障S13 直播賽事。不過仍有需要補(bǔ)齊和優(yōu)化的地方。

支持黑白名單，通過 XDP 過濾邊緣的攻擊；
支持 RFC QUIC-LB 定義的規(guī)則；
支持基于 VIP 的 DSR 模式，消除因Conntrack造成的限制，進(jìn)一步降低負(fù)載；

參考鏈接：

[1] https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer/

[2] https://github.com/dropbox/kglb

[3] https://www.usenix.org/system/files/conference/nsdi18/nsdi18-olteanu.pdf

[4] https://mp.weixin.qq.com/s/uPHVo-4rGZNvPXLKHPq9QQ

[5] https://github.com/github/glb-director/blob/master/docs/development/gue-header.md

李宇星

本期作者

李宇星嗶哩嗶哩資深開發(fā)工程師

馮學(xué)銘嗶哩嗶哩高級(jí)開發(fā)工程師

劉宏強(qiáng)嗶哩嗶哩資深開發(fā)工程師

本文鏈接：http://www.tebozhan.com/showinfo-26-40681-0.htmlB站邊緣網(wǎng)絡(luò)四層負(fù)載均衡器的探索與應(yīng)用

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com

上一篇：編程語(yǔ)言大比拼：Python、Java、C、C++、Go 實(shí)現(xiàn) 'Hello World' 和九九乘法表"

下一篇：你了解 JSX，那你了解 StyleX 么？

標(biāo)簽：

熱門焦點(diǎn)

官方承諾：K60至尊版將會(huì)首批升級(jí)MIUI 15

全新的MIUI 15今天也有了消息，在官宣了K60至尊版將會(huì)搭載天璣9200+處理器和獨(dú)顯芯片X7的同時(shí)，Redmi給出了官方承諾，K60至尊重大更新首批升級(jí)，會(huì)首批推送MIUI 15。也就是說(shuō)雖然
vivo TWS Air開箱體驗(yàn)：真輕臻好聽

在vivo S15系列新機(jī)的發(fā)布會(huì)上，vivo的最新款真無(wú)線藍(lán)牙耳機(jī)vivo TWS Air也一同發(fā)布，本次就這款耳機(jī)新品給大家?guī)?lái)一個(gè)簡(jiǎn)單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產(chǎn)
深度探索 Elasticsearch 8.X：function_score 參數(shù)解讀與實(shí)戰(zhàn)案例分析

在 Elasticsearch 中，function_score 可以讓我們?cè)诓樵兊耐瑫r(shí)對(duì)搜索結(jié)果進(jìn)行自定義評(píng)分。function_score 提供了一系列的參數(shù)和函數(shù)讓我們可以根據(jù)需求靈活地進(jìn)行設(shè)置。近期
10天營(yíng)收超1億美元，《星鐵》比《原神》差在哪？

來(lái)源：伯虎財(cái)經(jīng)作者：陳平安即便你沒玩過《原神》，你一定聽說(shuō)過的它的大名。恨它的人把《原神》開服那天稱作是中國(guó)游戲史上最黑暗的一天，有粉絲因?yàn)樗髂嵩赑S平臺(tái)上線《原神》，怒而
“又被陳思誠(chéng)騙了”

作者｜張思齊出品｜眾面（ID：ZhongMian_ZM）如今的國(guó)產(chǎn)懸疑電影，成了陳思誠(chéng)的天下。最近大爆電影《消失的她》票房突破30億斷層奪魁暑期檔，陳思誠(chéng)再度風(fēng)頭無(wú)兩。你可以說(shuō)陳思誠(chéng)的
三星獲批量產(chǎn)iPhone 15全系屏幕：蘋果史上最驚艷直屏

按照慣例，蘋果將繼續(xù)在今年9月舉辦一年一度的秋季新品發(fā)布會(huì)，有傳言稱發(fā)布會(huì)將于9月12日舉行，屆時(shí)全新的iPhone 15系列將正式與大家見面，不出意外的話
蘋果公司要求三星和LG Display生產(chǎn)「無(wú)邊框」OLED iPhone顯示屏

據(jù) The Elec 報(bào)道，蘋果已要求其供應(yīng)商為未來(lái)的 iPhone 型號(hào)開發(fā)「無(wú)邊框」OLED 顯示面板。蘋果顯然已要求三星和 LG Display 開發(fā)新的 OLED 顯示面
iQOO Neo8系列今日官宣：首發(fā)天璣9200+ 全球安卓最強(qiáng)芯！

在昨日舉行的的聯(lián)發(fā)科新一代旗艦芯片天璣9200+的發(fā)布會(huì)上，iQOO官方也正式宣布，全新的iQOO Neo8系列新品將全球首發(fā)搭載這款當(dāng)前性能最強(qiáng)大的移動(dòng)平臺(tái)
2021中國(guó)國(guó)際消費(fèi)電子博覽會(huì)與青島國(guó)際軟件融合創(chuàng)新博覽會(huì)新聞發(fā)布會(huì)隆重舉行

9月18日，2021中國(guó)國(guó)際消費(fèi)電子博覽會(huì)與青島國(guó)際軟件融合創(chuàng)新博覽會(huì)新聞發(fā)布會(huì)在青島國(guó)際新聞中心隆重舉行。發(fā)布會(huì)上青島市政府領(lǐng)導(dǎo)聯(lián)袂出席，對(duì)本次雙展會(huì)情

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

B站邊緣網(wǎng)絡(luò)四層負(fù)載均衡器的探索與應(yīng)用

01 背景介紹

02 架構(gòu)設(shè)計(jì)

2.1 總體設(shè)計(jì)

2.2 控制面

2.3 數(shù)據(jù)面

03 應(yīng)用場(chǎng)景

3.1 動(dòng)態(tài)加速的應(yīng)用

3.2 點(diǎn)直播CDN集群化場(chǎng)景的應(yīng)用

04 未來(lái)展望

參考鏈接：

官方承諾：K60至尊版將會(huì)首批升級(jí)MIUI 15

vivo TWS Air開箱體驗(yàn)：真輕臻好聽

深度探索 Elasticsearch 8.X：function_score 參數(shù)解讀與實(shí)戰(zhàn)案例分析

10天營(yíng)收超1億美元，《星鐵》比《原神》差在哪？

“又被陳思誠(chéng)騙了”

三星獲批量產(chǎn)iPhone 15全系屏幕：蘋果史上最驚艷直屏

蘋果公司要求三星和LG Display生產(chǎn)「無(wú)邊框」OLED iPhone顯示屏

iQOO Neo8系列今日官宣：首發(fā)天璣9200+ 全球安卓最強(qiáng)芯！

2021中國(guó)國(guó)際消費(fèi)電子博覽會(huì)與青島國(guó)際軟件融合創(chuàng)新博覽會(huì)新聞發(fā)布會(huì)隆重舉行

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊