下载掌阅APP，畅读海量书库
立即打开
服务网格是一个非常新的名词，于2016年由开发Linkerd的Buoyant公司提出，伴随着Linkerd的推广，服务网格的概念也慢慢进入国内技术社区。
任何一个架构都会有缺点，当微服务数量越来越多时，也逐步暴露出了一些问题。
·微服务的拆分和边界如何定义？应该拆分多少微服务？
·微服务间相互调用时，如何快速找到目标服务提供者？如何保障调用方的身份安全？
·下游微服务不可用时，如何快速熔断，保护当前微服务从而避免雪崩？
·如何通过调整权重和路由快速上下线微服务，治理微服务的负载均衡？
·如何管理复杂的上下游微服务依赖，快速定位出问题的微服务？
工程师除了关注业务功能实现外，还要聚焦微服务治理的控制。上述问题基本就是微服务治理要关注的服务发现、服务鉴权、服务熔断、负载均衡、服务依赖等内容。当然这些功能的实现有很多种方法，我们直接往微服务中增加对应的服务治理功能就好，但这样做往往有一个致命的缺点，就是复用性很差。当只有1个微服务的时候，服务治理的功能放在哪里都无可厚非，但是当我们拥有成百上千，甚至上万个微服务时，我们不能对每个微服务都增加相同的功能模块。更合理的做法是把共用的能力抽象后提取出来，作为一个独立的模块，常用的做法是抽象出通用的SDK（Software Development Kit，软件开发工具包），比如common-hystrix（熔断功能的通用包）。
通过通用能力的抽象，实现了服务治理功能的复用。它与业务功能耦合在同一个进程、同一个代码仓库里，业务开发人员还是会关注Common包的更新和维护，既然通用服务治理能力相对独立，能不能像PaaS或AOP（Aspect Oriented Programming，面向切面编程）一样，把它抽象成独立的一个层次出来，与业务代码解耦，交给专人来维护呢？答案就是服务网格。
相对于1.7.1节提到Common包，服务网格有如下特点。
·作为应用程序间通信的中间层。
·轻量级网络代理。
·应用程序无感知。
·解耦应用程序的重试/超时、监控、追踪和服务发现。
可见，服务网格的本质是一种代理，请求在微服务之间调用的过程中增加了一层代理来进行路由，而为了降低代理对微服务的侵入性，代理往往通过Sidecar的形式运行，类似于Spring的AOP，只不过这个切面增强不是在某段代码里，而是在统一的Java进程外，这样众多Sidecar之间形成了一个庞大的切面网络，我们形象地称之为服务网格，如图1-14所示。
图1-14 服务网格示意图
服务网格涉及两个概念，一个是数据平面，另一个是控制面。图1-14中的Sidecar就是数据面，通过接收控制面发送的路由与控制信息来定向转发或处理数据。数据面通常有如下职责。
·服务发现：发现后端服务实例中哪些是可用的。
·健康检查：定时向服务发送心跳，探测服务实例是否存活。
·鉴权：对于访问的请求，通过加解密来验证访问是否合法。
·负载均衡：对于多个下游服务，均衡分配流量。
·流量统计：对于每个请求，每分钟的流量，trace信息如何统计。
·熔断限流：确定最大QPS（Queries-Per-Second，每秒查询率）、最大并发数，以及何时拒绝请求。
数据面主要接收系统中的每一个包和请求，具体什么时间进行熔断限流、如何确认服务是否健康，这些逻辑关系都需要控制面的支持。目前业界常见的数据面有Linkerd、Envoy、HAProxy、Nginx，控制面有Istio、SmartStack等。
服务网格最大的优势就是实现了微服务业务架构和服务控制的解耦，应用服务不再需要为了接入微服务框架而在代码中配置繁多的依赖库和配置项，可以专注于实现自己的业务逻辑。如果没有服务网格，每项微服务的共性需求都要进行重复编码，比如大家常见的流量统计、trace埋点、限流控制等操作，这些操作可能是大部分微服务都要关注的，而通用功能的实现方式千差万别。
每个微服务的维护者能力参差不齐，实现业务功能的同时，还要关注稳定性、性能，必然会牵扯一定的精力，服务网格恰恰就是把这些共性的能力抽象出来，作为统一的实现层，由基础架构团队实现，统一部署为微服务的Sidecar，实现全局的流量统计、trace埋点、流量控制等功能。同时，由基础架构团队对服务网格进行升级和维护，这样业务开发人员可以更好地聚焦业务功能的实现，进而实现组织效率的大幅提升。
服务网格提供的常用功能如下。
·服务发现。
·负载均衡。
·加密通信。
·观察与追踪微服务之间的拓扑。
·服务之间访问的鉴权与授权。
·熔断机制。