这方面开发包含了多个方向，而不是一个方向，v2ex 上现在牛人基本越来越少，没有几个人会回复的。
一类是 kubernetes 开发
kubernetes 组件开发 一般在云边协同 和边缘云上很多
如果要运行在国产操作系统上，有的也需要对 kubernetes 源码修改。

一类是运维开发
涉及到 crd, 多集群管理和分发 以及备份，更高级的搞平台工程

一类是容器开发 门槛很高
要求懂 Linux 内核 和网络协议栈

@diagnostics
你嘴里还不是讲几个框架，你不会认为人家没有开源一些流式计算就没有吧。原来懂点框架的程序猿也会觉得自己牛逼， 你说的 apache spark 其中就已经有了替代。
DASK 以及 Ray 的分布式计算麻烦了解一下。
另外我告诉你一句， 你了解的也不过是过去的技术，不代表未来的技术栈。

说 java 不错的麻烦就不要谈神马性能了， 天天用 spring 全家桶的人根本不配谈性能， 和 cpp 持平基本没几个人能做到

java 的确是成熟的业务开发必备， 开发起来效率搞。降低程序员的门槛， 连代码都写得整齐划一，没有特点
如果你不是科班没问题，都是吃饭， 业务开发隔离了很多计算机知识本质就是企业的考虑，好控制人员和成本，缺你都有的是人。

@diagnostics 人家的项目至少在他的工作领域方面很不错， 你有神马，你还不是嘴炮。
另外你不会知道大数据现在已经也在变化吧， 这都是来自于谷歌的大数据论文。

面向工资编程，go 平均工资肯定是比 java 高的，这个在国外的各语言统计有表现。
大多数 javaer 基本都是依赖各种框架和库， 离开框架和库 属于什么都不会。
语言都要分领域的，java 适合的和 go 适合的领域不一样，过个 10 年，业务开发有可能会出现 go 程序员和 java 一样人多了。
现在不是 10 年前的市场，那是招聘基本是 curd 和 web 方面的人。

react native 和 flutter 都是做界面 UI 的， 如果 H5 没有问题， 切换这些没有意义。
关键组件用原生就可以了

建议分析是否需要跨端或在多个平台上构建应用程序，包括 iOS ，Android ，Web 和小程序等。

中间件不怎么用各种框架，都是想法设法减轻对第三方依赖的，这不是业务开发，中间件要想可控性强，就别用什么框架，一些通用的 bug 少的库可以用用

opencv 的 videocapture 已经对各种流协议以及摄像头做了高级封装， 直接在 videocapture 中写 rtsp url 地址就可以读出完整的图像，其他方式我尝试过的有 live555, 它是 c++ 专门处理 rtsp 的库需要你对视频处理有一定理解, ffmpeg 一些直接方式不推荐。
rtsp 包含 RTSP 控制指令以及 RTP 数据，协议不是直接编解码能解决的
视频编解码像摄像头很多用了 h265 来保证高压缩率。
yuv 是色彩空间，图像的格式，我们通常说的色彩空间还有 RGB, BGR, YCbCr 这些。

给内置类型添加是不行的，但是搞一个类模拟函数，给函数添加是可以的

class NamedFunction:
def __init__(self, name, f):
self.f = f
self.name = name

def __call__(self, *args, **kwargs):
return self.f(*args, **kwargs)

def __str__(self):
return self.name


f = NamedFunction("lambda: 'blah'", lambda: 'blah')
print(f())
print(f)

在 Python 中，不能直接在 str 类型上添加自定义方法。但是，可以通过创建一个新的类来继承 str 类，并在新类中添加自定义方法。以下是一个示例：


class MyStr(str):
def my_custom_method(self):
# 在这里实现你的自定义方法
pass

# 使用自定义类
my_str = MyStr("Hello, world!")
my_str.my_custom_method()

或者修改 str 的 built-in 方法

