目前社区关于ServiceMesh的主要方向

周六的时候，在线参加了“首届服务网格峰会”，听了很多业界的研究分享，便整理了这篇文章，一来,为了反思自己在服务网格这边的落地方向是不是偏离社区，二来，希望对读者有用，能够有所收获。

本次峰会，参与者众多，阿里，腾讯，蚂蚁，网易等等大厂都有参加，并都做了相应的内容分享，算是收获颇丰

峰会内容，主要围绕下面几点展开，参考下图:

​

1.数据面的替换

对于ServiceMesh而言，最火的是istio，而它的数据面是envoy，所以目前市面上使用最广的数据面便是envoy。

envoy是一个使用c++14开发的产品，它的入门门槛比较高，直接改动或者进行二次开发难度很大，这让很多开发者望而却步。

除此之外，很多公司更希望建立自己的生态系统，所以市面上就有很多数据面产品产生，主要分为下面两类。

网关类作代理的玩法，例如apisix，他们推出了apiseven来专门搞这件事情。

直接自研产品进行替代的玩法，以mson为代表，整个使用go进行开发的数据面，已经纳入cncf社区，不过还没有从里面毕业。

2.插件模式的研究

目前社区的wasm方式不够成熟，支持内容偏少，加上大家对服务网格的需求很多，社区的研发进度满足不了很多人的需求，大家就希望一个成熟的插件模式能够出来。

当前阶段，插件模式的玩法主要有下面几种:

1）基于native c++自研，这一类对研发人员要求过高，不过结合是最好的。

2）脚本方式实现，以lua,nodejs为代表的。

3）cgo方式实现filter插件，以蚂蚁为代表。

4）基于envoyfilter进行协议对接，通过外围产品来辅助完成。

3.性能问题的演进

对于服务网格来说，低延迟的快速转发一直是个强需求，而大家又想在这个基础上尽量少的使用cpu等资源。目前istio这一类网格产品表现则是差强人意，所以这方面的研究一直从未间断，当前市面上的玩法集中在下面两点:

1）iptables的替换策略，主要以ebpf

为代表，当然也有ipc通讯的方式，这种其实破坏了sdk和数据面之间的耦合性。

2）架构的调整，把数据面下沉到宿主机这个层面，有点类似把数据面往网卡这种设备去抽象的意思，这也是社区的最新研发方向。

对于这种玩法来说，笔者觉得是需要对当前数据面做切割的，要把通用的能力提取出来，来玩，其他功能往上浮才行。

4.xds按需下发

当前社区xds的下发方式采用的都是全量下发的模式，这种模式通常会带来下面几个问题:

问题一:

每个运行态的sidecar上面的xds数据超大，而这些数据对当前pod来说绝大部分都是脏数据，这一来会影响envoy处理流量的耗时，二来也会消耗envoy很大的内存。

问题二:

这种超大的xds配置对于istiod更新xds有很大的冲击，特别是pod数量成千上万的时候，这种数据更新就会变得很不及时，而这种不及时会导致这段时间内的流量有可能会出错。

问题三:

很难排障，一个大几十万的配置文件，是很难发现问题的，只有研发一些工具才能解决，这又是一笔额外开销。

目前市面上的解决办法主要是两种，一种是社区增量xds的演进，据说2022年是重点，我们可以期待下。另外一种，是自己实现一些配套产品对xds进行裁剪，像蚂蚁才用了单独一个进程的方式与envoy进行通讯来解决这个问题。

5.安全和零信任网络

目前这是一个大趋势，社区和市面上已经有很多人在搞了，这个对于服务网格来说是一个天然优势，只要接入了服务网格，整个零信任网络就可以在业务无感知的情况下玩起来。

这部分笔者涉猎比较少，就不做扩展了，等后面有需求搞这部分，在专门整理分享。

6.虚拟机调度和跨集群访问

对于企业来说，规模越大，虚拟机使用的越多，如果他们想推服务网格的话，虚拟机纳入管控中是必须要做的事情，像百度，阿里，腾讯这些大厂在玩服务网格的时候，都做了虚拟机这部分的单独开发。

除了虚拟机之外跨集群业务调度也是不得不解决的问题，因为规模的原因，很多业务线是物理隔离的，集群也是分离的，这样就需要有办法把他们统一管控起来。在网格中，这部分是通过serviceentry和ingress/egress配合来搞的，不过更细的细节，笔者在这里没有具体参与过，也就不分享了。

以上是笔者的一家之言，大家要是有不同的观点，欢迎私信我，共同探讨。

灰子做于2022-9-28日，公众号:灰子学技术