微服务的网络架构
微服务架构中，每个功能模块仅负责一小块职责，微服务之间通过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/...