就说 ray 计算吧，kuberay 就结合 kubernetes 和 ray 两者，它是以 operator 方式来部署的。
k8s 当然知道资源的情况，但是 k8s 不需要去了解你的业务内部和一些特定的业务需求。

云原生应用开发模式 != FaaS
单体式编程，编译时拆分，分布式执行 和 FaaS 也没有直接关系
去看看谷歌的 service weaver 吧。

至于你提到的 ray 那完全是另一回事，ray 需要对针对计算做资源和任务编排比如 task actor ，是相应 AI 人员做的事情，k8s 是针对服务部署以及服务的，而不关心计算之间的事情。

之前没看到是 mariadb, 那么就是分库的方案了，schema 拆分， 现在谈论任何优化都是过早的事情， 在你的用户量确定和增长量确定，然后服务器监控指标再说这些。
另外数据库分库分表也是根据实际情况来的，也是多种方案，你现在想这个实在是太早， 分库分表带来的一堆问题你自己都不好解决的。
架构演进可以如下
scheme 分拆 到 分区表 主从优化 最后才是分库分表或分布式数据库。

经典 shamir secret sharing 算法的一些项目
https://github.com/jwerle/shamirs-secret-sharing
https://github.com/shea256/secret-sharing
https://github.com/dsprenkels/sss

有访问权限的人都持有同一密钥就可以同时编辑， 我觉得可以参考密码学上的 secret sharing 比如（ n,k) schema, 这个比同一密钥分发更加安全。

一些端对端 加密共享协作的开源部署项目
https://github.com/cryptpad/cryptpad

你的问题其实 HTAP 类型的数据库就能满足， 不过你可能是用 mysql 吧， 你可以通过 mysql CDC 工具同步到 ES 来做分析或建立一些数仓来做分析。

那么多 IPC 的通信方式， 你选一种就行。 简单点就是 unix domain socket, 复杂点搞共享内存、POSIX 消息队列。像这种通信有很多开发库都封装了，比如 zeromq ， 自己多试试吧。

现在的语言就是绑定各种领域，这不是 10 年前，大家都是做 web 和 互联网 1.0 的时代。 另外专业领域的知识远比一些通用的业务知识要值钱，不要限于 crud 和 web 程序员里面

别整什么语言火啦， 难道不知道国内越火就等于越内卷，你们也不看看 java 内卷到什么程度，想不想卷八股文
golang 的确是各种基建的主力语言，而不是业务开发的首选语言。
国外都是各种基建比如
k8s 和 多数云原生设施 以及 cicd
数据库 比如分布式数据库 CockroachDB, tidb 的 控制层、
时序数据库如 Influxdb 、VictoriaMetrics
负载均衡的控制层比如 istio
各种分布式存储比如 Seaweed FS 、glusterfs 、juicefs 、MinIO
区块链和 web3 的项目如 ethernum 、hyberledger

国内用 go 做业务的的确是比较有钱的公司或一些科技初创公司

如果你可以花钱的话，可以使用 EMQX 企业版，兼容多种数据库存储。
还支持大文件数据上传。
它提供了 MQTT 协议文件传输能力，允许设备上传大文件数据并将其存储到本地磁盘或 S3 存储

@buffzty try catch 不是 goto 的封装，在 C 中实现 try catch 也不是一种方式，简单一点是 setjmp longjmp,
很多代码是从汇编的方式实现的。
try catch 这些和对象资源也是绑定的， 在 C 中实现的也是个模拟的语法糖，对象资源回收是不好实现的

Rust ，它里面也是满屏幕的.unwrap()，这实际上跟 Go 的 if err != nil 一样
写业务的还是太闲了， 天天讨论这些。

另外 try catch exception 还涉及到 RAII 机制，go 连对象都没有，谈 try catch 在 go 里面是没什么意义的，最多也只是语法糖。

因为大多数这种人都是写 java 的，喜欢这种 try catch 异常处理， 对于非业务开发，懒散和滥用 try catch 处理可以导致致命的 bug ，
linux 内核 和 c 那么多库都没有 try catch, 方式比 go 还原始也没啥人说什么，都是业务开发太闲了。
go 的哲学就是 错误就是要显示检查处理的，异常处理的不可见错误检查所带来的问题其实是很大的。不少业务开发才不管那么多，还不是能跑就行，最多加个单元测试。

thebytebook 挺不错的， 内容没有过时，挺一下。

上面说的都是 ci, 只有 argocd 是 cd 。
一般来说中小公司 ci 自动化比如 gitlab ci 、github action 、jenkins ，cd 多数还是手动 或写配置文件比如 yaml/helm/kustomize
terraform, argocd 直接使用也是满足一些简单配置。

尽管 K8S 统一了底层基础架构（提到应用交付、部署，大部分都是指往 k8s 上部署），但是它并没有在混合的分布式部署环境之上提供应用层的软件交付模型和抽象，对于复杂的多集群，很多公司用了 Kubevela(cuelang)
cuelang 动态配置语言比较强大 但不如 KCL 有强类型和更多扩展.

个人观点：非常不喜欢这种被限制的方式， 就算是 aop ， 那么也要精简，而不是做全。
让 gin 、echo 、iris 能够接入就行，或者参考 kratos 做成插件形式。

static pod 是不受 kubernetes 调度的， 属于 Kubelet 直接管理。 只有少数情况下需要用， 这个是和节点绑定的
1.只有要在宿主机运行的 daemon
2. 需要和节点绑定的 Pod
直接和 kubernetes 节点相关的修改和组件 需要, 其他情况下用这个基本要被开除。

xsession 错误大多数并不是很重要， 基本上它是一个相当低级的 X11 的错误日志，xwindows Linux 远程桌面的东西。
定期删除

k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
滴滴技术在文章里写原地大版本升级，艺高人胆大，链接在下
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw