下一代微服务架构——服务网格Service Mesh

下一代微服务架构——服务网格Service Mesh
服务治理
- 什么是服务治理
- 系统架构形态演进
- 现阶段存在的问题
Service Mesh是什么
- 概述
- 服务网格架构
Sidecar pattern
- 边车模式设计
- 边车模式解决了什么问题
- 从边车模式到 Service Mesh
- Service Mesh的具体实现
服务网格全景图
相关资料

下一代微服务架构——服务网格Service Mesh

服务治理

随着互联网行业的兴起，现在的系统架构越来越复杂，短短时间，服务架构为了最大限度的提升服务性能和开发，部署速度，衍生出了很多概念：微服务，面向服务编程，人工智能等等。今天我们要谈论的主要是关于微服务的发展。

什么是服务治理

服务治理可以理解为对服务生命周期的相关要素的管理。包括服务的系统架构设计、发布、定义、版本管理、线上监控管控、故障处理、系统安全性等。

比如我们常说的服务熔断，服务降级，服务异常剔除，对服务的性能监控等都输入服务治理的范畴。

系统架构形态演进

单体服务：在最初的业务简单，流量并不是很大的时候我们所有的业务都放在一个系统中，足以完成我们的业务。

特点： 1.部署相对简单，只需要进行单机部署。

2.模块之间进程之内调用

3.由于所有的业务都在一个系统，耦合度高

4.开发人员自己实现服务治理

微服务：随着业务越来越复杂，流量也越来越高，导致系统的性能面临着瓶颈，为了解决这个问题，微服务诞生了。微服务把原有的单体服务进行细化拆分成较小的服务，独立部署，服务间进行通信，完成业务。

特点：
1.功能模块独立部署

2.功能模块进程间调用

3.开发人员自己实现服务治理

SDK:将服务治理功能设计为一个公共库 SDK，让业务逻辑与这些功能减低耦合度，提高重复利用率，更重要的是开发者只需要关注公共库 SDK 的依赖及使用，而不必实现这些功能，从而更加专注于业务逻辑的开发。

特点：
1.SDK引用
2.SDK实现服务治理逻辑，可直接复用

现阶段存在的问题

耦合：业务逻辑和服务治理逻辑耦合在一起，具备了基本的服务治理能力，易于实现，但是会有一些缺陷：

1.基础设施功能（服务发现，服务注册，服务熔断等）和业务逻辑耦合。

2.不易于管理，假如某个服务的负载均衡变化，调用方都需要变化。

开发者需要兼顾服务治理的开发，不能致力于业务开发。

SDK升级问题：服务治理逻辑与应用系统混合在一个进程内，应用既有业务逻辑，也有服务治理逻辑，升级SDK也面临着应用变更，基础设施演进困难。

Service Mesh是什么

概述

从上边的阅读我们知道，我们要解决的问题就是**把服务治理下沉到基础设施。让业务更加专注于业务逻辑**。

说的直白点就是把我们的业务逻辑和服务治理的逻辑分开，找一个东东专门管理我们的服务治理，不需要我们操心了。这个管理服务治理的东东就是服务网格——Service Mesh。

服务网格的概念是由buoyant的CEO——William Morgan于 Linkerd产品在2016年并被首次提出，并解释了为什么云原生应用需要 Service Mesh。（有兴趣的同学请参照：https://buoyant.io/service-mesh-manifesto）

正如上边所说，Service Mesh 是一个基础设施层，其独立运行在应用服务之外，提供应用服务之间安全、可靠、高效的通信，并为服务通信实现了微服务运行所需的基本组件功能，包括服务注册发现、负载均衡、故障恢复、监控、权限控制等等。Service Mesh 的中文译为 “服务网格”。

它可以被用于处理服务与服务(service-to-service)之间的通信。通过构建云原生的现代化应用，服务网格能够使用复杂服务拓扑，来可靠地传递各种请求。服务网格的实现，实际上是与应用代码一起部署的轻量级网络代理阵列。服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。

一句话概括：Service Mesh是一组处理服务间通信的网络代理。

可能有些人是第一次听到服务网格这个名字，到这里你可能会有一个疑问：既然服务网格在2016年就被提出来了，而且还能解决这么多的问题，为什么很多公司没有使用到服务网格呢？（就是说我的公司没有用到呢？说白了就是为什么我自己怎么也没听过？）刚刚我们提到过，服务网格是基于云原生技术（Cloud Native）的，在云原生领域也是炙手可热的技术，在大部分的云厂商比如腾讯，阿里，AWS等等已经被广泛使用。服务网格提供了一个基础设施，使得开发人员更致力于业务逻辑的开发。但是Service Mesh的技术难度较高，现在的很多的公司云原生技术都不会使用，基于云原生的Service Mesh就更不会使用到了。但是大到随着时代的进步和发展，小到公司业务的复杂度和发展，我相信服务网格会越来越被广泛使用，真正成为下一代的微服务架构。

