1.0 什么是service mesh
微服务框架，比如HSF/Dubbo或Spring Cloud，都提供了强大的服务治理能力，比如服务发现、负载均衡、熔断降级等。这些服务治理能力以Fat SDK的方式与应用程序构建在一起，随着应用一起发布和维护。
- 服务治理能力与业务逻辑的生命周期耦合在一起的。微服务框架的升级会导致整个应用的重新构建和部署。
- 此外由于Fat SDK通常与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。
为了解决上述挑战，社区提出了Service Mesh（服务网格）架构。它将服务治理能力下沉到基础设施，通过一个独立的Sidecar进程来提供服务治理能力。而应用侧只保留协议的编解码即可。
- 从而实现了服务治理与业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构的灵活性；
- 同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性。
2.0 Istio
2.1 介绍
Istio，第一个字母是(ai)。
Istio实现的服务网格分为数据平面和控制平面。核心能力包括4大块：
- 流量控制（Traffic Management）
- 安全（Security）
- 动态规则（Policy）
- 可观测能力（Observability）
Envoy面向数据平面，也就是服务之间调用的代理。是 Istio Service Mesh 中默认的 Sidecar 方案。Envoy 是一个由C++实现的高性能代理，与其等价的，还有Nginx、Traefik.**
Istio在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面。
2.2 原理
Istio在控制平面上主要解决流量管理、安全、可观测性三个方面的问题，也就是前面提到的东西流量相关的问题。类似一个有配置中心的微服务集群架构。具体细节不在这里赘述。
在Istio中，Sidecar模式启动时会首先执行一个init 容器 istio-init ，容器只做一件事情，通过 iptables 命令配置Pod的网络路由规则，让 Envoy 代理可以拦截所有的进出 Pod 的流量。
之后，微服务应用通过Pod中共享的网络命名空间内的loopback(localhost)与Sidecar通讯。而外部流量也会通过Sidecar处理后，传入到微服务。
因为它们共享一个Pod，对其他Pod和节点代理都是不可见的，可以理解为两个容器共享存储、网络等资源，可以广义的将这个注入了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。
下图是具体iptabless与Sidecar之间互作用原理（来源：https://jimmysong.io/posts/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/）
2.3 实践
3.0 service mesh和api gateway之间的关系
Api网关负责服务向外部暴露（南北向），service mesh负责内部的服务治理（东西向）
