鹅厂车联网探索：5G下边缘云计算的车路协同实践

导语 | 5G网络下，多接入边缘计算（MEC）应运而生。结合TKEStack强大的集群管理能力和异构计算资源管理能力，腾讯打造了一个功能完备的边缘计算PaaS平台TMEC，提供了高精确度定位、视频处理、无线网络QoS控制和5G切片等多种特色业务能力，很好地支撑了车路协同、5G云游戏、视频直播等应用。本文是腾讯云技术专家杨勇&何猛老师在「云加社区沙龙online」的分享整理，希望与大家一同交流。

一、5G典型应用场景及其挑战 

1. 从自动驾驶说起 

自动驾驶在国际是非常热的话题，业界的标准分成了不同的等级，有的分成了5级、有的分成了6级。

如上图所示，国家工信部相关规范将自动驾驶等级标准定义为6级。目前国内的厂家和国际的一些厂家，绝大部分处于处于L2或者L3的水平。腾讯也有自动驾驶相关的产品，目前有数百人的团队从事自动驾驶等相关产品和技术的研发工作。

从实践落地的角度看，自动驾驶汽车商用的成熟性目前来看并不高，这中间存在很多问题，其中技术、成本和安全是阻碍自动驾驶产品规模商用的主要因素。

2. 自动驾驶技术和挑战 

典型的自动驾驶车辆涉及到硬件和相关软术的系统性挑战。主要包括以下四个方面：

第一是高精地图，其中包括厘米级精度、丰富的路标数据和三维重建能力。 

第二是多传感器，其中包括摄像头、激光雷达、毫米波雷达、超声传感器、惯导和卫星天线等。

第三是环境建模及智能决策，其中包括多传感器融合感知、道路和区域识别、环境模型构建、智能预测和决策等。

第四是车身控制，其中包括车辆自动控制、驾驶策略执行及规划。

总体来看，在目前的水平之下，整个自动驾驶车辆因为要安装多种传感器、工控机及系统控制软件，成本比较高昂，而且激光雷达等传感器的使用寿命也比较有限。业内人士曾经估算过，自动驾驶车辆的成本不会低于20万美元，这极大阻碍了自动驾驶汽车产品大规模商用落地。

3. 三大重点因素 

即使自动驾驶车辆配备了这么多的专业传感器和其它专业设备，在一些异常情况下还是不能很好的解决实际路况上出现的一些安全问题，包括特斯拉在内的自动驾驶汽车曾出现多次交通事故，导致财产损失和人员伤亡。

比如，在超视距的情况下，车载传感器包括雷达或者摄像头检测不到转弯前方的车辆，或者从街角对面驶过来一个车辆，就很容易发生交通事故。

刚才也提到了从成本的角度来讲，自动驾驶车辆的成本是非常高昂的。

另外从出行效率角度来讲，作为交通管理部门或城市市政管理部门，提升交通出行效率是他们主要工作目标之一。但自动驾驶车辆在道路上行驶的时候，考虑安全因素，会相应采取一些比较保守的策略。

比如说它的行车速度可能会比较低，同时在发生异常事故的时候，它会减速或者停车避让，这就使得整个交通的效率并不能得到有效的提升。

4. 车联网的技术实现C-V2X 

综合以上因素业界提出了 C-V2X 这个概念，这里面的 C 是蜂窝网络的意思， V2X 的全称是 vehicle to everything，就是说，基于蜂窝通信的 V2X 技术，使得车辆和道路所有参与方都能进行实时的数据交换，通过这种信息交换，来进一步提升包括车辆和其它参与方的安全性，同时提升出行效率。 

我们看到 V2X 主要包括四种场景：

第一个是 V2V（车辆对车辆），它主要解决一些车辆之间的可能发生的一些异常状况，比如说车辆碰撞事件；

第二个是 V2I，就是车辆和路边基础设施，比如红绿灯等，通过车辆和红绿灯的数据交换来及时提醒车辆减速或者保持一定车速，引导车辆通过绿波带，既能提升行车安全，也可以提升车辆出行效率。

第三个 V2N，通过和通讯网络的交互来为驾乘人员提供一些个性化信息服务。

第四个 V2P，通过和行人之间的数据交换，来为行人或非机动车发出一些安全提醒。

