AWS-用于在 AWS 上进行构建的工具

性能开销

我们反复谈到，Service Mesh的核心在于将原有以类库方式提供的功能拆分到独立的sidecar进程中，以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处，但是这对性能会有什么影响？

序列化性能

网络传输开销

如图所示，Service Mesh下，多了两次远程调用：

1. client发送请求给和client一起部署的Mesh
2. 服务器端部署Mesh将收到的请求转发给Server

但是需要指出的是，这两次远程调用都发在在本地，也就是”localhost/127.0.0.1”，走loopback/环回地址。而loopback可以绕开TCP/IP协议栈的下层，也就是会跳过链路层，物理层之类，不会真的经过网卡走网络，而是直接在IP层就处理了。如果优化得当还可以用Unix Socket之类的进一步提升性能，因此这两个我标记为”local”的调用，实际可以理解为是在内存里面兜了一圈，而不是真的走网络。

而两个标记为”remote”的调用，从网络条件来说可以认为是完全一致的，都是从client所在机器到server所在机器，中间的线路/速率/延迟/转发等都相同。

这样一来，在网络传输开销方面，Service Mesh增加的开销只在于两次loopback的网络调用。这个开销和client/server之间真实的网络线路相比可以认为是非常小的，无论是网络流量还是网络延迟。

推断：网络传输开销的增加基本上不大。

内存开销

这里有两方面的内存开销增加：

1. Sidecar进程额外占用的内存

和原有client/server进程相比，现在多了Sidecar的进程，必然会多出一些内存占用。

首当其冲的就是以Java为典型代表的基于JVM的语言，由他们编写的sidecar天然就要额外占用很多内存。其次，通过GC机制来自动回收内存，内存占用也会多一些。因此，基于Scala语言的Linkerd在这方面就吃亏比较大，和基于C++的Envoy相比差距明显。所以后来Bueyant重新开发Conduit时干脆选择用Rust。

2. 请求转发过程中占用的内存

请求在一路转发的过程中，sidecar肯定要占用内存的：毕竟一边接收请求，一边转发，期间要解析协议格式把Header读取出来。

此时，sidecar代码实现中”zero copy”是最基本的要求，必须做到。

遇到需要改动请求的情况就麻烦了，比如需要添加一个header(如http_x_forwarded_host)，需要去除某个header(抹掉某些敏感信息)，或者改写某个header的值(如Host)。在无法只读的情况下简单的”zero copy”肯定不可行，但是如果实现的足够好，起码Payload部分还是可以继续实现”zero copy”的。

TBD: 需要去读一下Envoy和Conduit的代码，看看他们具体如何实现。

在这一点上，HTTP/2（还有基于HTTP/2的gRPC）有天然优势：HTTP/2协议是基于帧的，Header帧和Data帧是分别发送的，因此对Header帧的修改完全不会影响到Data帧的处理，在编码实现上要比Header/Body一起传输的HTTP1.1简单的多。

有一点应该比较明朗：Service Mesh不适合大文件传输。毕竟中间多了两次sidecar转发，对内存开销和后面提到的CPU开销都会有负面影响。

sidecar的部署模型

额外的话题：sidecar的部署模型，是否一定要和服务实例一对一？

这是目前Istio/Conduit的标准部署模型，部署服务实例都会插入一个sidecar。考虑引入Docker之后，同一台物理机器上，容器的部署数量会大为增加，反映在服务实例上就是会有大量的服务实例部署在同一个物理机器上。此时是否应该考虑共享sidecar以减少sidecar的部署数量？这样可以大幅度的节约内存。

cpu开销

继续看回这个图片，多了两次sidecar的转发：

必然会有CPU开销的增加：

1. 两次sidecar转发请求，无论是接收请求还是发送请求，都涉及到网络IO
2. 接收请求之后，必须解析协议，读取header

但是和前面序列化的分析类似，只有当请求足够简单并且服务器端处理请求的负载足够低导致QPS非常高时，才会对性能有明显影响。对于大多数情况，影响应该不大。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com