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