作者回复: 功能类似，但位置不同，导致处理的问题不同。sidecar在网格内部，网关在网格边界。前者负责东西流量，后者负责南北流量。

作者回复: 思路相似，sidecar就是个代理，只不过更加专一； 部署形式也不同，sidecar是1比1部署在服务上。nginx这种代理你没见过每个服务都部署一份的吧？

作者回复: 你可以理解为sidecar是Pod里的一个容器，为Pod中另一个主容器（也就是你的应用所在的容器）服务。sidecar好比你应用容器的助手，负责非业务相关的逻辑，比如日志处理，流量控制。

作者回复: 官方的测试结果是每个sidecar仅有2ms的延迟，即便你的调用链很长，加起来也多不了多少。题外话，如果你的一个业务流程上有太多的服务，说明服务划分的有问题。 我们公司是比较典型的中小型应用，服务不超过100个。性能问题通常是应用本身的问题居多，不必担心mesh，envoy已经被验证了性能优秀

作者回复: sidecar的概念出来也很久了，我们这里特指限定在容器形态的sidecar，只要它接管同一个pod中应用的某种流量（不限于网络、也可以是db流量、io），那它就是一种代理。所以你可以认为sidecar就是一种代理。 你说的sidecar组成的网络就是第一代Service mesh。

作者回复: 对spring cloud没有深入研究，不敢妄加评论。以我现在粗浅的认识来说，我认为它算是一种公共库的解决方案，至少需要一些config或者annotation植入到应用代码中，对吧？如果我说的不对请专家指正。 所谓殊途同归，他们要解决的问题基本上是一致的，只不过思路不同而已，选择哪种解决方案还是要看自身的情况。我个人认为service mesh的思想是更符合云原生的理念的。

作者回复: sidecar是一个广义的概念，我们可以认为所有能帮服务分担非业务功能的代理，都是sidecar。比如filebeat，帮服务收集日志，也是一种sidecar。 service mesh是利用了sidecar的思路，本质上就是sidecar的网络拓扑组合，只不过它的sidecar只负责流量控制相关的功能而已。 只要你的应用中有这样的sidecar，哪怕只有一部分有，加上控制平面，就算是mesh。

作者回复: 公共库通常都需要整合、集成，这个过程算一种侵入。比如一些配置文件、代码中的annotation等。 另外，部分公共库虽然功能等方面独立，但是最终和应用程序一起被编译到同一个可执行文件去部署、运行。这算第二种侵入。