C-V2X 的目标总体上涵盖信息服务、交通安全、交通效率和辅助自动驾驶，它的目标之一就是把单车解决不了的问题移到路端去解决，通过路侧设备和车辆之间的 C-V2X消息交互来进一步辅助自动驾驶，提升交通安全能力，提升道路出行效率，形成“聪明的车”和“聪明的路”。

5. 单车智能到云端智能

那么按照“聪明的车”到“聪明的路”的想法，我们是不是可以将完全依靠自动驾驶车辆本身所具备的智能决策能力给它迁移到云端上去实现？这样还可以大幅降低车辆的购置成本，而且因为云端有高性能、可扩展的计算能力，可以做很多车端胜任不了的计算任务。

另外我们知道，现在自动驾驶汽车在车端要做大量的基于计算机视觉或者雷达数据的路况实时分析，这种高性能计算在车辆计算单元上的处理，其准确性等方面还有待提升，如果能移到云端去做，准确性可能会提高很多，而且云端还可以做很多复杂的算术和逻辑运算。

但是这里有一个问题，即云端计算存在的时延问题。自动驾驶智能决策的时延要求非常高，如果移到云端去计算，整个数据链路拉长势必造成时延的增加，这就可能给自动驾驶业务带来严重的影响。例如车辆在高速公路上以120公里/小时的速度行驶，每秒钟就能行驶 30 多米，时延增大就可能会引发严重的交通事故。

所以移到云端是个不错的想法，但它又带来了时延方面的负面因素，这种情况就为边缘计算的部署提供了一个契机。也就是，把云端那些计算任务移到路侧的边缘计算平台上来进行，通过在路侧的基础设施上部署边缘计算平台和车联网的应用，从而对车辆进行实时的智能提醒和决策。

在靠近网络接入的路侧基础设施上进行边缘计算，它的好处是非常明显的。第一，计算能力大幅提升，有利于准确度的提升；第二，不需要占用过多的核心网或者骨干网络带宽；第三，可以有效降低时延，在网络的边缘侧只要通过基站就可以直接将消息分发给路上的终端，数据传输路径比互联网到无线核心网再到无线接入网的路径短了很多，这就是边缘计算在车联网中应用的背景。

二、多接入边缘计算平台及其关键技术 

1. MEC在5G网络中的位置 

边缘计算在车联网里面会发挥着重要作用，目前我们看到各地关于 C-V2X 的新基建建设项目，重点的内容就是 C-V2X应用 和 MEC 服务的建设和部署。 

上图展示了无线网络的架构图及MEC在网络中的位置，左边是一些终端，通过5G基站接入5G核心网络，最终抵达互联网上部署的各种业务。其中核心网分为上面的控制面设备CCF和下面的用户面设备UPF。

控制面有很多的功能实体，这些功能都是 5G 网络专用的核心网网元。MEC需要部署在边缘UPF附近，通过本地分流能力将手机用户的业务请求引导到MEC上，由MEC上部署的应用为其提供服务。

比如说，通常情况下手机访问英特网上的业务，其访问路径是经基站设备到边缘UPF，再经本地UPF汇聚后进入因特网，最后到达云主机，这条路径比较长。

而在边缘计算场景下，业务部署在边缘UPF附近的MEC上，数据传输路径明显短了许多。当用户访问一个边缘应用的时候，我们通过本地分流将用户的请求直接引导到部署在基站侧的 MEC 上，这样它的流量就在靠近网络边缘被处理了，既不占用后端的核心骨干网络的带宽，同时又能降低手机访问网络业务的时延，优势显而易见。

2. 腾讯边缘计算TMEC平台

（1）系统架构

在这种背景下，腾讯提出了边缘计算 TMEC 解决方案。

整个解决方案分成三个层次，最上面是业务层，是TMEC支持的主要的边缘应用，比如云游戏、视频直播、智慧出行、智慧影视、智能制造等。我们看到这些业务绝大部分都和视频相关，这是因为视频在网络中占的带宽非常大，边缘计算可以很好地解决视频相关应用对网络带宽的占用，同时保证手机端的用户体验。

中间层是平台层，我们知道腾讯云有非常丰富的中间件服务，可以为上层应用提供丰富且可靠的基础业务支撑能力。

最下是基础层，它是 TMEC 平台的基础支撑，我们采用腾讯云自研的容器平台TKEStack来实现。

下面简单介绍几个TMEC上部署的特色业务能力。

（2）5G业务能力

