本篇内容主要讲解“服务网格相关知识点有哪些”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“服务网格相关知识点有哪些”吧!
什么是ServiceMesh
Service Mesh是一种非入侵、透明化的微服务治理框架。作为服务与服务直接通信的透明化管理框架，Service Mesh不限制服务开发语言、使用轻量级的通信协议（HTTP、gRPC等），并插件式的提供各类功能，如服务发现、负载均衡、智能路由、流量管控、性能分析等等，换而言之，用户通过Service Mesh得以用简单的方式获取高级的功能。
Rainbond原生支持Service Mesh，接下来我们将从服务发现和注册、弹性伸缩与负载均衡、容错处理（断路器与限流）、监控与报警、数据存储与共享、日志分析等方面进行解读。
服务发现和注册
服务注册是任何一个SOA/服务化/微服务框架必不可少的关键部分，与之密切相关的是一些强一致性分布式存储：Zookeeper、Etcd、Consul，其中Consul和Etcd基于Raft协议实现，Zookeeper基于PAXOS协议实现。
几乎所有的服务注册和发现都需要基于以上强一致性分布式存储实现，例如SpringCloud的两个重要的子项目Spring_Cloud_Consul/Spring_Cloud_Zookeeper。
对于Rainbond来说，通过应用/服务统一管理实现了所有部署应用/服务的自动注册。其原理在于Rainbond内部基于Kubernetes实现应用调度，注册于Kubernetes集群中的应用/服务信息，实际也是注册到了Etcd之中。应用实例每次重启，Rianbond都会为其分配不同的IP地址，服务注册信息将动态地改变。
我们知道，应用与应用直接通信之前必须首先发现对方，在这方面，Rainbond采用了声明式的发现机制，即当A服务需要与B服务通信，那么首先需要在A服务声明依赖B服务，而Rainbond应用运行时模块会基于用户声明发现对方服务地址，注入到A服务内部, 赋予A服务一个本地访问地址（127.0.0.1）访问B服务。
平台服务间的依赖关系
弹性伸缩与负载均衡
说到服务发现和注册，弹性伸缩与负载均衡也就不得不谈。
上文中A服务连接B服务，B服务可以是有状态的数据库服务，例如Mysql、MongoDB等，也可以是无状态的restfulAPI服务。
对于可以水平伸缩的应用（无状态应用或者分布式有状态应用），服务发现注入多个端点地址，必然需要负载均衡，因此A服务内部需要支持4层网络代理或者7层网络代理，通过应用运行时模块发现的后端地址注入到代理插件内部。
Rainbond默认的代理插件支持4层负载均衡，借助Service Mesh便于扩展得特性，我们可以再针对各种应用层协议匹配不同的网络治理插件，实现7层负载均衡，例如HTTP、gRPC、Redis等协议。
为什么需要7层负载均衡这样的高级功能？原因在于对于一些在线环境，我们希望可以对服务间调用实现热更改或者更好的容错，比方说A/B测试、灰度发布等等，必须要在7层负载均衡上完成。
Rainbond目前提供“基于envoy的7层网络治理插件”（envoy本身可以与安生运行于Rainbond插件体系之中），用户也可以选择和实现其他插件，Rainbond运行时将提供完善的基础服务。
配置7层高级负载均衡的方式
容错处理（断路器与限流）
能够容忍其中某些服务异常情况的微服务架构，才称得上是健壮的生产级微服务架构。
比方说某购物网站，订单页面会推荐其他相关商品，在大流量异常情况下，为了保证订单功能可用，将推荐功能（计算耗时，性能不好）限制可用，需要优雅的服务降级，将有限的资源用于关键服务的同时，保证整个系统稳定。
这里有两种方案：限流，将某个服务设置其最大的请求量或者连接数，硬性保护下游服务；断路器，当下游服务错误率到达一个阀值，将上游请求快速失败返回，保护上游服务稳定，同时又不给下游服务增加压力，做到快速失败、快速返回。
以上功能的实现对于业务系统来说相对复杂，而在上文提到的Rainbond高级负载均衡支持下，仅需为每个调用线路配置简单的限流参数或者熔断参数，即可实现断路器和限流机制开箱即用。
