【云駐共創(chuàng)】基于KubeEdge實現(xiàn)中國移動10086客服云邊協(xié)同平臺

【導(dǎo)讀】在線營銷服務(wù)中心是中國移動通信集團二級專業(yè)機構(gòu)，負(fù)責(zé)全網(wǎng)在線服務(wù)資源和線上渠道運營管理，擁有全球最 大的呼叫中心 ，自有坐席4.4萬，服務(wù)用戶9億，53個客服中心，是客服技術(shù)和客服業(yè)務(wù)的時代引領(lǐng)者。中心已承接中國移動10086全網(wǎng)在線服務(wù)包括（中國移動APP、門戶網(wǎng)站、小程 序、熱線、短信、直播、實名認(rèn)證等）服務(wù)渠道的集中化運營。形成了“31省+ 兩園區(qū)”的整體格局，是集團公司下聚焦于數(shù)字化服務(wù)的全國性二級專業(yè)機構(gòu)。

一、公司基礎(chǔ)架構(gòu)變更歷程

在線營銷服務(wù)中心在2014年10月成立，具體定位如下：

線上渠道的生產(chǎn)運營者

在線服務(wù)的全網(wǎng)提供者

全網(wǎng)生態(tài)合作運營的支撐者

智能化營銷服務(wù)能力的構(gòu)建者

經(jīng)過一些系列改革發(fā)展，公司在2016年底將中國移動各省的10086呼叫業(yè)務(wù)全部整合至中移在線公司，實行專業(yè)化經(jīng)營，并在2018年入選國資委“雙百行動”企業(yè)。

在線營銷服務(wù)中心的云服務(wù)基礎(chǔ)架構(gòu)也經(jīng)歷了虛擬化階段到云原生階段的過渡進化，我們都知道在虛擬化階段，大家普遍利用VMware技術(shù)進行虛擬化利用，但是VMware簡單虛擬化，資源發(fā)放效率低，資源不具備彈性伸縮能力，業(yè)務(wù)高峰無法快速擴容資源，系統(tǒng)服務(wù)存在很大的弊端。

到了云計算階段，OpenStack+KVM資源池是普遍的方案，但是虛擬化資源利用率低，自動彈性伸縮不足，無法應(yīng)對駝峰式流量，業(yè)務(wù)集中化需求也大幅增加，研發(fā)交付效率下降。這種架構(gòu)方案也漸漸不能滿足日益增長的業(yè)務(wù)量和開發(fā)需求迭代。

隨著云邊協(xié)同階段的到來，在線營銷服務(wù)中心使用KubeEdge框架，將容器云能力向分公司下沉，打造中心 + 邊緣一朵云的方案，加速基礎(chǔ)設(shè)施云改，成功應(yīng)對住了考驗。

接下來，我們介紹一下在線營銷服務(wù)中心是如何選型云邊協(xié)同方案的。

二、云邊協(xié)同方案具體選型

公司核心的融合客服系統(tǒng)具有“話務(wù)集中控制、媒體就近接入”的架構(gòu)特性，需在各省分公司機房部署少量的服務(wù)器設(shè)備，所 以全網(wǎng)服務(wù)器資源形成以雙中心+31省分公司為接入點的星狀拓?fù)浣Y(jié)構(gòu)。另外為解決網(wǎng)絡(luò)時延、音視頻數(shù)據(jù)傳輸?shù)绕款i，滿足營銷服 務(wù)業(yè)務(wù)高標(biāo)準(zhǔn)的用戶體驗要求，公司視頻客服、全語音門戶等多媒體業(yè)務(wù)系統(tǒng)向分公司下沉部署。

這種情況下，分公司資源池會出現(xiàn)如下問題：

1. 業(yè)務(wù)支撐響應(yīng)慢。分公司業(yè)務(wù)系統(tǒng)存在獨立資源池的“煙囪式”問題，系統(tǒng)間的服務(wù)器資源無法共享，敏捷性較差，無法實現(xiàn)系統(tǒng)快速彈性擴縮容，影響營銷服務(wù)業(yè)務(wù)的客戶體驗和系統(tǒng)穩(wěn)定性。

