百度在 Service Mesh 上的大规模落地实践

本次分享，我将和大家分享以下三部分内容：服务网格简介、百度在服务网格的最佳实践、对服务网格的未来规划与展望。

从传统单体应用到微服务架构转变去落地时，基于 SDK 和服务框架这种微服务治理体系，这种传统的服务治理能力完全是由 SDK 以及服务框架来实现的。这其中，包含了很多服务治理、服务发现、服务路由、服务重试、熔断限流等微服务相关的一些能力。业务程序重度依赖 SDK 及其服务框架，并和语言、业务绑定在一起。

基于这样一个服务框架的服务治理体系，在由传统的单体到微服务的转变之后，将面临着很多种挑战：

具体来说，在语言绑定层面，传统的微服务治理体系可能要跟具体的语言绑定，因为它跟具体的业务逻辑是要绑定在一起的。

从整体来看，在多语言层面很难做到一个统一的技术，因为语言本身有各自的特性，还有各个语言的能力，都有不太一样的情况。

此外，采用传统的 SDK，在向前去演进的时候，很难去推动业务去做升级，SDK 和业务严重绑定了，这样会造成演进困难。

基于这些问题，我们将非业务逻辑相关的微服务治理，放在另外一个透明代理，即一个轻量级的网格代理，我们称它为 sidecar。在 sidecar 层面，我们做了很多的服务发现、负载均衡、服务路由等等。

这样服务的概念更加纯粹，不同的服务和微服务进来，只需要关心自己的业务逻辑实现就可以了，完全把这种非业务的实现逻辑，放在 sidecar 层面去做。

这种典型场景具备四个特点：它本身和业务无关，真正做到了从业务中剥离出来；由于它和业务在两个独立的进程里，所以不存在语言绑定的情况；它和业务逻辑没有强烈的耦合，独立演进，包括独立的升级和维护；透明升级的，就是我们基于 sidecar 这样一个能力的升级是不再依托于业务的升级，因为本身没有绑定，这是我们基于透明代理的服务治理体系。

这种基于透明代理的服务治理体系，可以简单称它为服务网格。我们先看一下其典型代表 Istio，Istio 是一个在服务网格领域深受大家喜爱，也深受开发者追捧的框架架构。

我们来看一下它的典型架构。

Service A 和 Service B 是我们的两个业务应用，Envoy Proxy 就是一个透明代理，它本身对业务是透明的。我们可以看到，有一个控制平面 Istio control plane，控制平面可以简单理解为，它会向着我们所有的 sidecar 去推送整体的一些配置、数据等等。通过这样一个典型的 Istio 架构，来引出我们这个服务网格的概念。

从整体视角上来看，所有的 sidecar 都是在一个网状结构里进行透明的流量转发和治理，组成了一个扁平的网状，这种由透明代理组成的一个网状结构，我们可以称它为服务网格，服务网格本身是基于透明代理去实现的。

接下来，我和大家分享下百度服务网格最佳实践，主要介绍服务网格在百度的整体实践，包括我们怎么去落地服务网格，以及带来的业务收益。

百度在云原生领域的发展历程还是比较早的，我们在 2012 年到 2013 年，内部就有很多这种容器平台，比如 Matrix。在 2013 到 2015 年，我们内部有很多业务线逐步地去落地和推广云原生理念。在 2013 年到 2017 年，我们有大量的品牌业务、广告业务、营销业务开始使用了微服务引擎，其中比较典型的是我们的 BFE，以及百度 RPC（brpc）。

2015 年到 2018 年，我们整体的业务线，包括文库、音乐、人工智能等等，也开始在开源的 Kubernetes 里去做一些实践，大概有几十万的容器使用了 Kubernetes 技术。在 2018 到 2019 年，我们整体做了很多的微服务化、应用平台、PaaS 平台，其中也包含了我们对 Springcloud 和 Service Mesh（服务网格）的探索。

2019 到 2022 年，我们在百度的地图和信息流里进行了服务网格的大规模落地，在服务网格这部分做了很多事情，产生了很大的价值收益，后面我们会逐个去介绍。

在业务线上，我们有很多核心业务线，比如百度 APP、信息流、地图，还有百度小程序。百度也有很多开发语言，比如 C++、Golang、PHP、Java 等等，形成了一个多语言的场景。在开发框架里，基于传统的微服务框架，我们也有很多内部实现的积累，比较有名的是 BRPC 框架，还有 Golang 的 GDP，PHP 的 ODP 都有一些实践，并且跟业界开源的 SpringCloud 也有一些落地实践。

