《系统架构设计师教程（第2版）》第14章-云原生架构设计理论与实践-03-云原生架构相关技术

1. 容器技术

1.1 容器概述

• 概述：

  • 容器作为标准化软件单元
  • 将应用及其所有依赖项打包
  • 使应用不再受环境限制，在不同计算环境间快速、可靠地运行

• 物理机、虚拟化、容器化部署的区别
  

• 容器化的核心价值

  • 敏捷

    提升企业I T架构敏捷性，使业务迭代更加迅捷

  • 弹性

    通过部署密度提升和弹性降低50%的计算成本

  • 可移植性

    Kubernetes成为资源调度和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上

1.2 docker

• Docker容器
  • 基于操作系统虚拟化技术
  • 共享操作系统内核
  • 轻量、没有资源损耗、秒级启动
  • 极大提升了系统的应用部署密度和弹性
• Docker镜像：可理解为Docker提出的创新的应用打包规范

1.3 Kubernetes

1.3.1 概述

• 概述

  • 提供了分布式应用管理的核心能力
  • 已经成为容器编排的事实标准

• 优势：

  • 可移植性：屏蔽了IaaS层基础架构的差异

• Kubernetes的上层业务抽象：

  • 服务网格 Istio
  • 机器学习平台Kubeflow
  • 无服务器应用框架 Knative

1.3.2 k8s的容器编排

• 资源调度

根据应用请求的资源量，以及node节点的剩余资源，在集群中选择合适的节点来运行应用。

• 应用部署与管理

应用的发布回滚、应用的配置管理、自动化存储卷的编排、存储卷生命周期与容器周期的关联

• 自动修复

节点健康检查与迁移；应用的自愈

• 服务发现与负载均衡

各种Service + DNS实现多种负载均衡机制，并支持容器化应用之间的相互通信。

• 弹性伸缩

资源使用到达预定值，自动扩容，增加pod

• 声明式API

Deployment 、 StatefulSet、 Job等不同资源类型，提供了对不同类型工作负载的抽象

• 可扩展性架构

所有K8s组件都是基于一致的、开放的API实现和交互

• 可移植性

2. 云原生微服务

1.2 微服务发展背景

• 微服务：

  • 将单体应用拆分为松耦合的多个子应用
  • 每个子应用负责一组子功能，称为“微服务”

• 分布式微服务体系：

  • 多个“微服务”共同形成了一个物理独立、逻辑完整的体系

• 优势：通过分布式架构将应用水平扩展、冗余部署，解决了单体部署在这些方面的缺陷

• 与云原生结合的优势：

  • 利用云资源的高可用和安全体系，以提高应用的弹性、可用性、安全性、稳定性，降低应用架构的复杂度
  • 云原生应用天然具有更好的可观测性、可控制性、可容错性等

1.2 微服务设计约束

1.2.1 微服务个体约束

• 合理拆分（合理划分好微服务间的边界），
  • 功能在业务上的划分是相互独立的

优势：

• 每个微服务可以使用自己适合的语言
• 微服务对应的团队更小，开发效率也更高

1.2.2 微服务与微服务之间的横向关系

• 横向处理微服务间的关系

  • 可发现性

  如，当服务A扩容时，依赖服务A的服务B在不重新发布的情况下，自动感知A的变化

  • 可交互性

  如， REST 协议，满足了“与语言无关”和“标准化”两个重要因素

1.2.3 微服务与数据层之间的纵向约束

• 数据存储隔离 (Data Storage Segregation) 原则：

即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。

• 微服务的设计应当尽量遵循无状态设计原则，

对于有状态的微服务，通常使用计算与存储分离方式，将数据下沉到分布式存储，通过这个方式做到一定程度的无状态化。

1.2.4 全局视角下的微服务分布式约束

• 从设计开始，就要考虑：
  • 高效运维，及CI/CD
  • 蓝绿、金丝雀发布
  • 全链路、实时和多维度的可观测能力，及时发现并解决故障

1.3 主要微服务技术

1.3.1 Apache Dubbo

• 概念：是一款高性能的Java RPC框架，用于解决微服务架构下的服务治理与通信问题。
• 特性：
  • 基于透明接口的RPC
  • 智能负载均衡
  • 自动服务注册和发现
  • 可扩展性高
  • 运行时流量路由
  • 可视化的服务治理
  • 服务网格 (ServiceMesh)（v3版）

阿里的其他相关开源：

