还需要补充一下 Flutter + Fuchsia 才是重点, 单纯谈 Flutter 肯定不够说服力

@acidsweet
@wanguorui123

我最近两年都在做工业领域的项目, 用 QT+QML 改造了几个之前用 vb 做的, 但是 QT 的很多问题很不爽, 我在使用 fultter 的时候感觉很多方面是吸收了 qmL 的很多优点的,QT 的问题在于包袱太重了. 文档更新的进度也不够. 而这一点, flutter 要好不少,对开发者更友好一点.

Flutter 没有 UI 设计器, 但是也因此更轻快, 前些时间发布的 windows 支持其实是个很好的开端, 一些需要人机界面的工业软件仍然会大量使用 windows, (我试过各种 linux 桌面,兼容性太差了), 而那些使用 windows 原生开发的触控体验太差, 这是一个大痛点, UWP 还行但 ms 的这一套总归是不够, 所以可以 qml,flutter 一起来凑, 多一个选择肯定更好, 至于未来谁是主流就看造化.

dart 语言原则上不能算简单, 比 python, js 都要复杂不少, 但所有特性都是面向效率设计的, 用心良苦.

至于 webview, H5 太吃性能和资源, 在资源富足的个人电脑和手机上还行, 但是到了工业设备上, 那是赤裸裸的成本和利润.作为开发人员没有感知, 去做一回甲方或乙方就能深刻体会.

汽车中控以及更多类似控制面板都是比较适合 flutter, qml 这类技术的, 未来的物联网并非都是全部入云端由电脑手机来远程操控, 而应该是需要在更多的场景提供更多的人机界面, 这个人机界面一定需要非常友好. 比如手机固然可以控制家中所有的智能家具, 但是在墙面上挂一块人机操作面板也绝不是多余的,

和人,社交相关的领域微信小程序非常强大, 微信在物联网也会有一席之地, 但是物联网的领域太大了, 现在都还是初级阶段, 谁敢说一统天下.

手机 APP 发展这么多年, 红利殆尽, 谷歌站在大数据的顶端不可能这点趋势都看不清楚, 全平台,全场景才是目标.

@huskar
@DOLLOR

dart 是优秀的， 它吸收了其他语言，java，c#，golang，python，qml，js 的优点，

是商业更友好， 更有钱途的语言， 借助 Flutter，dart 回归了它的真正战场。

@longaiwp
@acidsweet
@wanguorui123
@nicevar
...
各位不要只把眼光盯着互联网和手机终端好不好， 工业物联网，车联网被你们生生忽视了

flutter 是一门很有前途的技术， 如果你还把他拿来和微信小程序比较只能说明你的眼界真的太窄， 未来是 iot 的世界， 手机 UI 不过是很小的一部分而已， 如果对工业领域了解的人就会知道， 好多已有的软件使用的还是上个世纪的技术，急切需要改进，怎么改，难道你那微信小程序和 H5 去改， 你试试不到 1000 元的工控触摸屏跑微信和 H5 试试。

工业物联网有各种控制面板， 而且还有越来越多的场景需求， 再怎么说汽车中控屏也算是个市场不小吧， 难道说这个微信也占领了吗。

看看 QT/QML 发展的方向， 不了解的可能说，QT/QML 早被边缘化了， 早被微信小程序打趴下了， 我只能说，你说的对， 微信太厉害了。

在工业领域， 只有 QML，Flutter 这样的技术才有更多的优化空间，别问我为什么这么确定， 我只透露一点， 某个项目我把 H5 实现的 UI 修改为 QML 后，硬件成本下降 500 元， 多收了 500K 的利润， 如果我改成微信小程序，也许能多收 1000K 吧， 但是臣妾做不到啊。


如果懂 java，C#, javascript，QT/Qml，golang, python 这些语言，dart，flutter 只要 10 分钟温习一下就可以开始做生产项目了， 很不幸， 上面说的这几种语言，我都非常熟悉， 所以我太喜欢 dart 和 flutter 了， 我在 1 分钟之内决定弃 QT/QML 转 Flutter， 我似乎看见了漫天飞舞的钞票， 不管你们怎么吹微信小程序， 我是不会改变主义的。

不要在乎星星， 我 8 年的项目才不到 400 星， 但是做商业的收入也有 7 位数了， 有的人项目几万星星还是累死累活的， 当然不能绝对以钱为衡量标准， 开心就好

一定要刮干净吗， 要的就是那种留一茬的效果， 要不怎么够爷们， 留胡子的艺术远远胜过刮胡子。每次摸上去那种扎手的感觉就很爽。

但有些留小山羊胡子的那种真不喜欢， 下巴留那么一戳， 娃娃脸都喜欢这个造型， 显得老成。

99%的商业许可协议上都会写着类似免责条款

* xx 公司特别提请您注意，xx 公司为了保障公司业务发展和调整的自主权，xx 公司拥有随时经或未经事先通知而修改服务内容、中止或终止部分或全部软件使用和服务的权利，修改会公布于 xx 公司网站相关页面上，一经公布视为通知。xx 公司行使修改或中止、终止部分或全部软件使用和服务的权利而造成损失的，xx 公司不需对您或任何第三方负责。

这年头宽带没有 500M 以上怎么干活

这年头每个 500M 以上怎么干活

@cupen
@axex