TMEC 一个重要的特色业务能力就是 5G 业务能力。

要实现5G业务在边缘计算设备上的部署，必须支持5G网络流量从 UPF分流到边缘计算站点。因而，引流是MEC平台的基本功能，通过与核心网的交互，将终端发给核心网的数据流量依据MEC业务的要求分流到MEC站点并分发给MEC业务处理。         

如上图所示，3GPP标准定义了引流功能的实现。目前引流有多种方案，比较成熟的是基于上行分类器UL CL的引流方案，目前腾讯已经和多个设备厂家进行了对接，实现了从核心网UPF网元到MEC 流量的引导。 

TMEC还支持 5G QoS 和网络切片能力，可以为部署在 TMEC上的应用提供一个可靠的无线通讯 QoS 保障。网络切片是 5G 重要特征，TMEC支持为边缘应用创建专门的网络切片，来进一步保证应用的服务质量。目前这些工作腾讯已经在现网和设备厂家及运营商之间进行了对接。

（3） 视频处理能力

视频类应用是边缘计算典型的应用场景。TMEC提供有高质量的视频转码能力，它是基于用户感兴趣区域ROI的视频编码技术，通过这个技术可以在不影响用户体验质量的情况下，将码率降低30%以上。

3. TKEStack

（1）TKEStack在TMEC架构中的位置

从上图中可以看到，TKEStack是属于基础平台层的解决方案。基础平台层主要解决的问题是为上层业务提供计算资源支撑，解决上层业务的各个服务在服务生命周期内的对计算资源、存储资源、网络的需求问题。

随着容器技术的发展，容器化的服务可以在集群上自由的迁移，服务的可靠性和稳定性得到了更好的保障，同时也带来了一些问题，比如：容器如何编排？编排框架上手难度较大，如何部署和维护？如何节省服务依赖的日志、告警、网络组件的部署维护成本？多个k8s集群如何管理等等问题，TKEStack正是这样一个解决此类问题的容器云平台。

（2）TKEStack基础平台层  

部署安装：

在ToB业务场景里面临的第一个问题就是部署更新问题。针对TKEStack平台部署，我们提供了一个 tke-installer 的工具，工具一键安装后提供一个部署平台的Web页面，用户在Web页面上填写各种平台配置后即可搭建一个global集群用于运行TKEStack平台。

平台部署后为用户提供了一个Web页面，用户通过管理员用户登录到平台后进行业务集群的创建和管理等等。同时平台支持各种扩展插件，用户可以根据需要在自己的业务集群或者global集群一键安装，对集群功能进行扩展。

异构资源虚拟化：

随着AI的兴起，由于需要大量的矩阵乘加计算，X86计算资源已无法满足程序对算力的需求，异构计算硬件慢慢普及开来，如：NVIDIA GPU、intel VPU、NPU等等，异构计算资源往往无法像CPU一样进行分时虚拟，目前TKEStack已经支持了Nvidia GPU 和Intel VPU，后续还会陆续增加对atlas、寒光的支持。

运维报警：

通常情况下，程序出现问题，都是反馈到功能上，然后再由程序开发者层层排查才能解决，在没有独立的日志监控系统情况下，日志查看往往要先到运行这个服务的服务器上排查，这个过程非常麻烦，在实时性要求较高的环境里基本不可接受，否则就要安装一套日志监控系统，开发者要花费精力调研、搭建、维护日志监控系统，TKEStack 集成了日志和监控报警等功能，通过扩展插件形式，一键部署，解决了上层平台的日志报警需求。

（3）TKEStack 能力介绍

上面我们简单介绍了TKEStack的主要功能，接下来我们详细介绍一下TKEStack的各项能力。

安装部署：TKEStaCk页面上通过几步按钮就可以部署一个k8s集群，安装各种平台插件，比如日志 采集、网络、存储等。

租户管理 ：TKEStack提供了租户和用户两层的权限管理。租户层，使用者可以通过划分不同的租户将平台切分成多个平面，各个租户之间互相隔离，适用于不同部门的不同业务依赖的资源各自独立的场景。用户层，同一个租户平面里可以创建各种用户，不同用户可以管理各自的业务，使用自己的业务下的资源创建k8s负载。

