云原生 on 冯威的博客

云原生：一文读懂核心技术栈与演进路径

Tue, 24 Jun 2025 14:36:00 +0800

最近，听老板说只要碰到一些大型项目，客户都要求使用云原生技术，让我们在技术储备上也要能跟得上。本文简单讲讲云原生的技术栈以及如何学习。

云原生（Cloud Native）近些年一直都是软件开发领域的热门话题之一。

什么是云原生？

云原生是一种设计和运行软件的方法论，核心思想是充分利用云平台提供的弹性、自动化和按需付费等特性，让应用更易于开发、部署和运维。关于云原生的概念，可以看看《简单聊聊云原生》。

很多人会问：我单体应用用得好好的，为什么要转向云原生这么复杂的架构呢？实际上，每一种新技术的出现都是为了解决已有问题，但同时也会引入新的挑战，权衡之下，如果利大于弊，就会采用。

下面我们来一步步分析，看看云原生技术是如何演变而来的。

云原生包含哪些技术栈？

目前主流的云原生技术栈（以 Pivotal 和 CNCF 技术栈为基础）包括：

微服务（Microservices）
容器（Containers，如 Docker）
容器编排（Container Orchestration，如 Kubernetes）
服务网格（Service Mesh）
声明式 API（Declarative API）
不可变基础设施（Immutable Infrastructure）
持续集成和持续交付（CI/CD）
DevOps
无服务器架构（Serverless）

企业为什么需要云原生？

对企业来说，降本增效非常重要，面对复杂的系统，使用云原生技术可以达到这个目的。

降低成本：通过容器技术，能提高资源利用率，降低整体成本。
提升效率：云原生架构下的部署更快速、更灵活，明显提升开发和交付效率。
提高业务承载力：云原生能快速扩容，应对高并发业务需求。
提升稳定性：健康检查和不可变基础设施让系统更稳定、更可靠。

云原生技术栈是如何演变的？

1、微服务

1967 年，计算机科学家梅尔文·康威（Melvin Conway）提出过一个观点：

组织的设计（包括其沟通结构和团队划分）会影响其生产的系统架构。具体来说，软件的架构往往反映了组织的沟通结构。

这就是著名的康威定律。

最初，软件往往是以单体应用的方式存在。当系统规模和业务复杂度增加时，组织就可能进行拆分，每一个小团队负责一个模块，这些团队甚至可能是分布式的。

组织的变化必然会让单体应用慢慢向微服务进行转变。不变不行啊，不然沟通成本太高了。

如果组织没有发生变化，强行去进行微服务拆分，会发现代码的管理、维护会变得复杂（即便是用上自动化工具），所以说有什么样的组织就有什么样的架构。

微服务将应用拆分成多个小而独立的服务，每个服务可以独立开发、部署、扩展，从而大大提高了灵活性和可维护性。但随之也出现了服务间通信复杂、部署管理困难等问题。

之前写的几篇微服务相关的文章：

《微服务：我们需要从单体转到微服务吗？》
《微服务：事务管理》
《微服务：如何拆分服务》
《微服务：服务间通信概述》

2、容器化（Docker）

微服务早在 2011 年就被提出，但近些年才火起来，靠的就是容器技术的普及。

微服务越来越多，手动部署变得异常复杂。Docker 这类容器技术的出现，使发布的程序和依赖的中间件能被封装到容器中，极大地简化了部署过程。

开发人员无需关注底层环境，容器的运行环境高度一致。在这之前，经常会有一些莫名其妙的问题，最后的原因就是各种环境配置的不一致。

然而，随着系统变得复杂，服务拆分的多，还要上各种中间件，容器数量就会越来越多，就会带来容器管理的问题，单靠 Docker 已经无法应对。

3、容器编排（Kubernetes）

容器编排技术随着容器化应用规模的扩大而诞生，主要是为了解决容器在生产环境中批量运行和管理的复杂性问题。最初，Docker 可以很好地处理单个或少量服务，但随着企业应用转向微服务架构，管理大量容器变得困难，仅仅靠人工的方式肯定会错漏百出。

为了解决这些问题，出现了容器编排技术，简单的有 docker compose ，测试环境和要求不高的生产环境中经常会用到。功能强大的有 Kubernetes ，提供自动部署、服务发现、负载均衡、健康检查、自动扩缩容等功能。

不过，容器编排技术的引入也会带来新的问题，包括系统复杂性提升、配置管理繁琐和安全性挑战。为应对这些问题，逐渐发展出了新工具，如 Helm、Rancher、OpenShift、Istio、Prometheus、Grafana 等。

4、服务网格（Service Mesh）

随着微服务规模扩大，服务间通信的管理要求变得更高，仅依靠 Kubernetes 等容器编排平台难以全面、高效地实现服务通信治理功能，就需要服务网格出场了。

服务网格（Service Mesh）是服务间通信的基础设施层。

它通过在微服务之间注入轻量级网络代理，统一处理服务发现、负载均衡、安全认证、流量控制、故障恢复等功能，非侵入式地解耦服务治理与业务逻辑。

到这可以发现，技术的演进都有相似性，本质上都是为了将通用能力从核心业务中剥离出来，通过更抽象、更统一的方式进行管理与复用。这种思路在软件开发的多个阶段中屡见不鲜。比如：

在架构阶段，API 网关将认证、限流、协议转换等边缘治理能力集中处理、配置中心实现了配置的集中化、动态化管理。
在编码阶段，我们引入了 AOP（面向切面编程）来将日志、事务、安全等横切关注点独立出来，实现与业务逻辑的解耦、通过工具类或SDK封装公共逻辑，提高复用性。

