指月小筑(探索云原生)
文章 标签 分类 关于
指月小筑(探索云原生)

Contents

Istio教程(二)---Service Mesh的起源、演进、定义

意琦行 included in Service Mesh
   2757 words   6 minutes 

本文主要对 Service Mesh的起源、演进以及定义做了简要介绍，让大家对 Service Mesh 有一个大致的认知。

1. Service Mesh 的起源

本章介绍了什么是微服务，微服务架构的优势以及微服务面临的问题，以及如何解决这些问题（Service Mesh ）。

1.1 什么是微服务

最早由软件工程大师 Martin Fowler 写过一篇著名的文章: 微服务 ，其中给出了微服务的定义，其中有两个特点：

  • 1）围绕业务构建团队
  • 2）去中心化的数据管理

围绕业务构建团队

下图就是单体应用的典型模式，开发团队按照职能划分成了不同的层次，组合在一起。

../../../img/istio/servicemesh/conways-law.png

微服务架构中整个开发团队会围绕着业务去构建，所以结构和单体不太一样，把不同职能的人组合成一个个小团队，每个小团队对应着一个独立的业务。

../../../img/istio/servicemesh/PreferFunctionalStaffOrganization.png

康威定律 是马尔文·康威 1967 提出的：

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

“设计系统的架构受制于产生这些设计的组织的沟通结构。”

通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

因为跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式，就像这样，不同产品的架构基本能反映出内部人员的架构：

../../../img/istio/servicemesh/conways-law-example.png

去中心化的数据管理

../../../img/istio/servicemesh/decentralised-data.png

在单体模式下，数据库逻辑上是一个整体（有可能物理上它的部署不是一处），它的数据是中心化的。

在微服务模式下，数据库和业务是绑定在一起的，不同的业务会持有不同的数据库。

这就是所谓的去中心化的数据特点。

1.2 微服务的优缺点

微服务的优势

  • 团队层面：内聚，独立开发，没有依赖
    • 强化服务边界，沟通成本降低
    • 独立开发，技术多样性
  • 产品层面：服务彼此独立，独立部署，没有依赖
    • 充分利用系统资源

微服务是软件架构的银弹吗？

银弹理论：没有任何一种技术和管理上的进步，可以极大的提升生产效率。

不是，微服务同样面临着自己的问题。

微服务面临的问题

最大问题为服务间网络通信。

当整个系统由多个微服务构成，服务间的调用会及其复杂，此时问题的排查难度成倍增加。

分布式计算的8个谬论（Fallacies of Distributed Computing Explained）

  • 网络是可靠的
  • 网络延迟是0
  • 带宽是无限的
  • 网络是安全的
  • 网络拓扑从不改变
  • 只有一个管理员
  • 传输成本是0
  • 网络是同构的

分布式系统中，网络问题是经常出现的，是一个主要问题，而微服务架构中，因为服务变得越来越多，变得更离散，交互也越来越多，所以网络问题出现的概率会更大，这就是微服务架构最大的一个痛点。

1.3 如何管理和控制服务间的通信

  • 服务注册发现
  • 流量控制：路由，流量转移
  • 弹性能力：熔断、超时、重试
  • 安全
  • 可观测性

而这些能力正好是 Service Mesh 所具备的，也及时说 Service Mesh 的出现实际上是为了解决当前微服务所面临的问题。

因此，也有人说 Service Mesh 是第二代微服务

2. Service Mesh 的演进

本章主要介绍了 Service Mesh 技术的发展历史以及Service Mesh的定义。

推荐阅读：有一篇非常著名的文章叫：Pattern: Service Mesh，它详细介绍了 Service Mesh 是如何从最初的原始状态一步一步演进到现在这种形态的。

2.1 起源

阶段一：控制逻辑和业务逻辑耦合

../../../img/istio/servicemesh/service_mesh_stage_1.png

在写业务逻辑时难免需要写一个网络流量控制相关的逻辑，比如限流、过载保护、服务发现、服务治理等等，导致网络流量控制相关逻辑和业务代码耦合在一起。

就像这样，业务代码中夹杂着重试逻辑：

for retry := 0; retry < 3; retry++ {
    if response,err:=http.Get(url);err==nil{
        break
    }
}

阶段二：公共库

../../../img/istio/servicemesh/service_mesh_stage_2.png

因为第一阶段中，控制逻辑和业务逻辑耦合严重，所以想着把它抽取出来，于是形成了公共库。

比如 Java 生态中比较火的 SpringCloud ，将服务发现、服务治理、流量控制等逻辑抽并整合在一起形成一个新的工具类库。

公共库实现了解耦和复用，但还是不够完美，公共库一般是语言绑定的，同时对业务逻辑还是有侵入的。