原地升级：服务生命周期里，部署成功后下一个问题就是升级更新了，正常k8s上的负载升级是先创建一个新的pod然后销毁旧的pod，在资源紧张情况下，容易导致升级失败，同时无法支持同一个负载下多版本共存，TKEStack的TAPP插件通过一个自定义的CRD，允许用户可以独立操作一个TAPP负载下的每一个POD，比如给单个Pod升级、重启等等。

GPU管理：提供一键安装 GPU 和 Nvidia 相关依赖能力，统一管理由不同型号 GPU 服务器组建的异构容器计算集群；Nvidia GPU，通过劫持cuda调用，实现了一卡多用，多容器共享同一张卡，还具备良好的隔离能力。针对intel VPU的host-device模式的计算资源，通过bridge形式将device和host置于的同一网络平面，解决device节点的网络问题，让device节点正常加入k8s集群进行资源调度。

运维中心：平台具备高可用和可扩展性的细粒度监控告警系统，在此基础上已经支持平台审计、平台事件、平台告警及告警记录查询、日志检索等功能，满足用户各种监控告警需求。

多种网络模式：TKEStack支持underlay和overlay两种模式的k8s网络方案，underlay模式下支持将容器网络和物理网络打通，比如腾讯公有云上，k8s容器和cvm 的vpc打通，容器使用起来更类似于一台cvm，支持用户使用已有的负载均衡对容器内的服务进行负载均衡，overlay模式下改良了原有的flannel，通过ip封包，降低了封包损耗，提升了网络效率。

（4）TKEStack功能图谱

TKEStack作为一个基础平台层解决方案，目前在集群管理、业务管理、应用管理、认证授权、镜像仓库、监控告警、日志、扩展组件等方面都提供了各种各样的功能。

在产品形态上，TKEStac分为平台管理和业务管理，平台管理控制台为用户提供集群、仓库、监控告警、扩展组件方面的管理，满足用户的集群和平台运维需求，业务管理控制台为用户提供业务资源、日志、监控功能，满足业务用户的资源使用需求，同时权限上的划分增强了平台的可用性。

TKEStaCk 功能图谱

（5）TKEStack支持TMEC采用不同的部署模式

在TMEC方案中，TMEC有两种部署模式，中心化部署和边缘自治部署。

中心化部署情况下，在云端中心部署TMEC管控平台和TMEC业务服务，管理边缘节点上的TMEC服务，这种模式下边缘的节点和云端中心处于同一个业务集群。

边缘自治部署模式下，分为云端集群和边缘集群，云端和边缘分别部署整套的管控平台和TMEC业务服务，TMEC管控平台之间进行跨集群通信。

TMEC用户通过TKEStack的控制台入口统一管理边缘集群和中心集群，实现TMEC服务的部署更新和维护。

4. 应用场景

（1）云游戏

云游戏将游戏渲染放在服务器上进行，并将渲染完毕后的游戏画面压缩后以视频流的方式通过网络传送给用户。

在云游戏模式下，客户端的游戏设备并不需要昂贵高端处理器和显卡，而只需具备基本 的视频解压能力和游戏操作能力。

云游戏时代的到来，将会使玩家即便没有高配置的游戏硬件系统，也能畅玩高质量的3A 游戏大作。云游戏能解决用户硬件配置要求过高、游戏包频繁更新、游戏外挂等问题，无需冗长的游戏下载，实现即点即玩。 

（2）多视角直播

多视角观赛即用户可以从多个角度来观看同一场比赛，而不再限制于导播给出的单路画面，比如篮球迷除了可以观看正常的球场侧方视角外，还可以从篮架下方、场边VIP席等多个角度自由体验篮球魅力。

利用TMEC部署边缘应用，可以分别构建场馆内多视角直播平台和多视角直播分发平台。既可以为演播人员提供本地快速编辑、 渲染、和极速分发等能力，也可以为终端用户提供稳定、优质、低时延的观看体验。

三、 基于TMEC的车路协同实践 

1. 基于TMEC构建的V2X车联网平台 

基于TMEC构建了一个车联网 V2X 平台，如下图所示。底层是路侧的基础设施，在平台层，提供多种V2X应用服务能力，为上层的应用开发和运行提供支撑。

2. 云端V2X信息处理：公路部署方案

上图展示了典型的应用部署场景。车辆直接和路侧的无线基站或者 RSU通讯，路侧摄像头和雷达等传感器数据送到路侧MEC计算，然后通过无线基站或者 RSU 把道路的一些异常事件下发给车辆或行人。 