在通讯协议方面，因为百度很多核心商业对性能有很高的要求，我们在大量的私有协议里有很多扩展，其中有大量的 L4 层协议。通过这样一个方式，百度的很多业务线已经完成了微服务的改造，它可能还是停留在传统的服务框架和 SDK 这样一个模式，形成了一个多开发语言、多框架和多通讯协议的复杂的异构系统。

基于传统的服务框架的模式，本身已经不能够再满足像百度这样体量的商业化系统的演进过程，同时也不再具备满足更高的服务治理的要求。基于这样一个背景，我们探索了服务网格的落地。

我们在落地服务网格时，有很多挑战和困难。

第一个比较典型的困难就是应用的类型比较多，因为日积月累，有大量商业化的服务框架应用涉及到服务网格的迁移。第二，像百度这种商业化体系，本身对时延等要求比较高。第三，我们对服务治理的需求比较多，在用户侧，当一个新的服务网格技术去落地时，用户也是比较希望这个全新的技术能够解决他在场景化的一些问题。最后就是技术理念的问题，因为服务网格是一个比较新的技术概念和理念，它涉及到的技术领域比较复杂，本身理念也比较新，开发者还是有一些接受的过程。

百度已经形成了很多微服务技术框架和架构，我们要去做一个新技术的推广，包括服务网格的落地，首先要去倾听业务的诉求。基于这些业务诉求，选择一些比较典型的核心业务，然后逐步向服务网格这样一个全新的微服务架构去转型。最后我们实现了比较大规模的业务落地，包括我们在大规模场景下一些稳定性相关的保障。

接下来，我们看一下百度服务网格大规模落地的步骤。

首先，我们需要解决流量接入的问题，流量怎么劫持到 sidecar，去做流量拦截和流量的治理。第二，解决对自有协议的兼容问题。百度有很多私有协议，要在 sidecar 层面去支撑我们所有的私有协议，最后要对老框架、老协议去做一些兼容。

解决完接入问题之后，再来看性能部分。因为我们是一个大规模的商业化场景，我们要重点解决刚才提到的 sidecar 的性能优化，还有控制面的性能优化，以及我们在整体代理架构的简化。

最后，业务接入服务网格之后，我们要来看一下这个服务网格最终有什么样的业务收益。我们在高级能力的策略还是比较丰富的，能够有效的保证业务的稳定性，同时在一些网格的特性，包括故障注入、容量探测、自动止损等方面也做了增强，同时对服务的可观测性也做了一些弥补和增强。

代理架构简化

接下来看下在代理架构简化这一层面，我们主要做了哪些事情。

先来看一下社区的方案。社区的方案是一个典型的双跳方案，每个业务程序都有一个边车，所有的流量都要经过两次边车处理，它有一个两倍的延时，包括两倍的资源开销。

我们对此做了一定的优化。我们提供了 client-side 这样一个模式，和社区的方案对比来看，业务之间在通讯的时候，业务本身不再依托于边车的流量管理，也就是说，我们相当于仅增加一倍的延迟，而不是社区的两倍延迟。同时在资源效能开销方面又降低了很多，这是因为我们发现大部分的服务治理的能力是可以在客户端来实现的。

控制面优化

在控制面优化上，我们整体是基于数据面加控制面的模式来做的。

第一步，利用框架的一些能力，采集服务的调用关系，把数据同步给我们的控制平面，控制平面会把服务所需的数据向边车去下发，达到一个按需下发的能力。同时，我们的边车也是主动地向对应的注册中心，查询获取到它的服务治理的能力。

在优化控制面的性能之后，我们也在服务网格的性能方面做了一些优化，包括控制面和数据面做了一些融合。我们引入了 BRPC 做了很多这种优化，因为在百度内部有很多 BRPC 的场景，同时我们也结合了 BRPC 和 Envoy 的一些优势，基于 Envoy 灵活的 filter 机制，做了丰富的策略，支持动态的 XDS 机制，同时也结合了 BRPC 的高性能的线程技术、Buffer 库、优秀的 IO 机制，最终达到的效果。

最终在 CPU 和平均延时这两个比较核心的指标层面，有很强的性能提升。

