讲的太棒了，绝对是大师级人物。快结束了，意犹未尽，重新看一遍。

题目：在讲述 Service Mesh 的时候，我们说了，希望 Envoy 能够在服务不感知的情况下，将服务之间的调用全部代理了，你知道怎么做到这一点吗？
答：在Service Mesh模式中，每个服务都配备了一个代理sidecar（Envoy代理），用于服务之间的通信。这些代理通常与应用程序一起部署，代理不会被应用程序感知。这些代理组织起来形成服务网格。
Envoy是Service Mesh中一个非常优秀的sidecar的来源实现。

Envoy就是lstio的核心支持，越来越觉得kubernetes真的是集大成者，服务治理，面向未来的声明式API架构，资源调度与编排，网络的多种优秀方案。怪不得可以在极端的时间里力压docker

对思考题的解答
容器系统中，是通过 sidecar 模式来解决的，服务容器都是直接和 envoy sidecar 互通，envoy 的配置变化，网络拓扑的改变对服务容器都是不可感知的。service mesh 还更进一步的发展，istio 和 conduit，他们都是在 sidecar 基础上，又加了一个总的数据控制平面，来加强 service mesh 的掌控能力。

我觉得是极客目前最好的专栏

想问一下老师，GRPC是否支持client通过代理服务器访问到server端？官网上找了半天没有找到相关答案，我这边现在的场景需要经典网络的管控节点访问到vpc中的服务节点，由于vpc中服务节点太多，不可能打太多的洞，所以想在vpc中部署nginx服务作为代理服务器，转发经典网络发来的所有请求到server端

已经完结这么久了，我才终于看到了这里。收获很多。感谢。

学java的应该可以跳过spring cloud了，感觉envoy + grpc + kubernetes是趋势

通过使用iptables程序配置内核中的netfilter，实现流量劫持转发，把指定入口流量都转发到envoy，出口流量也可以使用两样的方法实现

问题中描述的“希望 Envoy 能够在服务不感知的情况下，将服务之间的调用全部代理了”不禁让我想起了网络中的路由器发现相关算法，参照Jay的评论，我想为每个服务配置一个代理(路由器)，组成服务网格(AS)，将RPC的相关操作独立成一层，让应用如TCP调用IP层般进行夸服务、语言的调用，以达到对应用层的透明。

刘超老师，问个问题，如果一个服务在容器中，一个服务在物理机上，怎么进行rpc通信，此时容器是可以调用物理机的，但是物理机是无法调用容器中的服务了，例如dubbo，获取到的是容器中的ip，物理机调用的时候，通过容器中的ip是无法调用到容器中的，这个有什么解决办法么

对grpc有了基本的认识，包括协议定义，传输封装等。

服务的注册不感知是因为使用了容器平台的发现能力。服务自身不感知，是因为envoy 作为sidecar 的方式劫持了网络流量。

其实也不是完全无感知，服务还是需要知道service mesh的存在，只是一般是sidebar方式的部署，每个服务只需要知道自己的enovy在哪里就可以了，所有网络交互通过它来转发

赞，干货满满