对于 Qt，只要不修改源代码并且动态链接，是完全可以发布编译好的库的，也可以和闭源软件一同发布，这是没有问题的。

在这个用例之下，LGPL 的重点在于：
1、不修改源码
2、动态链接
3、不修改 Qt 库的分发版权，并提供原有的版权声明

是否秒开，跟采用的语言，是不是 h5 没有关系。关键是流媒体传输的方式，若是传统的直播类协议，如 hls、rtmp 这些，延迟 2-3s 是正常的情况

若要秒开，可以直接基于 rtp/rtcp 进行传输，或者采用 webrtc 这样的方式

若是 C++做后台服务器开发，那可以转；对后端多做些了解，对以后是加成
若是做客户端，就不要考虑

升级使用 go mod 之后，vscode 折腾老半天还是没正常过
还是 goland 省心，一次配置没有任何问题，一切正常

好聚好散，及时止损。若花的不是自己的钱，那无所谓，继续撑就是

１．评估工期极可能长
各种可能都要考虑到

２．把自动化测试都自己搞起来
开发个小模块小功能，没事慢慢把所有用例过一遍＼两遍＼三遍，确认没问题再提交测试


其实一句话就是，把测试的工作顺手就做了，而且要反复多做．测试会轻松很多，建议内部转岗测试

其实你就是把简单的问题复杂化了

用户态，由于无法一次处理完数据，基于性能考虑（避免不必要拷贝）。其实，你需要做的不就是要记录读写两个位置的地址而已

比较通用的，就是环形缓存，数据结构选择你喜欢的都可以，比如数组

@goldenalex #121
更大的压力是边缘节点或服务器端的带宽压力，大概率短期是无解
现在所谓的云游戏，通过类似 rdp 或 vnc 效果是不会好的。真正体验好，就是服务器端根据模型与数据，生成视频流，然后客户端就是类似现在看视频网站差不多——体验自然可以好很多

有人说小公司不要用微服务，恰恰相反，小公司更应该用微服务。因为这样整套框架搭建起来之后，在招人用人及运维方面，都是极其节省各种成本，提高开发维护效率

微服务，火了好几年的东西。曾经我们看中的是微服务拆分之后，每个项目变得更小，对团队的每个人来说维护成本降低，因为需要了解 的东西局限于一个更小的服务。第二是加强了技术选型的灵活性。但是由于没有实践，并不知道微服务会带来什么大的问题。 当我们大规模应用微服务之后，问题才开始慢慢显现出来。

网络调用过多
-----------------------------------------------------------------
不知道是如何评判过多？是影响到带来额外的处理延迟，还是性能瓶颈，或是带来额外的运维

技术栈太过灵活
-----------------------------------------------------------------
有很多选择又不是以为着所有的都会使用。若出现混乱（如随意选用技术栈等），这是管理的问题
选用特定技术栈，自然是有响应的好处

难于应对连表查询的需求
-----------------------------------------------------------------
这是架构或管理要背的锅

核心应用崩溃会导致大面积瘫痪
-----------------------------------------------------------------
降级，限流就是来做这个的

运维成本增加
-----------------------------------------------------------------
短期看是带来运维成本增加，但若真的把 devops 用起来；就算是简单的把 docker 用起来，看到的都是节省运维成本

接口风格不一致
-----------------------------------------------------------------
管理要背的锅

上面就是个人总结的一些微服务所带来的问题。对每个缺点的详细说明请看原文 :)

设备端与云平台的通讯，用 mqtt 会简单很多
１．云端部署一台 mqtt broker，如 emqtt
２．通过 pub/sub 发布与订阅消息（实时）

３．服务器端，订阅所有数据，进行处理（如转发或存储等）
别的，跟你原先设想，愿意怎么做都没问题

看楼主折腾了一大堆，却又不愿意稍微深入了解与配置下
用 linux 桌面版，若不想折腾就老老实实用 ubuntu; 若想折腾，就有个折腾的样子

比如你说的一大堆所谓的问题，只要稍微花些时间百度下，都可以解决的

楼上各位给模拟器、虚拟机方案的就不要瞎出主意了，要跑视频这都不靠谱，还不如直接用 web 或者手机（平板）实在些。起码手机或平板，视频大多数还是可以硬解

@fanchangyong 你误解了我的回答。比如你要两端 p2p 传文件，如 A 与Ｂ，其中ａ、ｂ处于不同的网络环境（家庭或公司），要穿透成功就要求ａ、ｂ都穿透成功，才可以 p2p，不然是通过 turn 转发

若 a 穿透成功；而 b 所处的网络（如某公司），防火墙把 udp 都封掉，或者把 80/443 之外的端口都封了，那么ｂ是无法穿透成功的

WebRTC 穿透成功率可以到 95%以上；当然，需要对服务器端配置与客户端配置做适当调整，进行优化，比如
1. stun 采用 tcp 方式
2. stun/turn 服务器端口要修改

等等诸如此类。因为很多内网会封掉 udp，对于 tcp 只会开启 80/443

@puras 这就是考核机制要做的事情。结果导向，工作效果反应到考核这个问题自然就可解决

对于工业这个方面，近期关注也比较多。相对来说，机会比较多的是网关（集成监控或视频）、工业自动化（如基于激光或视频的方案），还有上位机客户端（可组态、图像处理与流程）