微服务的网络架构
微服务架构中，每个功能模块仅负责一小块职责，微服务之间通过 HTTP/TCP 交互。
微服务之间的网络交互，须要限流、熔断、服务发现等等服务治理的性能，每个微服务外部都要集成相干的 lib 代码。
业务代码开发过程中，个别应用框架来实现上述的性能，比方 spring cloud，提供了 hystrix、Eureka 等熔断、服务发现等性能。
service mesh: v1
kubernetes 时代来了，咱们把微服务部署在一个个的 Pod 中。
服务之间的网络交互，通过各自 pod 内的 sidecar container 来实现，sidecar 内集成了服务熔断、服务发现的性能。
这样业务代码的开发，不用再关注服务熔断、服务发现等性能，专一于实现业务即可。
服务之间的交互，交由 sidecar 之间进行，最终所有的服务组成如下的一个“网格”：
service mesh: v2
sevice mesh 的 v1 是通过 sidecar 代理实现服务之间的交互，service mesh v2 则引入了集中的管制面治理，lstio 是 service mesh v2 的典型代表。
control Plane 能够进行全局的流量管控、路由下发，从 control Plane 的角度看，网络的流量变成如下的样子：
参考
1.https://zhuanlan.zhihu.com/p/…
2.https://philcalcado.com/2017/…