@CivAx 说得不错，不过用 HostPath 这些是不常见的，除非是小集群。
像很多传统采用 MPP 架构的数据上 k8s 是不太契合的，主要是存储资源、计算资源紧密耦合的架构，不太容易满足云时代不同场景下的不同 workload 需求。

当我们需要扩容集群扩充 CPU 资源时，往往会引发数据的 reshuffle ，这会消耗比较大的网络带宽和 CPU 资源。
而通过分离存储资源、计算资源，可以独立规划存储、计算的资源规格和容量。这样计算资源的扩容、缩容、释放，均可以比较快完成，并且不会带来额外的数据搬迁的代价。

最好的方式就是这些中间件计算和存储分开， 现在存储和网络这方面比如 RDMA 也是不断发展去减少分布式数据库的消耗

趋势和你列举的一部分重合，另一部分不是云原生领域。
像有状态应用上 k8s 有一些是需要改造的，这部分属于中间件研发而非云原生。
比如 confluent 对应 kafka 就可以轻松上 k8s, 而 kafka 就没有。
kubeflow 这些属于 MLOps, 是需要懂 AI 专业领域来能搞的
今年最火的是平台工程以及 EBPF 整合 k8s,其次是 wasm 。

@silentsky 依赖注入不多， 如果你在一些公司被要求使用公司的脚手架以及一些定制的框架的话，会见到。
用 go 写业务开发的话是可以看到一些， 主要还是团队技术领导好控制下面的开发小弟，完形填空写代码

redis 执行命令是单线程，一次执行一整条 lua 脚本，当然是原子性，如果是 redis 集群，在一些版本有可能有问题。

@hongyexiaoqing 运维开发的确没那么简单， 业务开发也不要太觉得自己并发多高， 很多非核心的部门的那点并发真没多少，复杂的 k8s cicd 工作流 v 站上没几个人提到，
云原生配置可编程之 KCL, cuelang 和 kubevela 这些项目在国内外也是非常火

运维是一个非常吃经验的行业， 这一行的确有些人是越老越吃香。不过现在运维也都需要懂开发， 不会开发的运维的效率是不高的。

另外说一句，能做好运维开发的都是大公司， 微服务治理和运维紧密相关。运维系统没有自动化是管理不了几百的微服务、几百台服务器的。运维监控平台是很重要的。

传统运维开发是基于 ansible 和 python 以及一些监控系统来做的


k8s 运维开发 需要懂的很多，V 站上的人多数都不是做这个的，回答真是。。。

k8s 基础命令行操作 kubectl 以及各种概念和资源对象必须懂
k8s 基础之 client-go 开发以及基于这个做一套 k8s 管理系统
Operator 开发 这个因各种公司需求来做
各种 operator 是必须要会写的，才能完成一定的运维自动化

其次像 csi, cri, cni 插件开发 需要懂

运维监控系统 开发
像传统的 zabbix 有的公司在用， 小米和滴滴的 open-falcon nightgale 的开发
prometheus 采集自定义指标这些

2PC 几个回复写得有点问题，
mysql 实现 2pc 不是 binlog 和 relog 达成共识，而是 XA 事务。XA 事务在很多数据库中是有实现。

共识算法是为了可用性， 服务器节点存在三个角色 ：leader 、follower 、candidate
主从模式中是只有主节点可以写入的。

https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/
可以看看这篇文章

binlog 那是依赖一个主多个从， 当你集群有多个主和多个从节点， 要想达到一致性就不能靠这个了。
mysql 集群 如果要允许多个主多个从 可以写入并达到一致性，就要依赖 paxos ，raft 。不同的公司都有一些实现，比如 facebook 的论文中就有通过 raft 来做一致性

mysql 将这个查询语句创建为一个视图，
这两句改写为在视图上操作。

👍👍👍

可以去看看这篇文章
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

@qq135449773 如果是基于 java 来做， 就不要研究了，java 社区对这个关注不高，远远没有成熟度。
wasi 目前支持的比较好的是 rust ，其次是 c++ 和 go 。
容器的资源隔离 wasi 是可以做到的。

在 Web 上，WebAssembly 使用浏览器提供的现有 API 。WebAssembly 系统接口（ WASI ）的创建填补了 WebAssembly 和运行在浏览器外部的系统之间的空白。这使非浏览器系统能够利用 WebAssembly 的可移植性，使 WASI 成为在分发时具有可移植性和在运行负载时具有隔离性的良好选择。

@flyqie wasm 通过 wasm 运行时 运行在各种操作系统上，wasm 运行时 比 容器运行时资源消耗更少，wasi 是用来让 wasm 和 操作系统交互的各种接口调用
k8s 运行 wasm 有两者方法
一种是兼容 Wasm 的组件替换本机 Linux 容器运行时， 使用 krustlet 代替 kubelet ， （ krustlet 目前停止更新）
另一种解决方案是使用带有 Wasm 运行时的基本镜像，并手动调用编译后的二进制文件， 这种依然是依靠容器运行。

目前流行的几种 wasm 运行时 Wasmtime （ Rust ，JIT ）、WAVM （ C/C++，JIT ）、Wasmer （ Rust ，JIT ）、Wasm3 （ C ，解释型）、WAMR (C, 解释型)。
go 编译器 以及 tinygo 都支持编译为 wasm 指令集架构的文件

有便宜的硬件，但是一两百不见得可以拿下
intel 计算棒
Google Coral
国内的 NCS 仿制产品
模型仓库去 intel openvino 和 谷歌的网站上下，有专门的量化模型 fp-16, int8 这种