服务网格模式(Server Mesh)

服务网格模式(Server Mesh)

服务网格模式可以看作是边车模式的集群方式，当多个边车相互连接在一起就形成了一个一个的服务网格，网格其实就是相互关联的服务

Server Mesh(去中心化)：

在网络协议栈中，为了避免应用程序加入一些流量控制、拥塞的逻辑，从而将一些保证数据可靠到达对端的基本逻辑封装到一个组件中也就是TCP协议，然而应用程序只关心业务逻辑，已经需要发送什么格式数据到对方就可以，将流控和拥塞控制交给TCP。 其实这里的Server Mesh 就类似于TCP协议。

服务容错和保护：
限流、熔断(断路器会记录服务返回的异常次数，例如服务不可用错误，当异常次数达到阈值时，就会对断路器进行熔断对后面的请求直接返回错误或特定值)、流量监控、日志记录、权限控制、服务发现和路由

以上功能都是对服务进行控制，如果把这些功能做成一个组件或作为一个服务提供给应用进行使用，那么应用就只关心其业务逻辑就行。如果把Server Mesh做成一个向外提供的集群服务(例如Pass服务)，只要业务服务往这个集群服务加入，由Server Mesh帮你完成一些控制逻辑(服务容错和保护)

应用和边车是如何工作？

应用和边车部署在同个机器上(不同的进程，通过本地RPC进行通讯)也可以在不同机器进行数据通讯， 边车你可以看作成应用的网络代理(边车能够实现服务发现和路由、限流和熔断等逻辑处理)，同时还需要有个控制中心，对当前服务流量进行收集、分发各种策略到边车上。

Dubbo和服务网格区别

Dubbo仅仅是RPC框架，实现服务发现和路由进行两台计算机数据传递，并不提供限流和熔断等一些其他功能，要实现这种功能就需要引入 Hystrix或Sentinel 第三方jar来实现限流和熔断功能，实际上就是一个代理，完成请求、或错误的统计，当达到阈值时返回一个固定值或拒绝请求。

Dubbo在消费端获取到服务提供端的地址，然后直接调用服务端接口，而服务网格是消费端将请求交给一个边车服务(网络代理服务)，由这个边车实现服务路由和其他控制逻辑，最终会将请求交给服务提供者边车，最终再传给服务提供者，处理完后返回结果。

为什么要用服务网格

为服务于服务之间通讯提供了通讯的基础设施，更好的管理分布式服务，同时为了保证分布式服务高可用性，需要对流量实时监控，必要时为了保证服务稳定运行下去需要进行限流和熔断处理。

服务网格模式和网关模式区别

使用服务网格是去中心化的一种实现，不像网关模式那样中心化。当网关前面一层负载均衡器down机了就会导致所有服务不可用，负载均衡器实现高可用成本较大(负载均衡器的高可用使用虚拟IP技术实现)。从用户请求发起会经过nginx->网关->服务链路太长，网络时延大。服务网格把负载均衡逻辑放在了调用端。由于每个服务边上都有个边车，所以服务网格架构部署更复杂。

将原来每个服务边上的边车换成了集中式的网关模式
网关模式不必管理所有服务节点，根据需要可以针对某几个应用服务进行管理。当后端服务很多时，可以给每组服务设定一个子网关，由总网关进行分发请求到子网关上，最后打到各个服务上。

网关和服务网格使用场景

一般网关代理用户请求到应用服务，因为客户端不易支持一些复杂的协议和一些复杂的逻辑，因此更合适发送http请求。 但是服务之间调用非常频繁，一个http请求接口可能导致后端多个服务之间进行调用，所以在服务内部之间更合适使用服务网格方式调用，减少了网络时延并且在调用端实现负载均衡逻辑，是一种去中心化的实现