3. 腾讯车路协同产品的特色  

（1）面向应用的集成与定制

根据应用需求，聚合第三方能力，可利用既有道路信息化设施，支持深度定制。 

（2）广泛的C端触达能力

内置腾讯C端（微信、QQ及地图等）触达能力，充分发挥腾讯链接优势，快速提升车路协同渗透率。

（3）高效的云-网-边协同

无线网络与数据中心融合，兼容DSRC、C-V2X、4G及5G等多种网络，智能调度管理边缘应用，实现边缘云和中心云的高效交互。 

（4）灵活轻量化异构部署

轻量化支持物理机、虚拟机、容器等异构部署环境，减少资源消耗，降低业务迁移难度，提升部署效率。

（5）强大的微服务治理能力

服务动态加载，区域感知，智能熔断，全天候监控能力，保证业务智能运行，支持10万+服务规模。

（6）完善的端到端安全能力

提供包括主机安全、网络安全、应用安全、通信安全在内的全套安全解决方案。

4. 车路协同开放平台

整个产品方案涉及到一个庞大的产业链，因而产业生态的建设是需要腾讯和各个厂家合作伙伴一起来完成的。目前在 4G 和 5G 网络上我们和业界主流的厂家都有合作，也做了大量的对接工作，和中国的三大运营商在现网也做了大量的测试验证工作。

另外像车厂、车载终端、路测设备厂家和软件解决方案厂家，我们都欢迎他们参与平台生态建设中来。

四、5G网络多接入边缘计算展望

通过参与5G和行业标准、理论研究和实践验证，腾讯未来网络实验室在 5G 和边缘计算应用方面也积累了一些经验，同时我们也在思考一些遇到的问题。

首先是 5G 标准的滞后和网络大规模建设需求之间的矛盾。我们看到3GPP 5G 网络标准一再推迟，R16、R17 网络标准没有正式发布，这就导致网络侧的互通侧缺乏标准接口定义。所以我们在和 5G 网络的设备厂家去做对接的时候，需要大量的定制化开发，这对边缘计算产品在现网的落地也提出了比较大的挑战。 

其次，整个生态目前参与方还是非常多的，大家的利益有很多互相交错的地方。比如说电信运营商、电信设备商和互联网厂商在边缘计算方面都会有自己的方案，而这些方案存在很多的冲突，包括边缘计算基础设施、边缘计算平台和网络等。如何保证各自的利益，是一个很有挑战性的问题。 

最后，业务方向选择的问题。边缘计算可以支撑To B业务和To C业务，BAT最早一直是做 To C业务的，做 To B 主要就是华为、中兴这些设备厂商和其它一些专业厂商。现在大家都在做 To B业务，竞争越来越激烈。然而 To B项目相对 To C 来说，从项目交付难易程度、利润等各方面都存在挑战。边缘计算作为一个当下的热点，催生出很多初创公司，对于这些公司，选择 To B还是 To C ，同样具有很大挑战性。

Q&A

Q：该平台c/c++开发是否有优势？语言选型有推荐的吗？ 

杨勇：TMEC里面有一个微服务开发框架，它基于腾讯开源项目Tars构建，Tars支持各种语言的，包括 C、C++、Go、Python、Java和js 等等这种常见的语言它都支持，坦白来讲 C++ 做一些高性能应用是非常有优势的，但是C++的开发效率相对其它语言还是比较有挑战性。 

Q：这要真正的落地，这日志维护是不是都是亿级别的啊？

杨勇：日志的存储一般会采用两级存储，即边缘云存储和中心云存储，日志量会比较大，但是有方案可以解决。 

Q：边缘计算跟之前的 P2P 技术有什么异同？

杨勇：我想这应该是两个不同层次的问题，边缘计算主要还是要解决在靠近用户接入的位置为应用提供服务， P2P 主要还是解决用户之间的数据共享和传输问题。 

Q：边缘计算，通讯协议是要多家机构商定和制定吗?安全方面有一些什么具体措施防止信息泄露或被破坏？

杨勇：实际上通讯协议是个大概念，我不知道这里边指的通讯协议是指的哪一块的协议，如果说是和 5G 网络对接的协议，目前一般都是按照 3GPP 的标准来的，因为标准相对比较滞后，所以现在很多厂家都自己定义了接口，比如说 QoS、 5G网络切片、本地分流等这些接口，都是我们跟厂家和运营商一起合作协商来制定的。3GPP 的标准出来之后，应该逐渐会向标准去靠拢的。 