同时还有一个成本问题，学习和部署方面都是比较困难的，需要有专人负责。

阶段三：代理

../../../img/istio/servicemesh/service_mesh_stage_3.png

这里的代理指 Nginx 这种 WebServer 组件，可以实现流控、负载均衡等功能。

虽然功能不够完善，但是这个思路是正确的。因为 Nginx 这样的组件已经和业务代码完全解耦。

2. 产生

阶段四：Sidecar

../../../img/istio/servicemesh/service_mesh_stage_4.png

所有流控相关逻辑，全部由 Sidecar 实现，部署时将 应用和 Sidecar 部署在一起，然后流量先进入到 Sidecar 走流控相关逻辑，之后再由 Sidecar 转发给应用执行真正的业务逻辑。

既实现了流控的所有功能又和业务完全解耦，是一个相对比较完美的解决方案。

Sidecar 可以说就是 Service Mesh 的前身。

阶段五：ServiceMesh

../../../img/istio/servicemesh/service_mesh_stage_5.png

图中绿色为微服务应用，蓝色为 Sidecar。

所有 Sidecar 组合而成的网络拓扑就是 ServiceMesh。

这也叫做第一代 ServiceMesh

2.3 演进

阶段六：控制平面

../../../img/istio/servicemesh/service_mesh_stage_6-1.png

../../../img/istio/servicemesh/service_mesh_stage_6-2.png

在第一代 ServiceMesh 基础上新增了 控制平面，由这个 控制平面 来管理整个 Sidecar 集群。

这也是现在的 ServiceMesh 形态，也叫作第二代 ServerMesh。

小结

ServiceMesh 的演进经历了 6 个阶段。

  • 1）逻辑耦合
  • 2）公共库
  • 3）代理
  • 4）Sidecar
  • 5）ServiceMesh
  • 6）ServiceMesh V2

../../../img/istio/servicemesh/service_mesh_development_process.png

3. Service Mesh 定义

本章主要包括 Service Mesh 的定义、产品形态、核心功能以及技术标准等。

定义

这个定义是由 Linkerd 的 CEO William 给出来的。Linkerd 是业界第一个 Service Mesh，也是他们创造了 Service Mesh 这个词汇的，所以这个定义比较官方和权威。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. lt’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。

  • 本质：基础设施层
  • 功能：请求的可靠传递
  • 部署形态：轻量级网络代理 Sidecar
  • 特点：和业务逻辑完全解耦

一句话描述：ServiceMesh 是一个用来进行请求转发的基础设施，它以 Sidecar 代理的形式部署并且对业务透明。

产品形态

主要由两部分构成：

  • 数据平面：也就是 Sidecar
  • 控制平面：进行总体的控制

也可以说：Service Mesh 是 Sidecar 的网络拓扑模式

../../../img/istio/servicemesh/service_mesh_stage_6-2.png

核心功能

  • 流量控制
    • 路由、流量转移
    • 超时重试、熔断
    • 故障注入
    • 流量镜像
    • 灰度发布、蓝绿发布
    • 请求转发
  • 策略
    • 流量限制
    • 黑白名单
  • 安全
    • 授权
    • 身份认证
  • 可观测性
    • 指标收集和展示
    • 日志收集
    • 分布式追踪

和 Kubernetes 的关系

Kubernetes

  • 解决容器编排与调度问题
  • 本质上是管理应用生命周期(调度器)
  • 给予 Service Mesh 支持和帮助
    • 比如 Pod 支持多容器就让 Sidecar 注入很方便

Service Mesh

  • 解决服务间网络通信问题
  • 本质上是管理服务通信(代理)
  • 是对Kubernetes网络功能方面的扩展和延伸

技术标准

随着各种 Service Mesh 产品的出现，也演化出了对应的技术标准

  • UDPA：Universal Data Plane API,数据平面接入标准

  • SMI：Service Mesh Interface，控制平面标准

../../../img/istio/servicemesh/servicemesh-interface.png

4. 小结

  • Service Mesh 的起源：为了解决微服务面临的服务间通信问题

  • Service Mesh 的演进：大致经历了六个阶段

    • 控制逻辑和业务逻辑耦合
    • 抽取公共库
    • 使用代理
    • Sidecar
    • 第一代 SerivceMesh
    • 第二代 SerivceMesh：增加控制平面

  • Service Mesh 的定义：最终形成的一个比较官方的定义、产品形态、技术标准等

    • 定义：ServiceMesh 是一个用来进行请求转发的基础设施，它以 Sidecar 代理的形式部署并且对业务透明
    • 产品形态：数据平面（Sidecar）+ 控制平面
    • 技术标准：UDPA（数据平面） + SMI（控制平面）
Updated on 2023-08-05
 Istio
Back | Home