服务网格可看作基础设施层，用于处理服务间的通信。现代云原生应用有着复杂的服务拓扑， 服务网格负责在这些拓扑中实现请求的可靠传递。实践中，服务网格通常是一组轻量级网络代理， 与应用程序部署在一起，可以将其比作应用程序或微服务间的 TCP/IP，负责服务之间的网络 调用、限流、熔断和监控。
在服务网格技术应用之前，微服务体系的实现方式往往由中间件团队为业务应用提供一个 SDK，在 SDK 中会集成各种服务治理能力，如服务发现、负载均衡、熔断限流、服务路由等。在 运行时， SDK 和业务应用的代码混合在一个进程中运行， 耦合度非常高， 这就带来了一系列问题：
一是升级成本高。 每次升级 SDK 都需要业务应用修改 SDK 版本号，再重新发布应用。在 业务快速发展的时候，这类升级会影响到研发效率。
二是版本碎片化严重。 由于 SDK 升级成本高，且中间件不断向前发展，久而久之，就会 导致 SDK 版本各不统一、能力参差不齐等问题，给统一治理带来巨大的工作量。
三是中间件演进困难。 由于 SDK 版本碎片化严重，导致中间件向前演进时需要在代码中 兼容各种各样的老版本逻辑，如同戴着枷锁前行，无法实现快速迭代。
金融机构的服务网格把原来通过 SDK 集成的一些网络通信能力下沉到 Sidecar 中，包括 基本的 RPC、消息、DB 访问能力，以及在此基础上的服务发现、熔断、限流、流量管控、数 据库分库分表的能力，以此给业务系统带来较为透明的通信基础设施，将基础设施的迭代演进 与业务系统解耦，让业务研发专注于业务逻辑，减轻业务系统的负担，提升业务系统及基础设 施的迭代效率。