Istio 是目前比较火的一个开源服务网格，大概逻辑就是每个服务会被注入一个 Sidecar 组件，服务之间的通信会先经过 Sidecar，然后 Sidecar 再将请求转发给另一个服务。因为请求都经过Sidecar，所以可以通过 Sidecar 实现很多通用功能。

5、持续集成与持续交付（CI/CD）

服务变多，引入了更多的技术，系统变得更复杂了，就需要更多的手段来进行效率和稳定性的提升。

CI/CD 技术通过自动化的方式完成代码检查、测试、构建、部署任务。自动化不仅减少了人工操作带来的失误，也提升了迭代速度与产品质量。

CI 是持续集成，CD 有两层含义（持续交付和持续部署）。

持续集成：代码合并到特定分支的过程，这中间有静态扫描、单元测试等。
持续交付：将构建后的产物发布到测试环境，预生产环境。
持续部署：将经过充分测试的代码自动部署到生产环境。

CI/CD 可以让我们避免重复操作，提前发现问题，减少人工错误，让系统更加稳定。

简单聊聊云原生

Tue, 19 Mar 2024 08:48:37 +0800

云原生，作为一种新兴的软件架构模式，目的在推动应用程序的敏捷开发、快速部署和可靠运行。虽然这一概念已经提出多年，但直至最近几年，云原生才逐渐引起了华中区客户的广泛关注和认知（不一定准确，从我的感觉和经验来看是这样的）。

本文结合我收集整理的资料、以及我的理解，来看看云原生是怎么回事？

概念

要搞清一个技术，先从概念开始，跟云原生这个概念有关的主要有两个组织：Pivotal 和 CNCF 。

Pivotal：Pivotal 成立于 2013 年 4 月，由 EMC、VMware 和 GE 投资成立，专注于帮助企业在数字化时代变革所需的 PaaS 云计算、大数据基础平台和平台上的极限编程。
CNCF：CNCF（Cloud Native Computing Foundation，云原生计算基金会）是 Linux 基金会旗下的基金会，可以理解为一个非盈利组织，成立于 2015 年 12 月 11 日。

2015 年，来自 Pivotal 公司的技术产品经理 Matt Stine，首次提出了云原生的概念，认为云原生架构必须包含下面一些特性：

符合十二要素、微服务、敏捷基础设施、基于 API 的协作、抗压性

2017 年，Matt Stine 在接受 InfoQ 采访时，将云原生特性做了些调整：

模块化、可观测性、可部署性、可测试性、可处理性、可替换性

而现在的云原生涉及到的一些关键词有，原文可以参考：https://tanzu.vmware.com/cloud-native：

微服务、DevOps、容器、服务网格、CI/CD、Serverless

可见，云原生的定义是在不断演进的，不断会有新的东西加入。

再来看看 CNCF 的官方最早是怎么定义的：

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization.

云原生使用一种开源软件技术栈来部署微服务应用，将每个组件打包到它自己的容器中，并且通过动态编排来优化资源的利用率。

2018 年，CNCF 推出了对云原生定义的 v1.0 版本，地址如下：

https://github.com/cncf/toc/blob/main/DEFINITION.md

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

云计算和云原生的关系

早些年，传统的企业软件开发是部署在企业的内部物理机中，为了让一个系统能正常运行，通常需要很多的机器，数据库、中间件、程序的前后端都需要进行单独部署。

后来有了虚拟化技术，通过在各种实体资源（CPU、内存、网络、存储等）之上构建一个逻辑层，从而摆脱物理限制的约束，提高物理资源的利用率。最直观的感受就是可以在一台物理机上快速运行多个虚拟机、意味着可以降低物理机的数量，节约成本。

虚拟技术的成熟促成了云计算的出现。2006 年 Google 首次提出了云计算的概念。云计算出现之后，就慢慢出现了 XaaS ：

IaaS（基础设施即服务）：一种云计算服务类型，它按即用即付的方式按需提供必要的计算、存储和网络资源。这种服务模式帮助客户降低维护成本和硬件成本。
PaaS（平台即服务）：云计算服务模式之一，它为开发人员提供了包括一系列开发工具、服务、应用程序接口（API）等资源的平台。它的目标是让开发者能够更快速、高效地构建、发布、扩展和维护应用，同时云服务商负责管理和提供开发环境。
aPaaS（应用平台即服务）：是一类特定的 PaaS，重点在于为应用程序提供更快捷的构建服务，例如低代码能力。通常包括通过可视化操作减少原生代码使用、高效的数据处理、模块化的功能实现等，目的是为了让开发者更高效地搭建、运行、维护和扩展应用。
DaaS（数据即服务）：将数据从静态资源转变为一种可通过网络获取的即时服务。用户可以方便地访问和使用数据，无需关心数据存储和管理的底层细节。数据通过平台进行集中化管理，提供规范化、标准化的数据访问和数据处理流程。
FaaS（函数即服务）：是一种基于事件驱动的无服务器执行模式，在这种模式中，开发人员无需关心服务器的管理和维护，只需编写并上传业务函数代码。当触发特定事件时，这些代码由云服务商在全托管的环境中执行。
SaaS（软件即服务）：一种云计算模式，在这种模式中，软件通常以网络浏览器的形式提供给用户。用户不需要在本地机器上安装或维护软件，所有的应用程序和数据库都位于云端的数据中心。这减少了用户在软件和硬件方面的投入和维护工作。

云计算的兴起，一些企业将软件逐渐迁移到公有云，无需再关心网络、存储、服务器等，这些都由云厂商的 IaaS、PaaS 能力提供。