# 服务网格(ServiceMesh)

客户端请求网页常常会经过代理，代理请求后面的服务，后台服务返回给代理，代理再返回给客户端。这是一个典型的代理服务的情景。大概是这样：

```bash
Client <-> Proxy <-> Server
```

现代后端开发，将服务拆分成多个微服务是常见的做法。

```bash
Client <-> Interface <-> [ProxyA->ServerA] <-> [ProxyB->ServerB]
Client <-> Interface <-> [ProxyB->ServerB] <-> [ProxyA->ServerA]
```

微服务之间的互相访问，公共的代理部分可以做很多公共的控制逻辑。这部分的的代码标准化，下层到云原生的基础设施里，就形成了服务网格（ServiceMesh）。服务网格通常管理微服务之间这三个方面的功能：

1. 流量管理(Traffic management)：动态服务发现、路由、流量灰度和流量分离等。
2. 安全(Security)：加密传输、基于正式验证的授权、基于访问控制和网络分区的授权等。
3. 可观察性(Observability): 例如链路跟踪、日志等。

服务网格和 k8s 之间是什么关系呢？一图胜千言，在k8s的基础上，为每个pod增加一个proxy（或者叫边车，sidecar),有两个变化：

1. 原来k8s的node里的pod通过node的kube-proxy和 API Server 通信；在ServiceMesh下，每个pod直接通过装在pod上的proxy和API Server通信。
2. 原来k8s的node里的pod通过node的kube-proxy桥接通信；在ServiceMesh下，每个 pod 之间直接通过装在 pod上的proxy直接通信。

![](https://gitcode.net/csdn/skill_tree_cloud_native/-/raw/master/data/1.云原生初阶/5.服务网格(istio)/1.ServiceMesh介绍/img/k8s_native_vs_service_mesh.png)
<br/>

以下说法错误的是？

## 答案

服务网格之间的通信都要通过 API Server 转发。

## 选项

### A

服务网格通常解决流量管理、服务安全、服务可观察性问题。

### B

在k8s原生组件的基础上，给每个pod安装服务网格的proxy，对这些proxy的编排调度，构成里服务网格层。

### C

服务网格的特点是，将微服务管理功能内置到基础架构层，无需在应用层写相关代码。