软考去年教材大改了， 出的题目如案例题现在大概率是教材上的新知识点，而不是过去常考的知识点。
如果你是从事 IT 工作 的程序员，那么没有必要花钱去培训班，都是智商税，我曾经看过希赛老师讲课，那一堂课废话就有一半以上， 其他有用的也就是做题套路而已。
淘宝上有文老师软考资料，稍微看看。
发的一些 2 到 3 年前的资料就不要看了， 选择题我就每天刷刷题库
案例题 看看文毅软考资料 就行了，
论文自己多写写，多吹吹，很多论文内容不怎么样都能当范文说明阅卷老师水平也不高，只要字数不差太多，内容没有写偏就可以了。
另外记住，选择新的技术和领先的技术的论文话题要远比那些传统软件工程论题得分高，这个论文就要靠平时多积累，多看一些架构师写的内容。

webrtc 是为了双向通信，视频和音频双向 webrtc 适合的视频会议，远程桌面分享，而这个在直播里面没有必要，并且做并发更困难。

直播里面主要是一对多广播音视频信息，并没有多少需要双向的需求。

搞清楚服务的定位先， 如果是监控摄像头，那么首选是 rtsp, 个人电脑摄像头或手机推流的确是 rtmp 。

帮 OP 重新显示一下图片链接，V2ex 图片格式有要求， 要是 i.imgur.com ，图片结尾要是.png 或.jpg
https://imgur.com/68SovkV

你下面这个是 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 写业务开发的话是可以看到一些， 主要还是团队技术领导好控制下面的开发小弟，完形填空写代码