• Spring Cloud Alibaba (分布式应用框架)
• Nacos(注册中心&配置中心)
• Sentinel (流控防护)
• Seata (分布式事务)
• Chaosblade (故障注入)

1.3.2 Spring Cloud

提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、 全局锁、决策竞选、分布式会话、集群状态管理等能力和开发工具

1.3.3 Eclipse MicroProfile

• 概念：
  • 是一个微服务的基准平台定义（原文称“作为Java微服务开发的基础编程模型”）
  • 即，定义了一套标准的、基础的技术集合，这个集合为构建微服务架构提供了核心的支持

它致力于定义企业Java微服务规范，提供指标、 API文档、运行状况检查、容错与分布式跟踪等能力，使用它创建的云原生微服务可以自由地部署在任何地方，包括服务网格架构。

1.3.4 Tars

• 腾讯的开源微服务框架

  基于其内部框架 TAF(Total Application Framework) 开发

• 特点：

  • 包含一整套开发框架与管理平台
  • 兼顾多语言、易用性、高性能与服务治理

1.3.5 SOFAStack

• 概念：
  • Scalable Open Financial Architecture Stack
  • 由蚂蚁金服开源
  • 构建金融级分布式架构的解决方案（教材原文说是“中间件”并不合适）
• MOSN
  • SOFAStack 的组件
  • 采用 G o 语言开发
  • 用于服务网格数据平面代理
  • 旨在提供分布式、模块化、可观测、智能化的代理能力
  • 支持Envoy 和 Istio 的API, 可以和Istio集成

  • Envoy是一个以C++开发的高性能非阻塞的服务代理程序
  • Istio是一个可配置的开源服务网格，用于连接、监控和保护Kubernetes集群中的容器

1.3.6 DAPR

• 概念：
  • 分布式应用运行时
  • Distributed Application Runtime
  • 是微软开源
• 特点：可移植的、无服务器的、事件驱动

3. 无服务器技术

3.1 概述

3.1.1 后端即服务（BaaS）

• Backend as a Service
• 是一种为Web、物联网或移动应用程序提供后端储存、计算等支持的云服务

教材原文称“是面向特定领域的后端云服务”

3.1.2 无服务器技术 (Serverless) 的特征

• 全托管的计算服务

  客户只需要编写代码构建应用，无需关注服务器等基础设施的开发、运维、安全、高可用等工作

• 通用性

  结合云 BaaSAPI的能力，能够支撑云上所有重要类型的应用；

• 自动弹性伸缩
• 按量计费

3.1.3 FaaS

• 概念：

  • Function as a Service
  • 函数计算
  • 是 Serverless中最具代表性的产品形态

• 原理：把应用逻辑拆分多个函数，每个函数都通过事件驱动的方式触发执行

• FaaS和容器技术的融合

  • 优势：
    • 容器化提供良好的可移植性
    • 基于容器工具链能够加快解决 Serverless的交付
  • 应用：
    • SAE：
      • Serverless App Engine
      • 阿里云提供的一个全托管、免运维、高弹性的通用PaaS平台
    • CloudRun服务
      • Google Cloud Platform提供的一项服务
      • 它提供了一个托管型的容器化运行环境，用户只需提供应用程序的容器镜像，无需关注服务器的管理和配置
    • Knativek框架：
      • Google基于 Kubernetes 的 Serverless应用框架

3.2 技术关注点

3.2.1 计算资源弹性调度

• 调度的行为
  • 已运行服务：根据实时情况，自动扩容缩容
  • 要创建的新服务：选择合适的计算节点创建

3.2.2 放置算法的目标

• 容错

如：实例时，应分布在不同的计算节点

• 资源利用率

如：在不损失性能的前提下，将计算密集型、 I/O密集型等应用调度到相同计算节点上
如：动态迁移不同节点上的碎片化实例

• 性能

如：复用启动过相同应用实例或函数的节点
如：利用缓存数据加速应用的启动时间

• 数据驱动

如：收集平台数据，用来验证调度算法的效果，为调优提供参考

3.2.3 负载均衡和流控

• 资源调度的负载均衡
  • 系统对资源调度服务的负载进行分片，
  • 分片管理器根据监控整个集群的分片和服务器负载情况，执行分片的迁移、分裂、合并操作
    • 分片的迁移：负载较高时，将分片迁移到资源多的服务器上
    • 分片的分裂：一个分片的资源占用较高，超过服务器负载时，将分片分裂成多个小分片
    • 分片的合并：分片管理器发现多个分片的负载都很低，将其合并为较大的分片
