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:
- 阿里云提供的一个全托管、免运维、高弹性的通用PaaS平台
- CloudRun服务
- Google Cloud Platform提供的一项服务
- 它提供了一个托管型的容器化运行环境,用户只需提供应用程序的容器镜像,无需关注服务器的管理和配置
- Knativek框架:
- Google基于 Kubernetes 的 Serverless应用框架
- SAE:
- 优势:
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
- 基于xD S协议而来
- 目标:为不同的数据平面提供统一的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 的低资源部署