云原生架构 - 技术栈

1.云原生定义

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

可以把云原生简单的了解为云原生是一种新的技术架构模式及软件开发的思想理念

1.1 名称的理解

云原生英文名称 cloud native 云原生=云 + 原生，其中云表示的是云计算 Cloud Computing。

1.2 云计算

一种通过互联网按需提供计算资源（如服务器、存储、数据库、网络等）的服务模式，其核心思想是将计算资源集中管理并池化，用户按需取用，无需自行购置和维护硬件设施。

有一个形象说法用来比喻云计算，像使用水电一样便利的基础设施。

云计算服务模式

术语	全称	中文翻译	核心定义
IaaS	Infrastructure as a Service	基础设施即服务	提供虚拟化的底层计算资源（如服务器、存储、网络），用户可自主管理操作系统、中间件和应用。
PaaS	Platform as a Service	平台即服务	提供开发和部署应用的平台环境（如数据库、运行时环境、开发工具链），用户只需关注代码编写，无需管理底层基础设施。
SaaS	Software as a Service	软件即服务	直接通过互联网提供完整的软件应用，用户无需安装或维护，即开即用。

部署模式

公有云：由第三方服务商提供（如AWS、阿里云），多租户共享资源，适合中小企业和通用业务。
私有云：企业自建或托管，数据本地化存储，满足金融、政务等高安全需求。
混合云：结合公有云和私有云，敏感数据存于私有云，弹性业务部署在公有云（如银行核心系统）。
行业云：针对特定行业（如医疗、教育）定制化服务，满足合规与场景需求。

1.3 原生的含义

"生于云、长于云"的含义。不是简单地将应用迁移到云上，而是从架构设计到开发、部署、运维全流程适配云环境，让应用"生于云、长于云"，最大化释放云计算的潜力

云原生是云计算的下半场

云托管 Cloud Hosting 云计算是传统软件架构的一场革命，云计算通过主机虚拟化实现了主机资源池化，并统一提供云化基础设施服务云托管服务，可以看做是云计算的上半场
云原生 Cloud Native 随着上云的不断深入，企业面临如何更好的利用云的价值，最大意义上发挥云的价值，通过云原生技术实现企业创新和数字化转型，可以看做云计算的下半场。

1.4云原生发展历程

2004-2007 Goolge大规模使用容器技术cgroups，cgroups从实验性技术升级为生产级工具，成为Linux容器核心能力的前身
2008年Cgroups合并进入Linux主核，Linux内核原生支持容器技术，为Docker诞生提供底层支撑
2013年Docker项目发布，首次实现 容器镜像标准化
2014年Google Kubernets项目发布，解决多容器集群管理难题，成为云原生生态基石
2015年Google联合RedHat、微软等成立CNCF云原生基金会成立，Kubernets成为第一个项目推动云原生标准化
2017年Kubernets项目实施标准确立，服务网格技术崛起Likederd发布1.0版本第一代服务网格，Istio发布0.1 版本第二代服务网格。
2018年 CNCF重新定义云原生云原生技术范畴扩展至 容器、服务网格、微服务、不可变基础设施、声明式API 。
2019年 OpenTelemetry 1.0发布统一，整合OpenTracing与OpenCensus，建立统一可观测性标准

2019年后云原生进入深度整合与行业落地阶段，技术栈持续丰富，生态边界不断扩展比如像边缘计算，AI人工智能也逐渐纳入云原生生态。

1.5 云原生定义的变化

技术的发展，云原生的定义也一直在变化，网络上查找的云原生定义也往往有多个不同版本的定义，或者各种不同的说法理解。

2015 Pivotal公司技术产品经理提出了"云原生"（Cloud Native）的概念，在 Matt Stine 所著的《迁移到云原生应用架构》书中，他提出云原生架构应该具备 5 个主要特征。

2015年CNCF（Cloud Native Computing Foundation，云原生计算基金会）成立，对云原生进行了定义 CNCF 对云原生的定义包含以下三个方面：应用容器化：容器化是云原生的基础。面向微服务架构：实施微服务是构建大规模系统的必备要素。应用支持容器的编排调度：编排调度是指能够对容器应用的部署、扩展、运行和生命周期进行自动化管理。

云原生计算基金会（CNCF）是 Linux 基金会旗下的开源软件基金会,致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
目前世界上主流的的云计算厂商都加入了CNCF，谷歌，亚马逊，微软，阿里巴巴，腾讯，华为等等。

