Service Mesh在百度网盘数万后端的实践落地

个人博客导航页（点击右侧链接即可打开个人博客）：互联网老兵带你入门技术栈 

1 背景

起初，在网盘快速发展期，为了快速上线，采用了服务单体化 + 主干开发模式进行研发，随着用户规模爆发式的增长以及产品形态的丰富，单体化的不足就体现出来了，于是架构上采用了微服务架构，开始对业务逻辑进行拆分部署。

服务拆分之后，也引入了新的问题，具体如下：

**请求路由：**服务部署从物理机向虚拟化方式迁移中，有大量的切流量操作，需要相关的上游都进行升级上线修改，效率低下

**故障管理：**单实例异常、服务级别异常、机房故障异常、网络异常等，严重缺失或者不完善，同时配套的故障定位也没有，服务稳定性不足

**流量转发：**不同的服务采用了不同的框架，甚至裸框架，策略不完善，导致负载不均衡

**研发效率：**相同的功能点，需要在不同的语言框架上实现一次，浪费人力，同时升级周期比较长，收敛效率低

2 解决方案 - UFC

2.1 UFC 发展史

为了解决这个问题，从2015年底开始思考解决方案，确定了解决问题的核心在于管控请求流量，在2016年开始自研网络流量转发中间件 - UFC(Unified Flow Control)，业务通过同机部署的agent进行服务通信，相关的发展史如下：

2.2 UFC 和 Service Mesh的关系

后来在调研业界相关技术的时候，发现了istio(业界Service Mesh的典型代表)，从而发现了Service Mesh的存在，而它的定义是在2016.9 由Buoyant 公司的CEO William Morgan 提出的：

Service Mesh是一个专门用来处理服务和服务之间通信的基础设施。它复杂确保在一个由复杂服务构成的拓扑的现代云应用中，请求能够被稳定的传递。在实践中，Service Mesh通常通过一系列轻量级的代理来进行实现。这些代理和应用同机部署，而应用不需要感知到代理的存在。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

从定义上，我们不难发现UFC和Service Mesh的设计理念是一致的，都是基于sidecar模式，有着控制面板和数据面板，UFC是Service Mesh的一种实现。感慨的说，历史的发展潮流是一致的，不管你在哪里。

目前UFC应用于网盘过千个服务上，涉及虚拟化实例数量超过20W，千亿PV，机器规模10W+(网盘+其它产品线机器)，10个IDC，从已知的实例规模上看，是国内最大的Service Mesh的实践落地。

2.3 基于Service Mesh 之上的服务治理

百度网盘的实践落地并不只局限于Service Mesh，首先是构建了从点延伸到线的Service Mesh进行服务通信管控，然后是在UFC这个Service Mesh的基础之上，站在全局视角对服务进行治理，保障服务的稳定性，相关能力等发展如下：

**点：**关注与下游进行通信，不关注上游的情况

**线：**加入上游的标识，基于上游做异构的通信策略

**面：**多条线组成面，站着全局视角进行服务治理

2.4 本文概要

本文将会先介绍UFC(如何实现一个Service Mesh)，然后是基于UFC做服务治理(基于Service Mesh的实践应用)

3 UFC 外部视角简介

3.1 用户使用视角

只需要做两个事情：

1. 服务注册：需要先确保自己的服务(上游)和要访问的服务(下游)已经注册过了，没注册过，则需要服务的owner进行服务注册
2. 服务通信：用户通过单机agent进行服务通信访问下游，下图显示了用户从直接访问下游变成了通过同机agent访问下游

3.1.1 服务注册

UFC为每个注册的服务分配一个service_name，service_name 是这个服务的唯一标识。同时需要对这个service_name配置它的相关配置：比如destination来源、负载均衡、熔断、超时重试等策略

3.1.2 服务通信

访问下游的时候，只需要访问本机固定端口，带上下游服务的service_name、自身标记、trace等信息，例如下面就是一个发请求的demo例子：

curl “http://127.0.0.1:8888/URI” -H “x-ufc-service-name=to_service_name” –H “x-ufc-self-service-name=from_service_name” -H “x-ufc-trace-xxxx = xxxxx”

3.2 UFC能力视角

介绍UFC基于点和线视角的相关能力，从服务声明、请求路由、流量转发、故障处理、故障定位、安全等维度和istio做了一个比较。而istio是大部分是基于下游这个点进行相关通信能力设计，线视角能力很少(比如权限认证等)

总结来说，istio是能力全面，但是具体实现上策略比较简单，而UFC是更贴近实际的业务场景(具体的可以看后面的介绍内容)

PS: 有些能力(比如流量复制/权限管理)UFC没有，并代表百度网盘没有这方面的能力，只是因为历史原因，通过其它的方案解决了。但是故障注入这块，的确是UFC需要考虑的，有了这块的能力，混沌工程也更容易的落地。

4 UFC 内部视角简介

主要是介绍架构和相关具体能力的实现设计初衷

4.1 架构设计

整个架构和Service Mesh一样，都是采用了同机Sidecar进行了流