嗯，，sidecar就是上面这种。。

mesh ： 微服务传统形态 和 sidecar形态

特征：

传统形态下，SDK代表着一个特定语言的库、工具包等，由应用程序和微服务框架（比如说dubbo）共处一个进程中，在发布升级*享生命周期。

serviceMesh下，推荐的是右边的sidecar方案，sidecar方案下没有引入新的功能，调用的拓扑也没有改变，只是改变了原有功能的位置，以独立的应用来存在。大家可以暂时以nginx来理解其网络代理能力也可以。

• 在ServiceMesh架构中，给每一个微服务实例部署一个SidecarProxy。该SidecarProxy负责接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该Proxy中。
• Sidecar以一个独立的进程启动，可以每台宿主机共用同一个Sidecar进程，也可以每个应用独占一个Sidecar进程。所有的服务治理功
  能，都由Sidecar接管，应用的对外访问仅需要访问Sidecar即可。当该Sidecar在微服务中大量部署时，这些Sidecar节点自然就形成了一个服务网格。

微服务框架的痛点和改进

• 对于基础架构框架开发者来说存在痛点：面向开发者的模式：新加了功能需要使用框架的应用开发人员配合升级版本，比如要升级maven中的依赖版本号，重新打包发布应用程序，时间上受制于相应的业务应用。业务开发人员相对来说只考虑自身业务稳定等因素，对基础框架的升级具有天然的抗拒心理。

• 使用SideCar模式带来的改进：这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。带来了下面的两个优点：
  1、面向运维：解耦了调用业务方和微服务，让它们的具备不同的发布升级的生命周期
  2、SideCar作为一个代理，可以完成更多的功能，比如跨语言、限流、负载均衡、灰度、熔断等都可以放到SideCar代理里

缺点：
1、从调用方到服务方增加了两次调用，有性能上的损失。（实际上的设计针对这个做优化，物理机上所有应用跟SideCar之间虽然是跨进程，处于不同的JVM应用中，但是它们处于同一台物理机中，故它们之间的调用可以走内核态方式，整体性能的损失可以在1%以内，平均延迟1.5毫秒左右），理论上多一跳的平均性能损耗在1.5毫秒左右；
2、调用复杂度增加，问题排查难度加大

总结：
对于大规模部署微服务，内部服务异构程度高的场景，使用ServiceMesh方案是一个不错的选择。ServiceMesh实现了业务逻辑和控制的解耦，但是也带来了额外的开销，由于网络中多了一次调用，增加了性能的损耗和访问的延迟。同时，由于每个服务（一般每一台物理机）
都需要部署Sidecar,这也会使本来就具有一定复杂度的分布式系统变得更加复杂。尤其是在实施初期，对ServiceMesh的管理和运维会是一个比较棘手的问题。