2017年10月，Matt Stine，他接受 InfoQ 采访时，对云原生的定义做了小幅调整，更新后的云原生架构特征

2018年，云原生生态不断壮大所有主流云计算供应商都加入了该基金会，CNCF 基金会中的会员以及容纳的项目越来越多，CNCF 为云原生进行了重新定义。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

2019年， VMware Tanzu 收购了 Pivotal，其官网给出了云原生最新定义，以及云原生的架构原则：

4 个要点：DevOps（开发运维）、Continuous Delivery（持续交付）、Microservices（微服务）、Containers（容器化）

2. 云原生技术生态现状

2.1 CNCF全景图

2.2 技术范畴

云应用定义与开发流程

应用定义与镜像制作
配置 CI/CD
消息和 Streaming.
云原生数据库

云应用的编排与管理

应用编排与调度
服务发现治理
远程调用
API网关
Service Mesh服务网络

监控与可观测性

系统监控.
日志管理
链路追踪Tracing
混沌工程

云原生底层技术

容器运行时
云原生存储技术
云原生网络技术

云原生工具集

流程自动化与配置管理
容器镜像仓库
云原生安全技术
云端密码管理

Serverless

函数计算 Faas
后端计算 BaaS
Serverless 计费

3.核心技术

3.1容器

容器是一种虚拟化技术，用于将应用程序及其所有依赖项打包在一起，以便在不同的计算环境中进行移植和运行。容器提供了一种隔离的运行环境，使不同应用程序能够在独立的文件系统、网络和进程空间等独立运行环境中运行，提升了安全性和稳定性。

3.1.1 docker

3.1.1.1 Docker镜像

容器镜像是一个随时可以运行的软件包，包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。

3.1.1.2 容器

镜像创建的运行实例

3.1.1.3 镜像仓库

Docker集中存放镜像文件规定场所，实现Docker镜像全局存储，提供API接口，提供Docker镜像的下载，推送，查询。 docker pull docker push docker search

3.1.1.3 架构

3.1.1.4 Dockerfile

Dockerfile是一个用来构建镜像的文本文件，文本内容包含了一条条构建镜像所需要的指令和说明

bash 复制代码

FROM xxx/library/jdk8-jacoco:1.0.0


ENV PROJECT_DIR=/app
WORKDIR $PROJECT_DIR
VOLUME $PROJECT_DIR/logs

COPY *.jar $PROJECT_DIR/app.jar

ENTRYPOINT exec java ${JAVA_OPTS} -jar app.jar --spring.config.location=application.properties

EXPOSE 9999

3.1.2 容器编排技术(Kubernetes)

