基于KubeEdge实现中国移动10086客服云边协同平台

【导读】在线营销服务中心是中国移动通信集团二级专业机构，负责全网在线服务资源和线上渠道运营管理，拥有全球最 大的呼叫中心 ，自有坐席4.4万，服务用户9亿，53个客服中心，是客服技术和客服业务的时代引领者。中心已承接中国移动10086全网在线服务包括（中国移动APP、门户网站、小程 序、热线、短信、直播、实名认证等）服务渠道的集中化运营。形成了“31省+ 两园区”的整体格局，是集团公司下聚焦于数字化服务的全国性二级专业机构。

一、公司基础架构变更历程

在线营销服务中心在2014年10月成立，具体定位如下：

1. 线上渠道的生产运营者
2. 在线服务的全网提供者
3. 全网生态合作运营的支撑者
4. 智能化营销服务能力的构建者

经过一些系列改革发展，公司在2016年底将中国移动各省的10086呼叫业务全部整合至中移在线公司，实行专业化经营，并在2018年入选国资委“双百行动”企业。

在线营销服务中心的云服务基础架构也经历了虚拟化阶段到云原生阶段的过渡进化，我们都知道在虚拟化阶段，大家普遍利用VMware技术进行虚拟化利用，但是VMware简单虚拟化，资源发放效率低，资源不具备弹性伸缩能力，业务高峰无法快速扩容资源，系统服务存在很大的弊端。 

到了云计算阶段，OpenStack+KVM资源池是普遍的方案，但是虚拟化资源利用率低，自动弹性伸缩不足，无法应对驼峰式流量，业务集中化需求也大幅增加，研发交付效率下降。这种架构方案也渐渐不能满足日益增长的业务量和开发需求迭代。

随着云边协同阶段的到来，在线营销服务中心使用KubeEdge框架，将容器云能力向分公司下沉，打造中心 + 边缘一朵云的方案，加速基础设施云改，成功应对住了考验。

接下来，我们介绍一下在线营销服务中心是如何选型云边协同方案的。

二、云边协同方案具体选型

公司核心的融合客服系统具有“话务集中控制、媒体就近接入”的架构特性，需在各省分公司机房部署少量的服务器设备，所 以全网服务器资源形成以双中心+31省分公司为接入点的星状拓扑结构。另外为解决网络时延、音视频数据传输等瓶颈，满足营销服 务业务高标准的用户体验要求，公司视频客服、全语音门户等多媒体业务系统向分公司下沉部署。

这种情况下，分公司资源池会出现如下问题：

1. 业务支撑响应慢。分公司业务系统存在独立资源池的“烟囱式”问题，系统间的服务器资源无法共享，敏捷性较差，无法实现系统快速弹性扩缩容，影响营销服务业务的客户体验和系统稳定性。

2. 业务运维效率低。分公司部署的业务模块均为人工手动维护，人工操作易出错、效率低、故障率高。

3. 资源利用率低。目前分公司服务器以传统虚拟化技术为主要支撑形态，导致算力无法聚合，资源利用不充分，低效、冗余资源亟需整合利旧。

边缘存在形态主要有两种即边缘集群和边缘节点，其中，边缘集群具备全量管理的能力，额外的控制层实现协同。而边缘节点，具备服用云端管理能力、云边协同、离线自治、支持原生K8S API等优点。

边缘节点形态下，当前主流的开源项目有三个，分别是KubeEdge、OpenYurt和SuperEdge。

对比截图下：

基于轻量级容器编排框架的KubeEdge云边协同技术，打造“中心+边缘”的云边协同架构，实现以本部双中心服务器为中心节点，分公司为边缘节点的“计算拉伸方案”落地，将容器云计算能力下沉至边缘节点，实现统一的资源调度和纳管能力。

那么基于KubeEdge框架的云边协同技术具备哪些明显的优势呢？

1. 集中管理，通过统一容器管理平台进行集群的管理。

2. 边缘纳管，基于KubeEdge框架完成边缘节点的纳管。

3. 离线自治，EdgeCore基础上增加边缘代理，提升离线自治能力。

4. CI/CD，复用管理平台CICD构建能力， 提升服务发布效率。

5. 云边协同，构建数据协同、管理协同、运维协同的平台。

