微服务架构可能存在一条较长的调用链，而错误发生时，通常很难定位错误发生的根源。
实现 Service Mesh 的典型方案就是 istio
- 服务：任何 Docker 容器都可以是服务，比如一个 Apache HTTP 服务器。
- 代理：Envoy Proxy，全权管理服务的流量进出，且代理本身也是一个容器。如果服务与服务之间需要通信，代理还可以进行通信协议的转换，如 HTTP、gRPC 等。由于代理和服务是伴生的，所以也称为 Sidecar。
- 代理管理总台：Envoy Web，可以动态配置这一大堆代理，设置过滤规则、负载均衡等等。把他们按功能分为 Pilot、Mixer 和 Citadel 三大块。
从 Envoy 的官方文档上，写着 Envoy 的目标：
网络对应用程序应该是透明的。当确实发生网络和应用程序问题时，应该容易确定问题的根源。
此外，借助 Envoy 我们还可以分析各个通信步骤的耗时，从而有针对性地优化服务。
那么，代理是如何劫持服务流量的？首先，Docker 有一个 --link 选项，将两个容器打通，也就是可以相互通信。然后，istio 通过自动创建 iptables 的 nat 规则，将服务的流量做了双向端口代理，从而实现最终的效果。