你下面这个是 c++ 不是 C, 你要把 c++ 转成 C 的 接口， 才能调用

只有 C 的 bindings 是通用的

C 的代码，但要调用写好的 C++代码时，需要将 c++的类型配置为.lib 的静态库或是.dll 的动态库，然后通过 extern “c”调用
Linux 则是.so 的共享库

此时搬出架构师考试的内容
https://i.imgur.com/vDgRMHx.png
遗留系统的演化策略
把对遗留系统的评价结果分列在的四个象限内，对处在不同象限的遗留系统采取不同的演化策略：

淘汰策略
第 3 象限为低水平、低价值区，即遗留系统的技术含量较低，且具有较低的商业价值。对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。

完全淘汰是一种极端性策略，一般是企业的业务产生了根本的变化，遗留系统基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了，经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。

对遗留系统的完全淘汰是企业资源的根本浪费，应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

继承策略
第 4 象限为低水平、高价值区，即遗留系统的技术含量较低，可满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业业务对该系统仍有很大的依赖性。

对这种遗留系统的演化策略为继承，在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型；为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

要做到对遗留系统的继承，必须对系统进行分析，得到旧系统的功能模型和数据模型，这种分析可以部分代替或验证系统的需求分析；如果遗留系统的维护文档不完整，而又必须解析系统的功能模型和数据模型，那将是一项十分艰巨的任务。这时可使用有关系统重构的 CASE 工具，通过分析系统的代码生成系统结构图或其他报告。

改造策略
第 1 象限为高水平、高价值区，即遗留系统的技术含量较高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求；这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。

这些改造包括系统功能的增强和数据模型的改造两个方面：系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型转化的过程。

集成策略
第 2 象限为高水平、低价值区，即遗留系统的技术含量较高，但其商业价值较低，可能只完成某个部门（或子公司）的业务管理；这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统，他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。

我在 twitter 上遇到一些数字游民， 可以和他们多探讨探讨比如大帅老猿、tinyfool

多数数字游民是老程序员了， 这个在 V2EX 上并不多

这时候 yaml 是不够的，
你需要尝试一下 HCL CUE KCL 这样的通用语言去生成 Yaml 了
https://kcl-lang.io/docs/user_docs/getting-started/intro/

stable diffusion 也要带上 seed,然后就是抽卡了。

midjourney 可以做到， 选生成图片的时候带上 seed Midjourney 机器人使用种子编号创建视觉噪声场（扩散模型的起始图片），就像小时候电视没有信号屏幕上是雪花图，作为生成初始图片网格的起点。种子数是为每个图片随机生成的，但可以使用--seed 或 --sameseed 参数指定。使用相同的种子编号和提示产生相似的最终图片。

@mokiki js 和 rust 哪里是 C 类语言，再说语言谈的是编程范式。

语言对应着不同的设计思想和范式，如果是研究兴趣和学习的话，建议多看看不同范式的语言

如果为了升职加薪，多看看一些其他的热门语言和语言所运用的领域以及项目。

强烈推荐这个油管主的视频列表
https://www.youtube.com/@Techsithtube/playlists

历史上工业革命出现的时候一些人也是认为马车还是比蒸汽机车好，后来就不用说了吧。

现在都有数据库容器化弹性伸缩的云服务并对外提供， 并且还是支持分库分表的，

试用一下 plantscale 吧， 基于云原生 vitess 的 mysql

国内创业团体做的 kubeblocks 也可以看看

kubevirt 是比较差的做法。FabricPath 已经谈到了。
较好的做法是用 kata container

@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 这些项目在国内外也是非常火

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

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