云原生名词解释
DevOps
这个词中间不应该有空格，意为 Development+Operations，开发 + 运维。
开发（Dev）写完代码 → 扔给运维（Ops）部署 → 出问题互相甩锅
这个词应该是描述公司中，团队协作的一种模式，一种组织文化，解决开发运维的协作问题，它不是一个具体的工具。
它的目标是：
CI/CD
Continuous Integration/Continuous Deployment
持续集成、持续交付
CI 用于开发者每次提交后，自动触发脚本，运行测试套件，验证代码质量
CD 用于当代码通过所有测试后，自动触发部署脚本，发布到部署环境，避免需要一次次的单独部署
开发者从“部署恐惧”到“随时交付价值”
GitOps
以 Git 仓库为单一事实来源，集群状态自动收敛到仓库中描述的状态
可以认为 GitOps 是 DevOps 的一个具体实现
它提出三个具体规则：
1、声明式配置（我要什么，而不是我会怎么做）
2、Git 是唯一入口（修改集群状态，通过提交 PR 来改，靠 git log 审计）
3、自动同步（Git 仓库变化，监视者自动触发流程）
Github Actions/Gitlab CI
这种部署模式是 CI pipeline，而不是 GitOps，
git push -> CI 构建镜像 -> CI 直接把镜像推到生产环境部署
GitOps 是 pull 模式
git push -> CI 构建镜像 -> CI 更新部署仓库的 yaml -> ArgoCD/Flux 在集群里看到 Git 变了 → 自己拉取并 apply
所以 GitOps 的关键是 集群自己拉取，更复杂
GitHub Actions 是团队实现 DevOps 的工具之一，但不是决定性因素（不是使用这些工具，就自动变成 DevOps 了）
任何需要人 SSH 上去做的事情，都是 DevOps 没做到位的标志
云计算服务模型
XaaS 的意思是 as a Service“即服务”
本质是指，云服务器厂商，如何给你提供服务
IaaS Infrastructure（基础设施即服务）
基础设施即服务，就类似于 AWS EC2 这种。直接给你一个虚拟机，里面的程序，环境，文件都需要用户自己去管理、搭建
PaaS Platform（平台即服务）
严格意义上的平台即服务我没用过
就是说云服务器厂家提供 操作系统，运行环境。用户甚至只需要提供代码即可。
这种说是一般是绑定特定框架，然后才能一键部署。
SaaS Software（软件即服务）
呃，这个和开发都没关系了，云服务器厂家直接提供好服务。
比如 GMail
Colab【Google Colab（Colaboratory）】更贴近 SaaS（Software as a Service）。
类似 Gmail：你使用它，但不"拥有"或"配置"平台。
CaaS Container 容器即服务
专注容器技术，比如 GKE Google Kubernetes Engine
通常被归类为 PaaS 的一个子集或特定形式，但它更聚焦于容器技术，比传统 PaaS 更“轻量级”和灵活
FaaS Function 函数即服务
目标是，让用户只需要写一个函数，平台提供所有的运行环境，每次函数运行，就收费
适用场景：构建 Restful 后端 API
云原生
它是一大堆指标的综合评定
https://www.cncf.io/reports/ 云原生计算组织，背后是一大堆巨头公司推动
微服务
微服务就是说把一个大型软件拆解为各个小功能，这个很好理解
但是为什么要这样做？主要是公司团队规模大了以后，团队之间协作出现问题，git 冲突太高，模块之间依赖深导致的，所以需要拆解
现代微服务架构几乎等同于 云原生架构，而容器和编排是其基石
微服务的关键特征包括：
围绕业务能力组织（而非技术层级），这是团队分工的基础。
独立部署：每个服务可以不依赖其他服务单独编译、打包、部署和重启。
技术异构性：不同服务可以用不同语言、框架、数据库（尽管需谨慎）。
去中心化治理和数据管理
康威定律 Conway's Law)
马尔文·康威1967 年提出的：
"设计系统的架构受制于产生这些设计的组织的沟通结构。"
康威定律指出了软件架构与软件团队架构的等价（congruent）
DFS 分布式文件系统
DFS Distributed File System 分布式文件系统
目标是将物理上分散在多台机器上的存储资源整合成一个逻辑统一的文件系统
| 系统 | 开发者/组织 | 特点 | 适用场景 |
|---|---|---|---|
| HDFS | Apache Hadoop | 高吞吐、一次写多次读、强一致性 | 大数据批处理（如 MapReduce） |
| CephFS | Ceph | 支持 POSIX、高可扩展、使用 CRUSH 算法 | 通用存储、云平台 |
| GlusterFS | Red Hat | 无中心架构、弹性哈希、支持 NFS/CIFS | 虚拟化、媒体存储 |
| Lustre | Intel/HPE | 高性能、并行 I/O | 高性能计算（HPC） |
| MooseFS / MinIO / JuiceFS | 开源社区 | 轻量、云原生、S3 兼容等 | 云原生、对象存储网关等 |
| RustFS | 实验性的 |
这些文件系统，最后决定存储文件的时候，可以借助于操作系统已有的单机文件系统，也可以自己管理磁盘
Hadoop
（2025）似乎是 10 年前开始火的技术
MapReduce 是 Google 的 GFS 和 MapReduce 论文中提出的编程模型
Hadoop 实现了这个模型，现在交给 Apache 基金会管理
Hadoop 下面有几个组件：
HDFS：分布式文件系统
MapReduce：Hadoop 原生支持的分布式计算模型
YARN：资源管理和作业调度框架，支持多个计算框架，不只是 MapReduce
Spark：对 MapReduce 的改进，也是一个分布式计算框架
- Hadoop = HDFS（存储） + MapReduce（计算） + YARN（资源管理）
- MapReduce 是 Hadoop 1.x 的默认计算引擎，简单但效率低。
- Spark 是更现代、高效的计算引擎，可独立使用，也可与 Hadoop 生态集成（如读 HDFS、跑在 YARN 上）
消息队列
Apache Kafka 是一个高吞吐、低延迟、可持久化的分布式发布 - 订阅消息系，解耦数据生产者与消费者
Kafka 管理数据如何进来和流动
HDFS 管理存储
Spark 管理如何计算，可以直接消费 Kafka
| 项目 | MQTT | RabbitMQ | Apache Kafka |
|---|---|---|---|
| 本质 | 通信协议（定义设备如何通信） | 消息队列中间件（实现消息的存储、路由、投递） | 分布式流处理平台（高吞吐日志/事件流） |
| 角色 | 规定了客户端 ↔ Broker 之间的交互格式（类似 HTTP） | 一个可以部署的软件系统（如服务器） | 一个可部署的分布式系统（含 Producer/Consumer/Broker） |
| 是否自带 Broker？ | 协议本身不包含 Broker 实现，但依赖 Broker（如 Mosquitto, EMQX） | 自带完整的消息代理（Broker）功能 | 自带分布式 Broker 集群 |
MQTT 是“语言”，RabbitMQ/Kafka 是“邮局 + 仓库”。MQTT 客户端要通过支持该协议的 Broker（如 EMQX）才能工作。
MPI HPC PVM
MPI 是 Message Passing Interface 的缩写
用于解决进程之间通信的问题，提供作业调度，故障恢复
目前常见的有：
OpenMPI （linux）
Intel MPI (linux)
Microsoft MPI (windows)
MPI 主要应用于 HPC 领域
HPC 是 High performance calculate 高性能计算
目前 95% 的高性能计算都是 linux
并且很多是开始做机器学习相关任务
HPC 有一点点指所谓的计算中心的意思，比如太湖之光
PVM Parallel Virtual Machine，并行虚拟机
一种并行计算框架，是 MPI 的前身，现在似乎已经较少使用了