面向工资编程，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 流协议 存的也不是每帧图像全部像素，涉及到很多视频处理。

@bthulu 先学会点礼貌先，没一点礼貌，我也不想回复你的任何问题

@bthulu 你自己不去看看 java 的新题案和 解决策略比如 graalvm ， 你机器上没有 jvm 可以跑 java ， 是吧。
jvm 设计之初就是为了充分利用服务器内存，甚至是多占用一些内存 来做 gc 。

要对比 docker 那也是对比虚拟机像 kvm 、vmware 的方案。
你什么都不懂就开始胡乱 at 人吧。

微服务不等于云原生， 微服务本身拆分和规划本身就不只是技术，还是团队管理问题。国内不少公司还停留在管理不善的问题阶段。

多数人对 devops 并不理解吧，k8s 就是单体部署也没有什么问题。 国内和国外所了解的都不是一回事

国外是谷歌新出的论文"towards modern development of cloud application"和 service weaver 对 微服务 发出新的构想。

文章认为，微服务将逻辑边界（如何编写代码）与 物理边界（如何部署代码）混为一谈。提出的方案是将应用程序构建为逻辑整体， 但将其交给自动化运行时， 后者根据应用程序所需内容和可用内容来决定在哪里运行工作负载。

bitvise ssh