服务网格在百度核心业务大规模落地实践

【百度云原生导读】服务网格（Service Mesh）的概念自2017年初提出之后，受到了业界的广泛关注，作为微服务的下一代发展架构在社区迅速发酵，并且孵化出了诸如Istio等广受业界关注的面向于云原生(Cloud Native)的微服务架构。

那么，服务网格在百度的落地情况又如何呢？

近日，在百度技术沙龙上，百度服务网格技术负责人乔元才发表了『服务网格在百度核心业务大规模落地实践』的主题演讲。

1. 从微服务到服务网格

何谓微服务？据维基百科的定义：微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信。

Service Mesh 最早在2016年9月29日由开发 Linkerd 的 Buoyant 公司首次提出，Service Mesh 是用于处理服务间通信的基础设施层，它负责通过构成现代云原生应用程序的复杂拓扑结构来可靠地传递请求。

因此 Service Mesh 也被称为微服务时代的TCP协议。

第一代微服务的常见架构如下图所示：

在黄色的容器内有服务A、服务B。A和B都包含自己的业务逻辑，如果想要A调用B，同时试图对这个服务进行治理，通常会在业务的内部集成一个SDK，来实现服务发现、负载均衡、服务路由、重试、熔断限流等功能。

但是，这个架构存在三个主要问题：

第一，开发成本。因为A和B的服务已经是微服务了，它们可能是由不同语言开发的而且各自的框架可能也不同，如果希望把绿色的部分进行升级或者提供新的功能，就需要重复的迭代和开发。

第二，升级成本。因为SDK的部分跟业务耦合在一起，在新增一些能力时需要重新部署业务的模块。

第三，部署成本。由于相关治理的功能需要耦合在业务的配置里面，所以很难做到实时的下发配置，服务间拓扑关系和治理配置无法统一管理。

Service Mesh 是如何解决这些问题的?

如下图左侧所示，它通过将SDK 、开发框架提供的服务治理能力下沉到一个和业务进程独立的轻量级网络代理中，由这个网络代理作为微服务通信的基础设施层，它可以提供业务无关、语言无关、独立演进，透明升级的特性。这个轻量级的网络进程被称作Sidecar代理，是服务网格的数据面。

同时如右侧所示，通过一个对 Sidecar 进行统一控制和管理的服务控制平面，来提供对微服务治理和运维的统一入口。

这种架构实现了服务治理技术和业务逻辑的解耦，是云原生时代微服务治理技术的发展方向，也得到了越来越多的公司的关注。

2. 百度微服务治理的现状和痛点

百度在服务网格以及微服务相关的探索大概可以追溯到201