三、落地阶段问题以及解决方案介绍

边缘节点网络可选模型较多，综合分析对比，确定落地网络方案，实现分公司内流量闭环。从可选规范，CNI、CNM、EdgeMesh中确定了CNI规范。因为CNI规范，全拼是 Container Network Interface，是由CoreOS提出的一个容器网络规范。已采纳改规范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。 另外 Contiv Networking, Project Calico 和 Weave这些项目也为CNI提供插件，兼容性和适用性更强。

同时，基于分公司节点与分公司容器边缘节点网络互通和分公司边缘Pod访问总部服务两种场景的需要，在线营销服务中心的最终结论是使用calico ipip网络。

常规的租户分区模式有资源配额限制，资源碎片化较为严重，不能有效的支撑容器云弹性伸缩的特性，不适合企业级大规模应用。

KubeEdge框架自身主要提供容器云计算能力的下沉，EdgeMesh模块提供了简单的服务暴露能力，但不能友好 支撑七层的负载均衡，因此决定将云端的能力下沉。

边缘服务访问和服务分组分流有哪些形式呢？

1. 流量隔离，为应对超大规模流量接入，实现流量隔离，定义多IngressController并分配给一个或多个租户。
2. 分组部署，支持分组部署，满足应用系统的故障隔离，并缩小故障影响范围。
3. 灰度发布，为及早获得用户反馈，降低新应用升级的影响，将特定用户的请求分发到灰度服务 ，从而控制风险，并对产品特性的发布有一个循序渐进的迭代过程。
4. 无感知发布，采用主备服务模式，在发布过程中按照流量比例进行实例自动伸缩，从而达到业务无中断、用户无感知。

同时，由于云边网络质量较差，采用统一的云端镜像仓库，镜像拉取可对网络带来较大的冲击，设计分级镜像仓库，降低镜 像拉取对网络的冲击。采用Prometheus + AlertManager + Grafana的形式监控，打造“中心+边缘”联邦式监控。原生CNI组件基本上依赖云端能力（APIServer/ETCD），离线时无法完成IP分配，建设IP快照能力，实现Pod IP 在离线重启保持不变。大边缘场景下，下沉较多的云端能力，构建边缘代理，提升系统组件离线自治能力，全面建设节点级别离线自治能力。采用两级隔离架构，实现自动监测、自动隔离等功能，全面覆盖集群关键组件及Node故障等场景，有效降低业务故障时间，保障业务持续稳定运行。

四、KubeEdge社区贡献

在线营销服务中心的服务架构得益于KubeEdge开源项目，那么它们为KubeEdge开源社区做了哪些贡献呢？主要有下面四方面：

1. keadm debug工具套件。丰富边缘节点故障时排查手段，简化边缘问题排查方式。主要包含keadm debug get/check/diagnose/collect命令。
2. CloudCore内存占用优化。优化CloudCore内部 informer、client的使用方式，精简LocationCache缓存数据，整体内存占用降低40%左右。
3. 节点默认标签和污点。边缘节点启动时默认增加指定的label和taint，简化边缘节点添加特定属性的操作流程。
4. 主机资源预留。边缘节点预留系统资源，允许设置节点最大Pod数，避免整体资源被Pod全部占用，提升边缘节点的稳定性。

五、总结&未来演进方向

中移在线从社区出发，基于KubeEdge云边协同框架，提升了对边缘的纳管能力以及服务发布效率。同时，深入业务，满足业务是第一优先级，提供合理的 网络方案以及负载均衡方案。完善周边，构建分级镜像仓库，联邦监控等不断完善日常使用环节。基于场景驱动，细化故障场景，打造全面的故障隔离 方案，缩小故障影响范围。从落地出发，完善KubeEdge能力，做社区贡献，进而做到回馈社区。再次从社区出发，进入新的良性循环。

未来演进的两个方向，一是统一负载架构，边缘节点基于kubevirt的统一负载架构（虚拟化和容器）。二是边缘中间件服务纳管，完成对边缘的中间件服务容器化的纳管。

最后，需要说明的是中移在线的工作模式为我们树立了一个标杆，或者说为我们指明了一个大概的方向，我们在吸收他人先进技术为我所用的同时，也可以贡献自己的力量。