微服务 MicroServices 和服务网格 Service Mesh

一：微服务 MicroServices

侵入式

架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立开发、部署、运行，微服务间是松耦合

微服务架构 ≈ 模块化开发 + 分布式计算

常见的微服务组件和概念：

* 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己
* 服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址
* 负载均衡：让服务调用方连接到多实例形式提供服务的服务提供方的合适服务节点
* 服务网关：服务网关是服务调用的唯一入口，可实现鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能
* 配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，可动态更新
* API 管理：
* 分布式事务：通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性
* 服务链路跟踪：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来
* 支撑平台：微服务化后，需要通过 Docker、K8S 对系统进行持续集成

二：服务网格 Service Mesh

非侵入式

服务间通信的基础设施层。是应用程序或微服务间的 TCP/IP，负责服务间的网络调用、限流、熔断和监控。由轻量级网络代理组成并与应用程序或微服务部署在一起

Service Mesh 通过开发框架中的网络库来解决服务间调用问题（简化了微服务架构中服务间调用复杂度）

* Service Mesh Sidecar（边车）

解决应用级别通用的网络问题，将问题与应用程序或微服务中的业务代码完全隔离，开箱即用

* Service Mesh Control Plane

负责管理所有 service mesh 的代理

功能特性：

* 服务间调用的弹性处理：熔断、超时、重试、错误处理、负载均衡、故障转移。
* 服务发现：通过专用服务注册表发现服务终结点。
* 路由：提供原始的路由功能，不涉及服务中业务相关的路由功能。
* 监控：度量、监控器、分布式日志、分布式跟踪。
* 安全：传输层安全，key 管理。
* 访问控制：基于黑名单、白名单的访问控制。
* 部署：原生支持容器，Docker 和 Kubernetes。
* 通信协议：HTTP1.x, HTTP2, gRPC, TCP。

优点：

* 业务代码非侵入式，跨语言
* 应用程序间通讯的中间层
* 轻量级网络代理
* 应用程序无感知
* 解耦应用程序的重试/超时、监控、追踪和服务发现

缺点：

* 增加了系统整体的复杂度（如增加了 Sidecar、Control Plane）
* 服务间通信的代理模式计算并转发请求，降低系统通信性能，增加系统资源开销

架构：

* 第一代 Service Mesh = n * (Service Mesh Sidecar（边车）+ MicroService)
* 第二代 Service Mesh：= Service Mesh Control Plane + n * (Service Mesh Sidecar（边车）+ MicroService)

开源项目：

* Linkerd：第一代 Service Mesh
* Envoy：第一代 Service Mesh
* nginMesh：第一代 Service Mesh，作为 Istio 的服务代理，替代 Envoy
* Istio：第二代 Service Mesh
* Conduit：第二代 Service Mesh 借鉴 Istio 整体架构，部分进行了优化
* Kong：

微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合

第一代 Service Mesh ####

将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求

代表：Linkerd，Envoy，NginxMesh

第一代 Service Mesh = n * (Service Mesh Sidecar（边车）+ MicroService)

第二代 Service Mesh

在第一代 Service Mesh 基础上，提供集中式的控制面板作为统一的上层运维入口，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报

代表：Istio、Conduit、Kong

第二代 Service Mesh：= Service Mesh Control Plane + n * (Service Mesh Sidecar（边车）+ MicroService)

Sidecar 边车模式

Sidecar 模式（Service Mesh 中习惯采用的模式）：将应用程序的功能划分为单独的进程。允许在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码

优点：

1. Sidecar 连接到父应用并且为其添加扩展或者增强功能
2. Sidecar 应用与主应用程序松散耦合
3. 屏蔽不同编程语言的差异
4. 统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能

使用：使用 Sidecar 模式部署服务网格

1. 无需在节点上运行代理，但在集群中运行多个相同的 Sidecar 副本
2. 为每个应用的容器部署一个伴生的容器
3. Sidecar 接管进出应用程序容器的所有网络流量

参考：

* 微服务（Microservices）和服务网格（Service Mesh）架构概念整理
* 开发者必须要了解的架构技术趋势：Service Mesh
* 什么是 Service Mesh【参考：Pattern: Service Mesh】
* Pattern: Service Mesh
* Sidecar 模式