实际项目中，有几个不同的子系统模块，使用了其他语言 node，php 开发，和主系统一样都是提供 json api 的 webserver

所以在主程序这里对所有前端请求做 分发， 由于在前端直接调用子系统的 API 会有一些问题， 比如跨域的兼容性， 统一权限拦截处理，子系统是没有权限判断的，统一在主系统 webserver 处理。


这应该算是比较简单的微服务调用吧


现在处理有了一点进展， 主系统处理了一个大 bug， 由于 grpc 连接处理不当导致的内存泄露（大量连接没有关闭）。解决这个 bug 后截止为止， 这个反向代理一直正常。但不能确定是不是 bug 引起的问题，应该是很有相关性， 继续观察。


http://xy.abc.com 后启动， 主程序的代理也不生效， 这个 status 是 404，去 echo 的 issues 列表看了下，没有很直接相关的主题，还是先定位下是不是我自己程序的 bug 吧。


对于服务分发调用，确实需要考虑更好地可靠性， 但暂时还不想引用过多的第三方工具（还达不到多大的量级），只能手工去加强这块的管理了， 至少可以先通过运维脚本监控重启解决。

我一直再用一个 89 元一年的 256M 数据库 mysql 实例， 目前新建实例已经没有这个配置， 至少 1G 起， 我也有点担心会不会突然哪天把我这个实例咔嚓了。虽然一次续了 5 年，心里还是没底

go 的确理论上有运行效率问题 == k8s 的确理论上有运行效率问题，让不让人活了

焦虑很正常，找个无公害发泄方式， 打拳击，摔瓶子，最后就会平静下来，我的习惯不好， 喜欢摔手机， 摔了 4 个了， 所以一直用千元机， 想换新机了就找个机会发脾气摔了

好的前期是最重要的, 不要太指望后期,

那些建议楼主嫁人的都扯淡， 这年代，女性保持独立性，有自己的经济实力才是最靠谱的，结婚只是人生的一部分，有些机缘可遇不可求， 自己才是最靠得住的，所以楼主不需要具体的建议，只需要你们傻傻的鼓励就够了。

@tsingke 我之前也是使用 elasticsearch 做监控，用起来很爽， 但是 es 是真的重， 不是每个项目都能给你 4 核 32g 的服务器让你爽， 这种情况下 ES 特别尴尬， 所以我觉得 ES 至少不适合小型项目使用， 还不如直接用 zabbix 。

但是如果要自己来撸监控系统，又要在一定范围内用起来，覆盖到大部分场景，就是选择 mysql， 原因就是学习成本低， 百分之 80 的人可以轻松搭建配置 mysql，并且都有自己熟悉的一套维护方法。

而其他的比如 mongodb，pg 系的 timescale，influxdb 等可能更合适做这个事情， 但是有个重要的原因， 他需要使用者去多学习一项额外的技能， 而这项技能即使比 mysql 简单也不一定能被认可， 这个是一种惰性， 就是不想学， 不想用， 我们自己或许可以突破，但是很多人还是不愿意， 比如我自己，能用 mysql 解决的我就不碰 MongoDB， 我就是不想维护两个数据库，哪天让另一个人去维护， 他先来一句“为啥用 mongodb 啊”， 那时你就想抽他一巴掌，再抽自己一巴掌。

我总结了一下，这叫心智负担， 大部分比较喜欢技术和钻研技术的人，不会在意多用几种技术， 但是面向长期的使用场景， 越简单稳定的越好， 越不要自己折腾越好。

如果有便宜的云 elasticsearch，mongodb，timescale 可以随便用， 因为云平台解决了基础维护， 不会给使用者太多心智负担。


所以，总结下来， 其实 mysql 就很好， 也许有人说 mysql 真不适合存储日志类数据， 但是别忘了 MySQL 内置有 archive 存储引擎，那是专喂日志的， 压缩存储量只有 20%， 又不会有 CPU 压力，写入并发高的不得了， 虽然不能删除，没有索引支持， 但是通过按日期、月份分表就可以很轻松解决了， 程序里自动建表，控制单表数据量， 删除数据就直接删除历史表， 这也是符合日志型数据的管理方法的， 备份迁移直接拷贝数据文件， 不能再简单了，

至于聚合，可以对固定类型的做预先聚合存储， 比如对秒级实时数据做分钟间隔，小时间隔的聚合计算后存储， 前端对实时数据就小范围查询， 大范围数据就去查询分钟间隔，小时间隔的统计数据， 这样就很快， 实际上工业物联网不少领域就是这么存储和处理数据的。

前端可视化的可以输出到一些第三方系统， 比如 grafana， 或者直接使用 mapreduce，linq 、ReactiveX，echart 等方式输出。

很多小型的项目， 数据量不大， 基于 mysql archive （甚至都不用），是最合适的， 最后顺便鄙视开口闭口就是 mysql 绝对不适合存日志的， 很多连百万级的量都没有碰过， 几十万的数据优化都不会。

功能太强，elasticsearch 太重， 运维成本过高

必须打, 有些人没小孩不要乱提建议

linq 的场景, 对泛型确实很期待, 超大数据集, 应该提升不止 10 倍性能

squares := []int{}

Range(1, 10).SelectT(func(type int)(x int) int { return x * x } ). ToSlice(&squares)