服务网格架构

（图片来自servicemesh.es）

浅色的Microservice就是我们上边提到的业务微服务，深色的Sidecar叫做边车服务（下边会对边车进行详细说明。）Sidecar作为业务微服务的代理来完成基础设施功能：如网络通信、安全、监控、流量控制等。从一个全局视角来看，Sidecar 连接成网，就是我们所说的网格mesh.

TCP 协议催生了分布式系统，分布式系统催生了微服务，Service Mesh 就是下一代微服务技术的代名词，是微服务时代的 TCP 协议。Service Mesh 以 Sidecar 形式，将服务治理从业务逻辑中剥离，并拆解为独立进程，实现异构系统的统一治理和网络安全。

控制平面：

控制和管理数据平面中的 Sidecar 代理，完成配置分发、服务发现、流量路由、授权鉴权等功能，以达到对数据平面的统一管理。控制平面不会直接解析请求数据包。通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面：

**由整个网格内的 Sidecar 代理组成，这些代理以 Sidecar 的形式和应用服务一起部署。**这些代理负责协调和控制应用服务之间的所有网络通信。每一个 Sidecar 会接管进入和离开服务的流量，并配合控制平面完成流量控制等方面的功能。

服务网格特点：

应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现

Sidecar pattern

所谓边车模式（Sidecar pattern ），也译作挎斗模式，是分布式架构中云设计模式的一种。因为其非常类似于生活中的边三轮摩托车而得名。该设计模式通过给应用程序加上一个“边车”的方式来拓展应用程序现有的功能。这种设计模式出现的很早，实现的方式也多种多样。现在这个模式更是随着微服务的火热与 Service Mesh 的逐渐成熟而进入人们的视野。

(生活中的摩托车)

提示：这里所说的边车模式是一种设计理念，而服务网格里边的sidecar是对边车模式的实现，这一节说的是这种设计理念。

边车模式是一种分布式架构的设计模式。如上图所示，边车就是加装在摩托车旁来达到拓展功能的目的，比如行驶更加稳定，可以拉更多的人和货物，坐在边车上的人可以给驾驶员指路等。边车模式通过给应用服务加装一个“边车”来达到控制和逻辑的分离的目的。

比如日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断等在业务服务中不需要实现的控制面功能，可以交给“边车”，业务服务只需要专注实现业务逻辑即可。如上图那样，应用服务你只管开好你的车，打仗的事情就交给边车上的代理就好。这与分布式和微服务架构完美契合，真正的实现了控制和逻辑的分离与解耦。

边车模式设计

在设计上边车模式与网关模式有类似之处，但是其粒度更细。其为每个服务都配备一个“边车”，这个“边车“可以理解为一个 agent ，这个服务所有的通信都是通过这个 agent 来完成的，这个 agent 同服务一起创建，一起销毁。像服务注册、服务发现、监控、流量控制、日志记录、服务限流和服务熔断等功能完全可以做成标准化的组件和模块，不需要在单独实现其功能来消耗业务开发的精力和时间来开发和调试这些功能，这样可以开发出真正高内聚低耦合的软件。

这里有两种方法来实现边车模式：

通过 SDK 、 Lib 等软件包的形式，在开发时引入该软件包依赖，使其与业务服务集成起来。

这种方法可以与应用密切集成，提高资源利用率并且提高应用性能。但是这种方法是对代码有侵入的，受到编程语言和软件开发人员水平的限制，但当该依赖有 bug 或者需要升级时，业务代码需要重新编译和发布。同时，如果该依赖宣布停止维护或者闭源，那么会给该服务带来不小的影响。

以 Sidecar 的形式，在运维的时候与应用服务集成在一起。

这种方式对应用服务没有侵入性，不受编程语言和开发人员水平的限制，做到了控制与逻辑分开部署。但是会增加应用延迟，并且管理和部署的复杂度会增加。

边车模式解决了什么问题

边车模式在概念上是比较简单的，但是在实践中还是要了解边车模式到底解决了什么问题，我们为什么要使用边车模式？

控制与逻辑分离的问题

边车模式是基于将控制与逻辑分离和解耦的思想，通俗的讲就是让专业的人做专业的事，业务代码只需要关心其复杂的业务逻辑，其他的事情”边车“会帮其处理，从这个角度看，可能叫跟班或者秘书模式也不错