Kubeernets(通常简称为K8s）是一款用于自动部署、扩缩和管理容器化应用程序的开源容器编排平台通过容器编排，可以构建跨多个容器的应用服务、跨集群调度容器、扩展这些容器，并持续管理它们的健康状况

3.1.2.1 核心功能

自动化部署：支持根据副本数量，回滚，重启等策略自动部署容器。
服务发现与负载均衡：自动发现增加的容器，并进行流量的负载均衡。
自动化容器恢复：自动对容器进行健康检查，并根据策略进行重启。
弹性伸缩：支持工作节点、容器的自动扩缩容

3.1.2.2 Pod

Kubectnets中能够创建和部署的最小单元，由一个或多个容组成器，提供了存储、网络等各个容器共享的资源和运行环境

3.1.2.3 Volume

Pod中能被多个容器共享的磁盘目录，用来管理Kubernetes存储的，支持多各种后端存储：本地存储、分布式存储、公有云存储等。用来实现数据的持久化。

3.1.2.4 Deployment

Deployment 是 Kubernetes 中管理应用部署的核心工具，通过声明式配置，创建管理更新Pod。

副本管理：确保指定数量的 Pod 副本（Replicas）始终运行。
滚动更新：逐步替换旧 Pod 为新版本，实现零停机部署
版本回滚：记录历史版本，可快速回退到之前的应用状态

3.1.2.5 Service

为动态变化的 Pod 提供稳定的网络访问入口。

服务发现：通过标签选择器（Label Selector）绑定一组 Pod，自动跟踪其 IP 变化。
负载均衡：将请求分发到后端多个 Pod（默认轮询策略）。
抽象网络端点：提供固定虚拟 IP（ClusterIP）或外部可访问地址（NodePort/LoadBalancer）

3.1.2.6 ConfigMap

是一种用于将（如环境变量、配置文件）与容器镜像解耦的抽象资源，使得应用配置可动态管理且无需重新构建镜像

3.1.2.7 Namespace

是用于在集群内划分逻辑隔离区域的核心抽象，允许将资源（如 Pod、Service、Deployment）分组管理，实现多团队、多环境或多项目的资源隔离与权限控制

3.1.2.8 架构

外部系统（External Systems）：用户或工具（如 kubectl、CI/CD 流水线）通过 Kubernetes API 与集群交互。
Kubernetes 集群（Kubernetes Cluster）：分为控制平面（Control Plane）和工作节点（Worker Node），共同管理容器化应用。

3.1.2.8.1 控制平面（Control Plane）

集群的大脑，负责管理所有的节点，负责调度Pod在哪些节点上运行，负责控制集群运行过程中的所有集群状态

kube-apiserver,集群的控制入口，提供RESTful API，接受来自kubectl、CI/DI系统或其他客户端请求
etcd 分布式kv数据库，存储集群所有资源如Pod、Service 、ConfigMap等配置和实时状态
kube-scheduler 集群Pod资源对象的调度服务，主负责监听新创建的、未指定运行节点的Pods，scheduler会依据一系列调度原则，将所发现的每一个未调度的Pod调度到一个合适的节点上来运行。
kube-controller-manager 控制器管理器是一个守护进程，连续运行并实时监视对象的实际和期望状态。如果实际状态和期望状态存在差异，则确保 Kubernetes 资源/对象处于期望状态。
cloud-controller-manager 专门用于集成云服务商的基础设施能力，使 Kubernetes 能够与不同云平台（如 AWS、Azure、GCP、阿里云等）的 API 交互。比如自动创建云存储挂载到POd，自动申请云厂商负载均衡器用来暴漏公网地址等。

3.1.2.8.2 工作节点（Worker Node）

负责管理所有的容器，负责监控/上报所有Pod的运行状态，

kubelet组件负责管理节点上容器的创建、删除、启停等任务，与控制平面进行交互
kube-proxy，负责节点服务的通信以及负载均衡、流量转发
container runtime 负责从 Registry 中拉取镜像、运行容器、分配和隔离容器资源，以及管理主机上容器的整个生命周期。接受kubelte组件的指令。

3.1.2.8.3 典型使用流程

通过kubectl命令执行创建kubectl apply -f rs.yaml创建pod时，经历的流程如上图，大概流程为
apiserver接收kubectl的创建资源的请求
apiserver将创建请求写入ECTD
apiserver接收到etcd的回调事件
apiserver将回调事件发送给ControllerManager
controllerManager中的ReplicationController处理本次请求，创建RS，然后它会调控RS中的Pod的副本数量处于期望值，比期望值小就新创建Pod，于是它告诉ApiServer要创建Pod
apiserver将创建pod的请求写入etcd集群
apiserver接收etcd的创建pod的回调事件
apiserver将创建pod的回调事件发送给scheduler，由它为pod挑选一个合适的宿主node
scheduler告诉apiserver，这个pod可以调度到哪个node上
apiserver将scheduler告诉他的事件写入etcd
apiserver接收到etcd的回调，将更新pod的事件发送给对应node上的kubelet进程
kubelet通过CRI接口同容器运行时（Docker）交互，维护更新对应的容器

3.2 微服务

微服务是一种架构风格，将应用拆分为多个独立的小服务，每个服务运行在自己的进程中，通过轻量级机制通信。这些服务围绕业务能力构建，可独立部署，使用不同的编程语言和数据存储技术

3.2.1 微服务的设计思想

微服务架构 本质上是高内聚低耦合设计思想在分布式系统中的具体实践， 内聚性（Cohesion）指的是模块内部各个元素之间的关联程度。高内聚意味着模块内的各个部分紧密相关，共同完成一个明确的任务或功能。耦合性（Coupling）则是指不同模块之间的依赖关系。低耦合意味着模块之间相互独立，修改一个模块不会或很少影响到其他模块。

为什么说高内聚低耦合是好的设计。高内聚让模块职责单一，易于理解和维护，因为每个模块专注于一个功能点。低耦合减少了模块间的依赖，提高了系统的可维护性和可扩展性。当需要修改某个功能时，只需关注特定的模块，而不必担心连锁反应。

3.2.1 微服务和云原生

微服务与云原生的结合是现代分布式系统最佳实践，二者通过 互补的技术栈 和 协同的设计理念 ，共同构建出规模化、弹性、可扩展且高效的应用架构

容器化微服务：通过将每个服务打包为容器镜像，实现服务的可移植性和可复用性。这样可以在任何地方以相同的方式运行服务，提高了部署的效率和灵活性。
自动化部署：通过自动化部署工具（如持续集成/持续交付工具），实现服务的自动化构建、测试和部署。这样可以加快迭代速度和降低人工错误率。
弹性扩展：根据需求自动扩展或缩减服务的资源，以保持应用程序的高可用性和性能。这样可以应对高峰期的流量和负载，提高应用的可用性和响应速度
服务治理和监控：建立完善的服务治理和监控机制，实现对服务的实时监控和管理。这样可以及时发现和解决问题，保证应用程序的稳定性和可靠性。

3.3 不可变基础设施

不可变基础设施是一种保持基础设施实例不可修改，只能够进行整体替换的模式。任何基础设施实例（包括服务器、操作系统、软件等）一旦创建之后便进入只读状态。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换。

这里可以用宠物（Pets）牲畜（Cattle）的概念做类比：

在传统数据中心内，服务器被视为"宠物"：一台物理计算机，被赋予有意义的名称，并受到照料。通过将更多资源添加到相同计算机（纵向扩展）来进行缩放。如果服务器出现问题，你会进行修复，使它恢复正常运行状况。如果服务器不可用，则每个人都会感知到。

牲畜服务模型有所不同：你会将每个实例预配为虚拟机或容器。它们是相同的，并分配有系统标识符（如服务-01、服务-02等等）。通过创建更多实例（横向扩展）来进行缩放。当一个实例不可用时，无人会感知到。

牲畜模型采用不可变基础结构。服务器不会进行修复或修改。如果一台服务器发生故障或需要更新，则会销毁它并预配新服务器，所有操作都通过自动化完成。

云原生系统采用牲畜服务模型。它们会在基础结构横向缩减或扩展时持续运行，而不考虑运行它们的计算机。

3.4 声明式API

声明式设计是指一种软件设计理念："我们描述一个事物的目标状态，而非达成目标状态的流程"。至于目标状态如何达成，则由相应的工具在其内部实现。

命令式 API：可直接发出让服务器执行的命令，例如："运行容器"、"停止容器"等；
声明式 API：可声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。

声明式使系统更加健壮。声明式API描述最终运行环境的状态，由系统来决定如何来创建这个环境。例如，你的描述就变成"创建一个有三个Nginx的集群"，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。

Kubernetes的API就是一种声明式API。Kubernetes中，所有应用的部署都是基于YAML文件的，这实际上就是一种Infrastructure as Code，可支持通过代码来管理基础设施和部署环境。

3.5 可观测性

可观测性是指系统的内部状态能够通过外部输出（如日志、指标、追踪等）来进行观察和理解的能力。换句话说，系统的可观测性使得我们能够从系统的外部获取足够的信息，以便分析和解决可能存在的问题，预测系统行为，或者优化系统性能。
可观测性与监控的关系监控告诉我们系统哪些部分是正常的，可观测性告诉我们系统为什么不正常了。 ------by《高性能 MySQL》作者 Baron Schwartz

监控是针对已知风险，提前定义好要监控的指标（如CPU、错误率）。一旦异常就告警。可观测性是应对未知问题，通过系统产生的数据（日志、指标、追踪），动态分析问题的根源，即使这个问题从未出现过。

业界将系统输出的数据总结为三种独立的类型

指标数据（Metrics）指标通常指系统性能相关的可量化数据，如 CPU 使用率、内存占用、网络带宽利用率、数据库查询速率、服务响应时间等。这些实时或周期性收集的数据可用于监控系统性能、资源利用率、容量规划、系统可用性。
链路数据（Tracing）记录请求在多个服务之间的"调用链路"（Trace），以"追踪树"（Trace Tree）的形式呈现请求的"调用"（span）、耗时分布等信息，形成完整的请求链路视图，便于深入理解跨服务边界的服务交互性能和问题定位。

less 复制代码

Trace ID: 12345
└── Span ID: 1 - API Gateway (Duration: 50ms)
    └── Span ID: 2 - User Service (Duration: 30ms)
        └── Span ID: 3 - Database Service (Duration: 20ms)

日志数据（Logging）日志是系统在运行过程中生成的记录信息，包括错误消息、警告、调试信息及用户操作事件等。通过对日志进行收集、存储、搜索和分析，运维人员能够了解系统的执行历史、发现异常情况并诊断问题。

vbnet 复制代码

[2024-12-27 14:35:22] ERROR: Failed to connect to database. Retry attempts exceeded.

上述 3 类数据各自侧重不同，但并非孤立存在，它们之间有着天然的交集与互补。比如指标监控（告警）帮助发现问题，日志和链路追踪则帮助定位根本原因韦恩图如下。

Tracing + Metrics（左重叠区）：链路数据关联与诊断：在追踪链路中嵌入指标（如数据库查询耗时），结合 RED（Request Rate, Error Rate, Duration）方法定位性能拐点。
Tracing + Logging（右重叠区）：全息排查：通过 Trace ID 串联日志（如错误堆栈）与追踪链路，实现上下文关联分析。
Metrics + Logging（下重叠区）：统一监控大盘：在仪表盘中同时展示指标趋势与关键日志摘要（如错误频次）。
三者交集（中心区）：全链路通路：构建端到端可观测性，结合追踪、指标、日志实现立体化监控。

开源系统

2019年OpenTelemetry合并OpenTracing 和 OpenCensus 成为标准采集解决方案，同时支持指标、追踪和日志等各类遥测数据，遥测数据采集后如何存储、展示、使用，OpenTelemetry 并不涉及。可以使用 Prometheus + Grafana 做指标的存储和展示，也可以使用 Jaeger 做链路追踪的存储和展示

3.6 服务网格

服务网格是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。

处理服务通讯的基础设施层
保证服务间的请求的可靠传递。实施微服务架构，解决服务注册、服务发现、负载均衡、熔断、限流等问题的本质是保证服务间请求的可靠传递
有一组和服务部署在一起的轻量级网络代理

服务网格将非业务功能服务通讯治理逻辑（服务注册、服务发现、负载均衡、熔断、限流）从服务中剥离。

3.6.1 ISTIO

服务发现与配置分发：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理；
流量管理：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能；
安全管理：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信、基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限；
可观测性支持：协助 Envoy 采集系统输出的遥测数据（日志、指标、追踪），并将数据发送到外部监控系统（如 Prometheus、Jaeger、OpenTelemetry 等）；
配置验证与管理：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性；

3.6.1.1 架构

3.6.1.2 控制平面

控制和管理数据平面中的 Sidecar 代理，完成配置分发、服务发现、流量路由、授权鉴权等功能，以达到对数据平面的统一管理

3.6.1.2 数据平面

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

3.7 serverless

Serverless 是一种云计算模型，开发者无需管理服务器基础设施，按需编写和部署代码，由云平台自动处理资源调度、扩缩容和运维。其核心思想是将基础设施抽象化，让开发者专注于业务逻辑而非底层运维

术语	全称	中文翻译	核心定义
FaaS	Function as a Service	函数即服务	开发者编写无状态函数（事件触发的代码片段），由云平台动态调度资源执行，无需管理服务器或运行时环境。
BaaS	Backend as a Service	后端即服务	提供托管的后端服务（如数据库、身份认证、文件存储），开发者通过API/SDK直接调用，无需自建基础设施。

3.8 DevOps

DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

研发和运维之间不再是对立的关系，应该是互相协作、深度交流并且彼此体谅的状态。
开发流程方面，以往研发和运维各搞各的模式也需要改变：运维需要在项目开发的初始阶段提前介入，了解开发所使用的系统架构和技术路线，并制定好相关的运维方案。开发人员也需要参与到后期的系统部署和日常维护中，并提供优化建议。不仅仅是把代码甩给运维了事。

DevOps 的成功实践离不开工具上的支持，这其中包括最重要的自动化 CI/CD 流水线，通过自动化的方式打通软件从构建、测试到部署发布的整个流程。还有实时监控、事件管理、配置管理、协作平台等一系列工具/系统的配合下图循环迭代的视角系统化呈现了 DevOps 的核心流程与关键技术支撑八大阶段

PLAN（计划）
CODE（编码）
BUILD（构建）
TEST（测试）
DEPLOY（部署）
RELEASE（发布）
OPERATE（运维）
MONITOR（监控）