Q：客户端需要什么标识才能通过 UPF 路由到边缘云？

杨勇：按照厂家规范的功能，如果要把终端发往核心网的流量分流到本地的边缘云来，目前一般情况下都是按照IP五元组信息来定义本地分流策略，比如说可以根据IP地址、端口号和协议类型等，我们目前和设备厂家对接也都是按照这些策略来做的，因为绝大部分的应用它的协议和端口都是明确的，当然这些策略也可以支持动态的修改。 

Q：请问这个方案里面的upf以及5gc控制面是用运营商建的？还是你们自建的？ 

杨勇：是运营商建的，都是运营商现网的设备，TMEC是作为在 3GPP 5G标准里面定义的AF 的角色去和5G的核心网网元交互，来实现本地分流的。

Q:  5G是车联网的强依赖吗？目前4G的话能支持部分功能吗？

杨勇：应该说 5G 和车联网是密不可分的，但是部分功能 4G网络 也是可以的，比如说我们就和一个设备厂家对接了在 4G 网络下的本地分流功能。只有分流功能具备了，这个边缘计算平台才能在上面部署业务，才能为移动用户提供边缘服务。在4G网络中由核心网网元SGW把流量送到TMEC平台来。 

Q：边缘计算的计算载体是什么？

杨勇：移动边缘计算它实际上是边缘云和5G网络接入技术的一个结合，所以要说它的计算载体的话，主要是与云计算相关的一些产品和技术，然后上面再叠加一些5G网络相关的能力。实际上3GPP和ETSI定义的MEC，叫多接入边缘计算，它不仅仅支持 5G 网络，包括 WiFi和固定网络，都涵盖在 MEC 的概念里。

Q：我们是做视频分析，道路感知，事件检测等，目前也落地了一些车路协同案例，怎么加入你们的开放生态？

杨勇：刚才也讲到了，整个产业链比较庞大，我们确实目前也是找了好多的合作商合作伙伴，每家都有自己的优势。我们也欢迎相关厂家参与我们的生态建设。如果感兴趣的话，可以联系云加社区小助手，小助手会协助联系对接部门。 

Q：Overlay网络是不是退出历史舞台了？

何猛：个人不认同此观点，Overlay和Underlay属于两种不同的模式，适用于不同的场景，由于IPV4资源有限，Overlay可以方便的组建局域网，不消耗用户IP资源，网络拓扑简单问题排查方便，在AI、大数据的等对算力要求较高，对网络性能无太大要求的场景下还是有很大优势的。

Q：听到TKEStack介绍里有部署k8s集群。请问一下，咱们有没有在传统k8s做一些适配边缘计算的工作？之前看到腾讯有做边缘容器相关工作，不知道TKEStack是否支持部署呢？

何猛: 目前公有云容器服务下已经提供边缘集群功能，针对弱网、低资源等问题引入了新的解决方案，以后会选择合适的时机在独立部署版落地。 

Q：TKEStack相较同行竞品其优势在哪里，除了车联网的探索之外，TKEStack还可以用在哪些领域？

何猛:  TKEStack是一个通用的容器云平台，在使用上并不局限于某一个行业或者是某一个领域，可以应用于这种车联网，也可以应用于大数据 AI ，除基础的容器云平台功能外，TKEStack在产品形态方面，为用户提供业务权限管理、对接已有的第三方权限系统能力，在k8s集群扩展方面，提供GPU虚拟化、TAPP原地升级等功能，特别是GPU虚拟化，cuda 劫持方案是一个原理上简单，实现上很优雅的方案。 

Q：容器相关的GPU和存储方面产品在TKEStack里面有具体实现吗？

何猛: 平台部署后可以在扩展插件里安装GPUManager插件，部署后按GPUManager的说明创建GPU负载即可体验。TKEStack和GPUManager目前都已在github上开源，有好的想法欢迎提Issue和PR。

Q：在边缘计算中，关注很多是负载均衡和访问延迟方面的研究，请问目前腾讯平台是如何设计的？

何猛：目前边缘计算的方案已经在公有云上线，有这方面需求的可以体验一番，目前还没有开源，等方案更加成熟之后会在独立部署场景落地。