以上涉及到的网格技术短板都属于数据面需要解决的问题。首先了解目前主流的服务网格数据面方案。
服务网格数据面技术现状
Envoy
C++开发，是目前功能最全面的数据面方案，通过标准xDS协议可以对接多种控制面，如主流的Istio控制面可以天然的集成到k8s集群内。其原理为设置每Pod的iptables规则对应用出入流量进行劫持，数据处理上采用过滤器方式扩展处理能力，用户可以自定义开发监听层、网络层、http层过滤器并注册到数据面网格代理中。开源社区最为活跃，并且有如Google、Lyft等厂商深度参与开发，因而发展最为迅速。
Linkerd
第一个采用服务网格方式进行服务治理的产品，Rust开发，具有轻量性能较高的特点，配置方便直接，开箱即用。具备基本的服务治理能力，但较Envoy缺少断路器、故障注入等高级服务治理能力。还有如Conduit、提供了一个更轻量级、但功能上比较简单。
Cilium
Cilium属于一种新型的数据面代理部署方式，主要基于Linux内核的EBPF技术，其主要思想是将数据面代理逻辑放入系统内核层，这样在拦截处理网络请求的同时在内核实现数据解析及流量治理，相较于其他数据面代理在应用层实现流量治理的方式，可以减少出入内核的次数，并可以在内核层面对数据代理使用的计算资源进行高优先级的保证。
总结
Cilium目前在多个产品中是性能表现最好的技术，但同时受限于操作系统内核版本及EBPF本身支持所支持的代码量限制，因此无法实现如Envoy等全面的数据面代理服务治理能力，另外，从以上数据面产品本身部署形式来看，Envoy和Linkerd是是基于用户态做的七层治理，而Cilium将治理逻辑下沉到内核中进行加速，但无论哪种都会占用较多系统主机的资源。
从应用的广泛程度看，针对应用的透明服务治理已经成为未来的发展趋势，国内外云厂商相继推出了服务网格产品，云厂商如AWS提供AWS App Mesh，Google提供Anthos Service Mesh、 Traffic Director、华为云ASM，其数据面都采用了Envoy，不仅因为其完善的七层治理能力，还有经过大量应用验证的稳定性作为支持。
服务网格数据面技术问题与挑战
虽然应用网格发展迅速，但在实际应用中，也遇到了一些产品上共性的问题：
性能影响和资源占用
从上面数据网格代理的原理可以看出，将服务治理从进程中分离出来变成独立的代理进程，增加了两跳网络通信成本。即使从本机内应用到数据面网格代理的网络通信流量也要经过网络协议栈的完整处理，势必会对整体时延有所增加。
网格内在每次服务调用完成后收集调用信息，通过服务端组件再转发给监控中心， 整个监控数据上报对数据面转发性能带来了影响。在Envoy 1.6之后，社区推荐将上报方式变成监控中心对网格数据面代理的拉取方式，同时对网格数据面内调用信息的缓存能力提出了新的要求。
由于数据面代理和客户应用部署在相同主机空间内，一旦主机CPU使用率较高时，分配给数据面代理的时间片将会减少，这样导致路由选择和转发率下降，更多应用发出的请求被堆积，导致整体时延显著增加。并且由于主流的数据面代理为Pod内部署形式，无法进行绑核操作，因此基于现有架构无法解决这个问题。
由于每Pod内都需要部署一个数据面网格代理进程，实测每个代理进程将占用70MB以上的内存空间，因此分配给应用的实际内存将达不到需求或者导致主机内存资源的利用率较低。
第三方协议的治理能力
目前服务网格支持几种主流协议，http(s)，grpc, dubbo,mysql,redis,zookeeper,kafka,mongo,tcp等，其中对于http及grpc的支持比较完善，其他协议只是部分支持，如dubbo自身的hession协议只支持到方法级，无法支持接口级负载均衡。
这块社区建议采用WASM技术（一种基于进程内虚拟机）将自定义的协议动态插入到Envoy过滤器链中，WASM实现了沙箱功能，保证了Envoy代理本身的稳定性并且支持字节码的热升级。但目前WASM技术性能上还无法与C++原生代码执行效率看齐，因此如何提升WASM性能是目前一个活跃的技术发展方向。
问题分析及定位能力不足
之前谈到数据面代理采用过滤器方式处理应用数据，但各个处理模块本身并不打通，这样就无法将数据网格代理中各个处理阶段的信息进行更细粒度的分析，现有的处理方式是收集各个处理阶段的日志并根据请求的起止时间进行人为匹配，往往耗时费力，而且线上系统由于业务处理要求不允许输出大量调试信息，因此对一些偶现问题很难追溯原因。
产业应用情况分析
从目前产业应用范围看，虽然各个主流云厂商都提供了自己的网格服务，并且越来越多的用户也在一起探索网格技术对已有系统的迁移和可替换性，但大规模应用服务网格的用户数量与传统基于SDK方式的服务治理用户相比较还不多，更多是一些新兴互联网公司可以在开始的技术选型上偏重服务网格的开发方式。
究其原因，一方面是新兴互联网公司规模相较于一些大型互联网公司体量都不是很大，用户数量不会由于服务网格本身的性能问题成为瓶颈。但更重要的是这些大型公司缺乏从已有系统中迁移到服务网格的动力，因为往往这些公司在一开始就已经确定了技术方向，如dubbo等SDK方式，之后新开发的应用也是基于相同的框架，所以不存在需要异构服务治理能力的场景，再加上迁移到服务网格技术后性能随之会产生一定的下降，更加造成了对这种新技术的观望态度。
然而由于网格技术的快速发展，加上这种开源技术对各种开发框架支持的透明性，用户也希望自己的基本架构不要绑定到某种特定的开发框架下。因此提升网格数据面性能和降低资源占用量成为推广服务网格技术所亟待解决的问题。
ASM对于服务网格数据面的优化方向
华为云应用服务网格（ASM）产品作为商用的Envoy方案，在标准化基础之上，在如下几个方向正在进行相关增强工作，以提供更满足客户场景诉求的商业化网格产品：
网络优化
为了进一步降低主机内通信的网络延迟，目前正在进行的一项优化是将主机内部通信如客户应用到网格数据面代理通过EBPF技术进行加速，替换目前Iptables拦截方式，使请求数据在进入操作系统网络协议栈前判断目标端地址，如果为本机则直接将其放入接收进程的TCP缓冲区中，减少经过完整操作系统协议栈的性能消耗。
监测与故障处理
为了解决线上系统对调试日志记录的限制，并快速定位以及预先发现数据面或网络可能出现的抖动等问题，目前正在对数据面网格代理的多个处理环节进行打通，解决每个数据处理环节只记录本环节内的处理结果而无法将有效诊断数据整合输出的问题。
这样对线上经常需要帮助定位的问题，如是否由于网络抖动导致分包引入的长时延、每个请求从进入数据代理到发送到上游的时延是否过长、每个请求的路由选择策略中主要因素及选择结果判断等信息可以集中进行输出，这样线上系统就可以在日常运行中安全的记录这种少量但精简的日志信息。不仅便于对于已经发生过的问题进行分析定位，同时可以预判可能发生的其他引起数据面处理异常的原因，提前做出预警。
共享化
为了解决现有数据面代理每Pod部署引起的主机资源内存消耗量大的问题，同时可以对数据代理进行CPU资源的绑核操作。
目前正在实现将数据面代理独立到主机节点部署，作为主机内所有应用Pod的共享代理。这样通过EBPF方式增加出流量拦截层，根据已有服务注册信息自动识别需要进入此共享数据面代理进程的流量，而其他非代理调用的请求直接通过网卡进行发送。兼容目前每Pod部署数据面代理的各种通信模型。
硬件卸载
在前面网格数据面共享化模式实现同时，正在计划将共享化的数据面代理下沉到内部的擎天智能网卡上，实现请求的七层治理能力，以实现对于主机系统资源零占用。
主机与加速卡内通过RDMA等技术进行数据双向通信，并通过主机侧出流量拦截层的EBPF模块结合硬件卡内的自研用户态协议栈对传输层数据进行封装，这样对于数据面代理本身可以做到网络处理代码部分最大的兼容性，对于后期与社区代码新功能整合减少合并成本。
再者由于擎天硬件卡本身属于用户不可见部分，则进一步保证了数据面进程与主机系统的隔离，提升了系统内网络通信及运维操作的安全性。而且对一些如压缩、加密等对于CPU及相关算法依赖度高的处理步骤结合硬件加速卡本身提供的特定硬件进行加速。
另外网格数据面代理进入加速卡后，对于外发网络请求可以将现有租户隔离等功能与用户态协议栈进行进一步融合，减少网络处理消耗。
总结
从服务网格数据面发展的未来看，下一代网格会作为一项基础能力结合网络并感知应用。如根据应用调用量值能调整网络带宽分配，结合智能调度器控制已有或新应用实例的创建分配的位置等能力，将作为云原生基础系统的一部分进行部署。
未来服务网格数据面会更加深入地融合到整个云原生基础设施层，与基础网络、负载均衡、网关、软硬件加速等技术交叉融合，为客户业务提供高性能、高吞吐、高灵活的服务治理与流量管控能力。
