为什么需要service Mesh
微服务需要解决的问题和对应的中间件
- 用 RPC 框架解决服务通信的问题；
- 用注册中心解决服务注册和发现的问题；
- 使用分布式 Trace 中间件，排查跨服务调用慢请求；
- 使用负载均衡服务器，解决服务扩展性的问题；
- 在 API 网关中植入服务熔断、降级和流控等服务治理的策略
** 如何让服务治理的策略在多语言之间复用呢**
可以考虑将服务治理的细节，从 RPC 客户端中拆分出来，形成一个代理层单独部署。这个代理层可以使用单一的语言实现，所有的流量都经过代理层来使用其中的服务治理策略。这是一种“关注点分离”的实现方式，也是 Service Mesh 的核心思想
什么是Service Mesh
Service Mesh 主要处理服务之间的通信，它的主要实现形式就是在应用程序同主机上部署一个代理程序。一般来讲，我们将这个代理程序称为“Sidecar（边车）”，服务之间的通信也从之前的客户端和服务端直连，变成了下面这种形式
RPC 客户端将数据包先发送给与自身同主机部署的 Sidecar，在 Sidecar 中经过服务发现、负载均衡、服务路由、流量控制之后，再将数据发往指定服务节点的 Sidecar，在服务节点的 Sidecar 中，经过记录访问日志、记录分布式追踪日志、限流之后，再将数据发送给 RPC 服务端
这种方式可以把业务代码和服务治理的策略隔离开，将服务治理策略下沉，让它成为独立的基础模块。这样一来，不仅可以实现跨语言服务治理策略的复用，还能对这些 Sidecar 做统一的管理
目前提的最多的方案是 Istio
它将组件分为数据平面和控制平面，数据平面就是 Sidecar（Istio 使用Envoy作为 Sidecar 的实现）。控制平面主要负责服务治理策略的执行，在 Istio 中，主要分为 Mixer、Pilot 和 Istio-auth 三部分
如何将流量转发到sidecar 中
在 Service Mesh 的实现中，一个主要的问题是如何尽量无感知地引入 Sidecar 作为网络代理。也就是说，无论是数据流入还是数据流出时，都要将数据包重定向到 Sidecar 的端口上。实现思路一般有两种：
-
一种，使用 iptables 的方式来实现流量透明的转发，而 Istio 就默认了使用 iptables 来实现数据包的转发
优点：Iptables 方式的优势在于对业务完全透明
缺点：在高并发下，性能上会有损耗
-
轻量级客户端
RPC 客户端会通过配置的方式，知道 Sidecar 的部署端口，然后通过一个轻量级客户端，将调用服务的请求发送给 Sidecar。Sidecar 在转发请求之前，先执行一些服务治理的策略，比如，从注册中心中查询到服务节点信息并且缓存起来，然后从服务节点中，使用某种负载均衡的策略选出一个节点等等
请求被发送到服务端的 Sidecar 上后，然后在服务端记录访问日志和分布式追踪日志，再把请求转发到真正的服务节点上。当然，服务节点在启动时，会委托服务端 Sidecar 向注册中心注册节点，Sidecar 也就知道了真正服务节点部署的端口是多少