2. 業(yè)務(wù)運維效率低。分公司部署的業(yè)務(wù)模塊均為人工手動維護，人工操作易出錯、效率低、故障率高。

3. 資源利用率低。目前分公司服務(wù)器以傳統(tǒng)虛擬化技術(shù)為主要支撐形態(tài)，導(dǎo)致算力無法聚合，資源利用不充分，低效、冗余資源亟需整合利舊。

邊緣存在形態(tài)主要有兩種即邊緣集群和邊緣節(jié)點，其中，邊緣集群具備全量管理的能力，額外的控制層實現(xiàn)協(xié)同。而邊緣節(jié)點，具備服用云端管理能力、云邊協(xié)同、離線自治、支持原生K8S API等優(yōu)點。

邊緣節(jié)點形態(tài)下，當(dāng)前主流的開源項目有三個，分別是KubeEdge、OpenYurt和SuperEdge。

對比截圖下：

基于輕量級容器編排框架的KubeEdge云邊協(xié)同技術(shù)，打造“中心+邊緣”的云邊協(xié)同架構(gòu)，實現(xiàn)以本部雙中心服務(wù)器為中心節(jié)點，分公司為邊緣節(jié)點的“計算拉伸方案”落地，將容器云計算能力下沉至邊緣節(jié)點，實現(xiàn)統(tǒng)一的資源調(diào)度和納管能力。

那么基于KubeEdge框架的云邊協(xié)同技術(shù)具備哪些明顯的優(yōu)勢呢？

1. 集中管理，通過統(tǒng)一容器管理平臺進行集群的管理。

2. 邊緣納管，基于KubeEdge框架完成邊緣節(jié)點的納管。

3. 離線自治，EdgeCore基礎(chǔ)上增加邊緣代理，提升離線自治能力。

4. CI/CD，復(fù)用管理平臺CICD構(gòu)建能力， 提升服務(wù)發(fā)布效率。

5. 云邊協(xié)同，構(gòu)建數(shù)據(jù)協(xié)同、管理協(xié)同、運維協(xié)同的平臺。

三、落地階段問題以及解決方案介紹

邊緣節(jié)點網(wǎng)絡(luò)可選模型較多，綜合分析對比，確定落地網(wǎng)絡(luò)方案，實現(xiàn)分公司內(nèi)流量閉環(huán)。從可選規(guī)范，CNI、CNM、EdgeMesh中確定了CNI規(guī)范。因為CNI規(guī)范，全拼是 Container Network Interface，是由CoreOS提出的一個容器網(wǎng)絡(luò)規(guī)范。已采納改規(guī)范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。 另外 Contiv Networking, Project Calico 和 Weave這些項目也為CNI提供插件，兼容性和適用性更強。

同時，基于分公司節(jié)點與分公司容器邊緣節(jié)點網(wǎng)絡(luò)互通和分公司邊緣Pod訪問總部服務(wù)兩種場景的需要，在線營銷服務(wù)中心的最終結(jié)論是使用calico ipip網(wǎng)絡(luò)。

常規(guī)的租戶分區(qū)模式有資源配額限制，資源碎片化較為嚴(yán)重，不能有效的支撐容器云彈性伸縮的特性，不適合企業(yè)級大規(guī)模應(yīng)用。

KubeEdge框架自身主要提供容器云計算能力的下沉，EdgeMesh模塊提供了簡單的服務(wù)暴露能力，但不能友好 支撐七層的負(fù)載均衡，因此決定將云端的能力下沉。

邊緣服務(wù)訪問和服務(wù)分組分流有哪些形式呢？

流量隔離，為應(yīng)對超大規(guī)模流量接入，實現(xiàn)流量隔離，定義多IngressController并分配給一個或多個租戶。

分組部署，支持分組部署，滿足應(yīng)用系統(tǒng)的故障隔離，并縮小故障影響范圍。

灰度發(fā)布，為及早獲得用戶反饋，降低新應(yīng)用升級的影響，將特定用戶的請求分發(fā)到灰度服務(wù) ，從而控制風(fēng)險，并對產(chǎn)品特性的發(fā)布有一個循序漸進的迭代過程。

無感知發(fā)布，采用主備服務(wù)模式，在發(fā)布過程中按照流量比例進行實例自動伸縮，從而達(dá)到業(yè)務(wù)無中斷、用戶無感知。

