一、服务网格在什么背景下诞生？

随着系统架构从单体架构向微服务架构发展，现在微服务架构以成为主流的架构方式，则得益于微服务架构的诸多优势，例如：
（1）单一职责、独立部署：每个服务只负责某一块业务，由独立小组负责开发和维护，服务之间松耦合，且独立部署，因此可以快速响应变更。
（2）不限技术栈：服务之间通常采用HTTP/RPC协议进行通信，不绑定特定技术栈，因此每个服务实现技术不限定。
（3）精粒度控制业务：系统的熔断、降级、限流等可以具体到某个服务，业务的控制更加细粒度。

但是实际上在微服务在落地时，也存在较多的问题，例如：
（1）技术门槛高：通常我们在实现业务功能之时，一些非业务功能也我们自己处理，比如服务发现、负载均衡、熔断、降级、灰度发布、故障切换、分布式跟踪等。
（2）代码侵入性强：SpringCloud、Dubbo等主流微服务框架都对业务代码有一定的侵入性，技术框架替换成本较高，比如Dubbo升级到SpringCloud，需要花费较多的成本。
（3）多语言支持不足：目前开源社区上没一套统一的、跨语言的微服务技术栈，主流的技术栈SpringCloud和Dubbo都是基于Java。

为了解决微服务存在的诸多问题，服务网格诞生了。

二、什么是服务网格？

服务网格（Service Mesh）被称为下一代微服务，服务网格是一组用来处理服务间通讯的网络代理，实现业务逻辑和非业务逻辑的分离。

服务网格采用Sidecar模式（如下图所示的边斗车），非业务功能下沉到sidecar，用于只需要关注业务功能，而不用关注服务治理等非业务功能，每个微服务实例都部署一个SideCar Proxy，该Proxy用来接管服务的出入流量，并将服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能抽离到该Proxy中。

打赏