云原生：一文读懂核心技术栈与演进路径
云原生：一文读懂核心技术栈与演进路径
目录
6、不可变基础设施（Immutable Infrastructure）
最近，听老板说只要碰到一些大型项目，客户都要求使用云原生技术，让我们在技术储备上也要能跟得上。本文简单讲讲云原生的技术栈以及如何学习。
云原生（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 可以让我们避免重复操作，提前发现问题，减少人工错误，让系统更加稳定。
6、不可变基础设施（Immutable Infrastructure）
基础设施指的是程序运行所依赖的服务器、网络、存储、中间件等。
有不可变肯定就有可变，那可变是什么意思呢？
程序发布通常有开发环境、测试环境、生产环境，在这些环境中，手动安装服务器系统，然后安装依赖的中间件，后续可能因为各种原因导致每个环境中都手动去修改配置参数、打升级补丁。
时间一长，每个环境会变得有差异，这就是可变的意思。
所以，不可变基础设施（Immutable Infrastructure）是一种运维理念：一旦某个环境实例（如一台虚拟机或容器）被创建并部署应用，就进入只读状态，后续所有“修改”都不是在原有实例上直接进行，而是通过生成、测试并替换成全新实例来完成。这样，每个实例在其生命周期内都是不被更改的。
这就是为什么在 docker compose 或 k8s 中进行程序更新时，都是旧容器先被删除，然后重新构建新的容器。
7、声明式 API（Declarative API）
这里所说的 API 不是 WebAPI 。
和声明式对应的是命令式，先来看一段命令式 API 的 js 代码：
const div = document.createElement('div');
div.innerText = 'Hello, world!';
div.style.color = 'blue';
document.body.appendChild(div);
这个就是告诉浏览器要创建一个 div 元素，并设置文本和颜色，并添加到页面中，每一步都是在说要怎么做。
声明式 API 强调“做什么”，而不是“如何做” 。
比如 docker compose 的 yml 文件就是声明式的，我们只需要在 yml 文件中定义我们要做什么就行，具体容器怎么创建由系统搞定。
version: '3'
services:
web:
image: nginx:latest
ports:
- "80:80"
上面的代码表示需要一个名叫 web 的服务，基于 nginx:latest 镜像，并将容器的 80 端口映射到主机的 80 端口。
声明式 API 的出现是为了解决传统命令式 API 在复杂系统中的问题：命令式 API 需要详细描述所有步骤，容易出错且难以维护，系统状态难以追踪和还原。
声明式 API 通过专注于目标而非过程，提供了简洁清晰的接口，具备自愈能力——当系统状态偏离预期时能自动纠正，同时易于维护、扩展和回滚，特别适合自动化和 DevOps 场景。
最后
云原生涉及的知识非常庞杂，先要从宏观层面了解不同技术之间的关系，还要能搞懂各种具体的技术细节。
拿微服务来说，我们可以去看《微服务架构设计模式》学习架构设计，但具体到代码层面，就需要学习 Spring Cloud Alibaba 之类的微服务框架进行代码实践。
希望本文对您有所帮助！
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
0
0- 0
已为社区贡献29条内容
所有评论(0)