同時，由于云邊網(wǎng)絡(luò)質(zhì)量較差，采用統(tǒng)一的云端鏡像倉庫，鏡像拉取可對網(wǎng)絡(luò)帶來較大的沖擊，設(shè)計分級鏡像倉庫，降低鏡 像拉取對網(wǎng)絡(luò)的沖擊。采用Prometheus + AlertManager + Grafana的形式監(jiān)控，打造“中心+邊緣”聯(lián)邦式監(jiān)控。原生CNI組件基本上依賴云端能力（APIServer/ETCD），離線時無法完成IP分配，建設(shè)IP快照能力，實現(xiàn)Pod IP 在離線重啟保持不變。大邊緣場景下，下沉較多的云端能力，構(gòu)建邊緣代理，提升系統(tǒng)組件離線自治能力，全面建設(shè)節(jié)點級別離線自治能力。采用兩級隔離架構(gòu)，實現(xiàn)自動監(jiān)測、自動隔離等功能，全面覆蓋集群關(guān)鍵組件及Node故障等場景，有效降低業(yè)務(wù)故障時間，保障業(yè)務(wù)持續(xù)穩(wěn)定運行。

四、KubeEdge社區(qū)貢獻(xiàn)

在線營銷服務(wù)中心的服務(wù)架構(gòu)得益于KubeEdge開源項目，那么它們?yōu)镵ubeEdge開源社區(qū)做了哪些貢獻(xiàn)呢？主要有下面四方面：

keadm debug工具套件。豐富邊緣節(jié)點故障時排查手段，簡化邊緣問題排查方式。主要包含keadm debug get/check/diagnose/collect命令。

CloudCore內(nèi)存占用優(yōu)化。優(yōu)化CloudCore內(nèi)部 informer、client的使用方式，精簡LocationCache緩存數(shù)據(jù)，整體內(nèi)存占用降低40%左右。

節(jié)點默認(rèn)標(biāo)簽和污點。邊緣節(jié)點啟動時默認(rèn)增加指定的label和taint，簡化邊緣節(jié)點添加特定屬性的操作流程。

主機資源預(yù)留。邊緣節(jié)點預(yù)留系統(tǒng)資源，允許設(shè)置節(jié)點最大Pod數(shù)，避免整體資源被Pod全部占用，提升邊緣節(jié)點的穩(wěn)定性。

五、總結(jié)&未來演進方向

中移在線從社區(qū)出發(fā)，基于KubeEdge云邊協(xié)同框架，提升了對邊緣的納管能力以及服務(wù)發(fā)布效率。同時，深入業(yè)務(wù)，滿足業(yè)務(wù)是第一優(yōu)先級，提供合理的 網(wǎng)絡(luò)方案以及負(fù)載均衡方案。完善周邊，構(gòu)建分級鏡像倉庫，聯(lián)邦監(jiān)控等不斷完善日常使用環(huán)節(jié)。基于場景驅(qū)動，細(xì)化故障場景，打造全面的故障隔離 方案，縮小故障影響范圍。從落地出發(fā)，完善KubeEdge能力，做社區(qū)貢獻(xiàn)，進而做到回饋社區(qū)。再次從社區(qū)出發(fā)，進入新的良性循環(huán)。

未來演進的兩個方向，一是統(tǒng)一負(fù)載架構(gòu)，邊緣節(jié)點基于kubevirt的統(tǒng)一負(fù)載架構(gòu)（虛擬化和容器）。二是邊緣中間件服務(wù)納管，完成對邊緣的中間件服務(wù)容器化的納管。

最后，需要說明的是中移在線的工作模式為我們樹立了一個標(biāo)桿，或者說為我們指明了一個大概的方向，我們在吸收他人先進技術(shù)為我所用的同時，也可以貢獻(xiàn)自己的力量。

本文整理自【華為云社區(qū)內(nèi)容共創(chuàng)者火熱招募中】第四彈：耕耘五月，步履不停！

查看活動詳情：https://bbs.huaweicloud.com/blogs/266530

視頻鏈接：https://live.huawei.com/hdc2021/meeting/cn/8045.html

客服 容器

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。