• 流量隔离控制
  • 多租户情况，计算资源要被不同用户共享以降低成本，因此需要隔离能力，以避免干扰

3.2.4 安全性

• 安全的必要性：其定位是通用计算服务，要能执行任意用户代码
• 安全维度：权限管理、网络安全、数据安全、运行时安全等
• 轻量安全容器的应用

  实现了更小的资源隔离粒度、更快的启动速度、更小的系统开销，使数据中心的资源使用变得更加细粒度和动态化，从而更充分地利用碎片化资源。

4. 服务网格 (ServiceMesh)

4.1 技术特点

• 目的：将微服务间的连接、安全、流量控制、观测等通用功能下沉为平台基础设施，达到与服务解耦
• 服务网格典型的架构
  

说明：

• proxy：代理A到B的请求，并负责B的发现、熔断、限流等
• Control Plane：以上策略的配置

4.2 云厂商共同采纳的开源软件和协议

下边将介绍 各云厂商共同采纳的开源软件和协议：

4.2.1 xDS协议和Envoy

• xDS协议：
  • Extensible Discovery Service
  • 可扩展的服务发现协议
  • 用于动态配置Envoy Proxy
• Envoy
  • 即，Envoy Proxy
  • 是一个高性能、可扩展的开源边缘和服务代理
  • 专为云原生应用设计，是服务网格中的一个重要组件
  • 得到Google、IBM、Cisco、Microsoft、 阿里云等的支持
• 和Istio的关系
  • Istio将xDS协议作为数据平面和控制平面间的标准协议

4.2.2 SMI(Service Mesh Interface)

• 概念：
  • 由Microsoft提出
  • 是一个针对云原生应用的网络管理规范
• 目标：提供一个通用的、可扩展的抽象层，以便于管理和配置多种服务网格
• 应用：
  • 为Istio、Linkerd等服务网格框架在服务观测、流量控制等方面实现最大程度的开源能力复用

4.2.3 UDPA(Universal Data Plane API)

• 概念：
  • 通用数据平面API
  • 基于xDS协议而来
  • 目标：为不同的数据平面提供统一的API

4.2.4 Wasm技术

• 作用：
  • 为扩展程序创建一个安全的隔离沙箱环境，有效地防止程序故障对整个系统的影响
  • Envoy代理的扩展
    • Envoy可以在运行中动态地加载Wasm模块
    • 开发者能够使用任何语言开发自己的Wasm过滤器
    • 对Envoy本身无侵入

4.3 主要技术

4.3.1 Istio服务网格

• 概念

  • 2017年发起的开源项目
  • 清晰定义了数据平面和管理平面
    • 数据平面：
      • 则主要负责服务之间的实际通信和流量处理
      • 由开源软件Envoy承载
    • 管理平面
      • 负责配置和管理整个服务网格
      • Istio 自身的核心能力
  • 它最初是为Kubernetes设计的

• 主要组件

  • Pilot (服务发现、流量管理)
  • Mixer (访问控制、可观测性)
  • Citadel (终端用户认证、流量加密)

• 关注点：连接和流量控制、可观测性、安全性、可运维性

  作用照着关注点说：如：为微服务架构提供了流量管理机制

• 适用：

  • 虚拟机或容器中

    虽然最初是为Kubernetes设计的，但它也可以应用于虚拟机中

  • 是大部分云厂商默认的服务网格方案

4.3.2 Linkerd

• 概述
  • 数据平面：用Rust语言实现了linkerd-proxy
  • 控制平面：go编写
• 优势：在时延、资源消耗方面强于 Istio
• 缺陷：功能上不如Istio

4.3.3 Consul

• 概述

  • 是一个服务发现和配置管理工具

  教材原文说它是一个Service Mesh 解决方案，这个说法实在太牵强了。它顶多算是Service Mesh的一个

  • 控制平面：使用 ConsulServer
  • 数据平面：可以选择性地使用 Envoy

4.3.4 Conduit

• 概述

  • Kubernetes 的超轻量级ServiceMesh
  • 数据平台：
    • Rust编写，快速、安全
    • 是应用代码之外运行的轻量级代理
  • 控制平面：
    • Go编写
    • 是一个高可用的控制器

• 目标：成为最快、最轻、最简单且最安全的ServiceMesh

• 特色：

  • 透明地管理服务之间的通信
  • 提供可测性、可靠性、安全性、弹性的支持
  • 与Linkerd相比，Conduit的设计更加倾向于 Kubernetes 的低资源部署

---