一些常见对象的魔术方法
__len__, __getitem__, __contains__, __add__, __mul__, __mod__, __format__, __eq__, __ne__, __lt__, __le__, __gt__, __ge__, __hash__, __repr__, __str__, __bytes__, __bool__, __int__, __float__, __complex__, __index__, __trunc__, __floor__, __ceil__, __round__, __enter__, __exit__, __new__, __init__, __del__, __call__, __getattr__, __setattr__, __delattr__, __dir__, __getattribute__, __setitem__, __delitem__, __iter__, __next__, __reversed__, __len__, __contains__, __add__, __mul__, __rmul__, __mod__, __format__, __eq__, __ne__, __lt__, __le__, __gt__, __ge__, __hash__, __repr__, __str__, __bytes__, __bool__, __int__, __float__, __complex__, __index__, __trunc__, __floor__, __ceil__, __round__, __enter__, __exit__, __new__, __init__, __del__, __call__, __getattr__, __setattr__, __delattr__, __dir__, __getattribute__, __setitem__, __delitem__, __iter__, __next__, __reversed__, __contains__, __add__, __mul__, __rmul__, __mod__, __format__, __eq__, __ne__, __lt__, __le__, __gt__, __ge__, __hash__, __repr__, __str__, __bytes__, __bool__, __int__, __float__, __complex__, __index__, __trunc__, __floor__, __ceil__, __round__, __enter__, __exit__, __new__, __init__, __del__, __call__, __getattr__, __setattr__, __delattr__, __dir__, __getattribute__, __setitem__, __delitem__, __iter__, __next__, __reversed__, __len__,

容器网络是 linux 的特性，linux 没有/dev/tcp

另外容器网络是在命名空间中的

无 shell 或工具的 pod 调试就是 nsenter

这个是 python 通用的省内存技巧，有一定参考意义， 没有 cython 和 pypy 效果好。

@nothingistrue 有点搞笑，那么多人都说了， 你怎么还这么头铁。tidb 是 newsql ， 其设计是在 google spanner F1 论文的实现 来对关系事务做支持。
tidb mysql 兼容的 mysql 传输的协议 和 sql 语法，而不是什么二开。
另外 tidb 设计理念就和 mysql 没有关系，
存储引擎层用 rust 写的 tikv, TiKV 的 KV 存储模型和 SQL 中的 Table 无关
查询层则是用 golang 写的。

你们的业务是 OLTP 为主， 仅仅是数据量的话，这些方案都不需要，直接建 mysql 分区表，数据量和并发、吞吐量不是一回事。
如果是面向用户的较高并发简单点就是 Sharding-JDBC ，不过依然会存在各种不兼容要修改代码的问题，分库分表的限制也是不少的。
分布式数据库也有很多种选择， 一般分为两类，一类是 NewSQL, 另一类是 PG-XC ，NewSQL 包含 oceanbase, tidb.

可以考虑一些 PG-XC 的数据库，是在传统关系型数据库，增加了切片集群，增加了协调节点，增加了全局时钟,性能比较稳定，也比较接近分库分表。
一般有如下几个
腾讯的 TBase
华为的 GuassDB 300

无论是深入了解原理还是深度二次开发都必然是 Go

zeromq 没怎么用过特殊模式，你把 zeromq 看成一个可以实现内存消息队列的设计精巧的网络库就好。

zeromq 低延迟和内存低占用 不是其他通信方式可以比的， 不少人是自己在 zeromq 的 源码和 业务代码上添加一些额外功能比如持久化。

zeroq 支持三种通信方式 inproc 、ipc 、tcp

我用的是 inproc 和 ipc , inproc 对共享内存做了封装, ipc 则是 unix domain socket, 其 ipc 封装实现很不错了

如果单机内部不同进程之间通信而不是不同主机之间通信，可以考虑 zeromq, 像嵌入式设备或边缘设备上用这个也不错。

我是用在 视频处理和分析中， 将 c++ 读取监控摄像头的视频帧分发给不同的 GPU 上跑的 python 程序，完成并行不同功能的 AI 处理。

一些参考的例子

https://github.com/jeffbass/imagezmq
https://pyimagesearch.com/2019/04/15/live-video-streaming-over-network-with-opencv-and-imagezmq/

大公司自建云基础设施，
如果项目可以结合一些弹性混部，在线离线混部的建议 比较好。

java 用 opencv 的 bindings 就行， 其他的处理都比较麻烦，rtsp 流协议 存的也不是每帧图像全部像素，涉及到很多视频处理。