我们在探寻的时候发现，传统的业务逻辑加 SDK 的微服务架构，和应用加 sidecar 这样一个全新的 Service Mesh 架构，是有一个过渡态的。在这个过渡态里，我们需要异构应用的互访，也就是说，传统的微服务应用能够和我们这个 Service Mesh 的应用去做互通，Service Mesh 里面的应用程序，同样要去和这种传统的异构程序去互通，我们称它为过渡态。这是我们典型的一个应用场景，也是业务线比较关心的一个问题。

另外我们做了一个 Fallback 机制支持流量的一键回退。刚才提到，在典型的 Service Mesh 架构里，这种代理模式是比较好理解的，就是所有的请求都会经过 sidecar。这是一个典型的 Service Mesh 架构，我们可以称它为一个典型的代理模式。

另外一个方式，我们称它为直连模式，就是这个请求不再经过 sidecar 拦截，直接写入业务进程，和业务进程直接去通信，这个就是我们典型的这种业务之间通信方式。

业务在向这种典型的 Service Mesh 架构去迁移或者转变的时候，有个担心点是，传统的业务可能采用直连模式，换成这种代理模式之后，因为所有的流量都会经过 sidecar 拦截，一方面会增加时延，以及对稳定性的诉求；另外一方面，在极端的情况下，如果 sidecar 数据平面产生了一些故障，怎么快速帮业务止损。

我们基于定制化的一些能力，做了 Fallback 机制。Fallback 机制提供了一个产品化的能力，能够自由地在代理模式和直联模式间去灵活切换。这样，一个典型的应用场景就是在故障或者是业务止损方面，如果传统的 Service Mesh 架构发生了一些故障，我们能够快速地把流量切回到直联模式，这是我们在稳定性方面的一个保障，也是给业务信心的增强。

在针对一些传统的 Java 的微服务应用程序考量时，会发现一些传统的微服务应用已经有一些现有的微服务治理体系，那么，我们怎么去让它做这种服务网格的迁移？

我们采用了一种无侵入的实现方式，利用了 JavaAgent 这样一个技术，首先它能够做到对业务无侵入，因为它本身是基于字节码层面的一些修改。基于这些能力，我们实现了它在服务网格里面的服务治理的能力。

第一个比较典型的场景就是我们能够动态地开启和关闭传统微服务治理框架的治理能力，因为在传统的框架里面，它本身已经有了微服务的能力，在接入了服务网格之后，我们希望它和服务网格的基本能力能够做一个取舍，而不是一个相互叠加。

第二，可能熟悉服务网格的同学都对这点深有体会，虽然服务网格是由 sidecar 来代理流量的，但它本身需要在业务进行微服务监控的时候，能够主动地把 sidecar 产生的对应的 trace 信息做一些透穿。这部分，我们也是利用探针的能力，去实现了微服务调用关系的 trace 信息的透穿。

第三，我们也做了一些增强。我们发现，Istio 这样全量推送的架构里，可能会有一些性能的损失，我们会主动探测到应用程序里边需要访问的微服务调用关系，基于这个调用关系，我们把这些元数据做一些收集，再同步到我们的控制面，再到我们的 sidecar 层面去生效，这样保证我们在大规模场景下的性能优势。

接下来介绍下我们内部在提升 Service Mesh 性能方面的一些实践，典型实践就是 Service Mesh 的单跳方案。

Service Mesh 单跳方案主要是解决 sidecar 的非必要拦截。社区的双跳方案，业务请求先到某一个服务 A，服务 A 的 Sidecar 进行一个拦截，这个 sidecar 会把请求转发给服务 A ，同时服务 A 要向服务 B 发起请求，对外的请求也要过一次 sidecar。同样的，服务 B 的 sidecar 也要把这个请求再转发到服务 B，再出去的时候，再过 sidecar，我们看到这样的话，每次请求进出服务 A 和服务 B 都会产生这个 sidecar 的拦截。

我们发现，大多数服务治理的策略往往可以在服务 A，也就是 client 端来实现。基于此，我们做了一个单跳的方案。我们在入向和出向的时候，只有在第一次请求拿到服务 A，往出走的时候，我们再过服务 A 的 sidecar，同时在访问服务 B 的时候，我们这个请求是不需要再过服务 B 的 sidecar。基于这样的一个方案，我们节省了一部分 sidecar 的资源开销，还有时延的开销。

接下来，我们再来看一下一些内部的典型大规模应用场景。