一句话，版本问题。还有一个跨语言问题。
引：
在 Service Mesh 之前，微服务体系的玩法都是由中间件团队提供一个 SDK 给业务应用使用，在 SDK 中会集成各种服务治理的能力，如：服务发现、负载均衡、熔断限流、服务路由等。
在运行时，SDK 和业务应用的代码其实是混合在一个进程中运行的，耦合度非常高，这就带来了一系列的问题：
-
升级成本高；
-
每次升级都需要业务应用修改 SDK 版本号，重新发布；
-
在业务飞速往前跑的时候，是不太愿意停下来做这些和自身业务目标不太相关的事情的；
-
-
版本碎片化严重；
-
由于升级成本高，但中间件还是会向前发展，久而久之，就会导致线上 SDK 版本各不统一、能力参差不齐，造成很难统一治理；
-
-
中间件演进困难；
-
由于版本碎片化严重，导致中间件向前演进过程中就需要在代码中兼容各种各样的老版本逻辑，戴着『枷锁』前行，无法实现快速迭代；
-
有了 Service Mesh 之后，我们就可以把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施，可以让业务更加专注于业务逻辑，中间件团队则更加专注于各种通用能力，真正实现独立演进，透明升级，提升整体效率。
