【顶层思维】云原生概念辨析
开一个系列用于记录一些值得学习的大技术方向/架构/概念等，暂且就叫【顶层思维】，“高屋建瓴”之类的太中二了。
什么是云原生，硬看概念的话再久也搞不明白，不如从它的一些重要子概念开始看起，云原生和“非云原生”的区别在哪里，这样才能有更具象的理解。看了一些大佬的讲解，先记录一下自己比较粗浅的理解，估计也有很多错的。
微服务 vs 单体应用
与传统的大型单体应用相比，微服务将应用拆解为更小的、独立的组件或模块。这种拆分是纵向的，从底层的 IT 基础设施、数据库、应用中间件，到软件程序部署包，各个部分都是完全独立的，可以分别进行需求设计、开发、打包和部署。通过这种方式，微服务实现了松耦合，各微服务之间通过 RPC 等轻量级的通信接口进行交互。
DevOps
DevOps 的核心理念是自动化软件交付，涵盖从需求分析、设计开发、编译构建、打包部署到测试环境与生产环境的整个软件生命周期。其中的关键实践包括：
- 持续集成（Continuous Integration, CI）：频繁地将代码变更集成到主分支。
- 持续交付（Continuous Delivery, CD）：确保软件可以随时部署到生产环境。
- 自动化测试：通过自动化测试流程来确保代码质量。
容器云
容器云包含两个核心概念：容器（如 Docker）和容器资源调度与编排（如 Kubernetes）。容器相比虚拟机是一种更轻量化的资源隔离单位，具有体积小、创建和销毁速度快的优势。容器化是一种 IaaS 层面的技术，结合容器编排技术，可以将服务提升到 PaaS 层级。
服务网格 vs ESB 总线/API 网关
在服务治理方面，传统的 ESB 总线或 API 网关采用的是中心化架构，所有流量都通过 API 网关进行，这样可以方便地对流量进行拦截，实现日志记录、监控和限流等治理能力。而在云原生架构中，采用去中心化架构，不再有集中的流量管控点，流量的拦截能力下放到各个微服务中。常见的实践是在微服务端增加一个代理，通过代理实现对流量的拦截与管控。服务网格技术正是基于这种思路，如 Istio 框架通过在每个微服务端注入 Envoy 边车代理，实现流量的拦截与治理。需要注意的是，去中心化的微服务治理仍然有一个中心化的控制平面，用于服务的注册发现等功能，而数据平面则负责实际的流量转发和接口调用，这样即使控制平面出现故障，也不会影响微服务间的通信。
Serverless
云原生架构的核心是将资源到服务不断地向上抽象。在这个过程中，你会发现逐渐脱离了底层 IT 基础设施，而只需关注各种技术服务能力。这种抽象带来了 Serverless（无服务器）架构，用户无需接触底层基础设施，实现真正的无服务器化。在 Serverless 架构中，技术服务能力被称为 BaaS（后端即服务）。在传统的 PaaS 架构下开发应用，仍然需要选择开发框架和底层平台，涉及多层架构，如数据层、逻辑层和展现层。而在 Serverless 开发流程中，你只需关注功能核心，即通过代码片段的组装实现复杂的业务逻辑，对应于 Serverless 的 FaaS（函数即服务）层。
总的来说，Serverless 架构包含两层：BaaS 和 FaaS。BaaS 将后端服务（如对象存储、消息队列等）抽象成 API 接口，开发者只需编写函数代码即可完成 FaaS 层的应用程序开发。
不可变基础设施
在传统开发流程中，完成软件部署后，如果需要变更，无论是程序还是配置，通常会在原有的生产环境上进行修改或重新部署。而云原生强调，不可变基础设施理念，即一旦应用被部署到生产环境，生成的容器实例不应再做任何改动。如果需要变更，应该基于新的配置重新生成一个新的容器实例，同时销毁旧的实例。不同环境之间的迁移也应基于相同的容器镜像，而非重新编译构建。
声明式 API vs 命令式 API
在传统方式下，创建或操作一个容器通常是通过命令行工具（如 kubectl）进行。而声明式 API 是通过编写配置文件，在其中声明所需操作及期望的最终状态。平台接收到配置文件后，会自动解析并执行相应操作，将底层资源调整到声明的状态。使用声明式 API 有助于快速追溯操作历史，实现回退或回滚。